Subject: "Yes, I can handle PGP/MIME"

From: David Shaw <[email-masked]>
Date: Thu, 15 Apr 2004 11:46:56 -0400

The PGP/MIME vs inline discussion seems to be on an up-cycle, and it
showed up on both the PGP and GnuPG mailing lists in the past week.

I don't mean to revisit the debate itself, so suffice to say that some
people use it, some people don't use it, some people can't use it, and
there are difficulties when a user sends PGP/MIME to someone who can't
handle it.

Given all that, would there be some benefit in a standard way for a
user to advertise that he can handle PGP/MIME?  Specifically, a
"features" subpacket bit to say "I can handle PGP/MIME".

It's important not to read too much into such a feature bit.  Having
the bit set does not mean that PGP/MIME must be used, and having the
bit unset does not mean that PGP/MIME must not be used.  A PGP/MIME
bit, rather like the MDC bit, simply means that the user is capable of
handling a PGP/MIME message.  How a sender handles that extra
information is up to him.  Senders remain free to use configuration,
heuristics, guessing, or whatever methods they like to decide when to
use PGP/MIME.

To be sure, this is a little odd since OpenPGP/MIME and OpenPGP are
two different things, and 2440bis is not the OpenPGP/MIME spec.
Nevertheless, since you can't do OpenPGP/MIME without OpenPGP, it
would be convenient to be able to advertise this capability via
OpenPGP.

Proposed text:

In section 5.2.3.24, add:

   0x02 - Recipient is capable of handling OpenPGP/MIME (RFC-3156).

In the same section, change this sentence:

    In the case of Modification Detection, an implementation may
    freely infer this feature from other suitable
    implementation-dependent mechanisms.

to:

    In the case of Modification Detection and OpenPGP/MIME, an
    implementation may freely infer this feature from other suitable
    implementation-dependent mechanisms.

David

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Fri, 16 Apr 2004 01:22:32 +0900 (JST)

From: David Shaw <[email-masked]>
Subject: "Yes, I can handle PGP/MIME"

> "features" subpacket bit to say "I can handle PGP/MIME".

Interesting.

Bue I have a simple question:

Suppose Alice delivered her public key which says I can't handle
PGP/MIME. Then Alice comes to be able to handle PGP/MIME. How can she
deliver her (new) public key which says I can hadle PGP/MIME,
obsoleting old one?

--Kazu

---

From: David Shaw <[email-masked]>
Date: Thu, 15 Apr 2004 12:35:38 -0400

> deliver her (new) public key which says I can hadle PGP/MIME,

The same way she handles it if she changes her OpenPGP program to one
that can handle MDC, or has different ciphers, or changes her
expiration date.  This is a standard thing in OpenPGP.  All of the
various informational subpackets can be rewritten if their information
changes.

Section 5.2.3.3 says:

    Since a self-signature contains important information about the
    key's use, an implementation SHOULD allow the user to rewrite the
    self-signature, and important information in it, such as
    preferences and key expiration.

David

---

From: Jon Callas <[email-masked]>
Date: Thu, 15 Apr 2004 15:21:46 -0700

I have no problem with it. I'm a firm believer that we should be 
specifying syntax, and this is valuable syntax.

	Jon

---

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
Date: Fri, 16 Apr 2004 09:52:03 +0200

> "features" subpacket bit to say "I can handle PGP/MIME".

Since this is completely unrelated to OpenPGP itself, isn't this a good 
case for a notation packet on the selfsig? The big advantage is that 
this could be specified in the proper document - the one specifying 
PGP/MIME (well, when it is revised the next time), or in a document 
updating rfc3156.

I feel it is bad design to bloat the OpenPGP spec with application 
specific things like this (even when email is the dominant application 
of OpenPGP at this time.)

Notation 'pgp-mime=accept' or 'rfc3156=accept' or 'email=rfc3156' or ... 
(Hmmm. I like the latter - perhaps there will be other options on how 
email should be formatted etc., and it would allow 'email=clearsigned' 
if somebody wants to explicitly discourage PGP/MIME usage.)

greetings
- -- vbi

- -- 
featured link: http://fortytwo.ch/gpg/subkeys

---

From: Will Price <[email-masked]>
Date: Fri, 16 Apr 2004 02:24:38 -0700

In the absence of a definitive non-advisory flag, we solved this 
problem over a year ago, and the solution is now deployed in many 
versions of shipping products. Since PGP products never (before PGP 
Universal) generated the preferred keyserver attribute on keys, we 
consider PGP/MIME to be a preferred encoding format if the recipient 
key has this flag. If the flag does not appear, we use Legacy encoding 
(to be distinguished from the simplistic "inline" encoding concept as 
real scenarios such as sending HTML, RTF, encoded multiparts, and 
attachments properly in a method compatible with legacy products 
requires far more work when not using PGP/MIME than simply encrypting a 
block of "inline" plaintext).

Given that most PGP products before PGP Universal did not support 
PGP/MIME, and the only extant keys with said flag were some GPG keys, 
and most GPG front ends both require and only support PGP/MIME, it was 
a logical choice which has worked out well.

Thus, we would have no use for such a flag (if you had posted your 
message two years ago, that would be a different answer). I don't 
anticipate any major email scenarios in the future which will not 
support at least the decoding of PGP/MIME. PGP products either do now 
or will use this flag in the way indicated above. Since most GPG front 
ends already require PGP/MIME and often set this flag on keys, the 
waters are already moving in the proper direction.

Email formats are becoming ever more complex. PGP/MIME is the only 
standard solution on the table. Legacy encoding methods can be created 
to encapsulate MIME in a non-PGP/MIME way for maximum backwards 
compatibility as we have done with PGP Universal, but the complexity of 
creating an actual standard around such methods far exceeds the 
complexity of filling in the last few pieces in the transition to 
PGP/MIME.

The illusion here is that there is an alternative to PGP/MIME. That 
illusion is rapidly dispelled after careful analysis of all the kinds 
of email from every mailer and every mail system are thrown into the 
pot and we try to figure out how to encode them all without PGP/MIME. 
It is relatively hopeless to have 100% accuracy like PGP/MIME. Should 
legacy formats still be used in some cases and possibly even for 
decades to come?  Quite likely. There are some simple text/plain 
scenarios where using PGP/MIME just isn't worth the possibility of a 
compatibility issue. The reality is that the vast majority of email no 
longer falls into that category.

While this was a bit of a hack, the facts on keys in the field match 
the usage of the attribute and all signs point to that continuing. I 
believe over the next two years we will find that the remaining 
deployed population unable to decode PGP/MIME will have dwindled to 
insignificant levels. Meanwhile, anything we discussed here right now 
would not have any measurable deployment until likely 2005. Thus, I 
would suggest that if you find yourself needing such a flag, adopting 
the same method would be the most advisable and simplest solution which 
has the advantage of already being deployed.

> "features" subpacket bit to say "I can handle PGP/MIME".

- --
Will Price, VP Engineering
PGP Corporation

---

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
Date: Fri, 16 Apr 2004 12:08:45 +0200

On Friday 16 April 2004 11.24, Will Price wrote:
[...]
> standard solution on the table.
[...] 

 - some people are not able to or do not want to use PGP/MIME for 
whatever reason
 - PGP/MIME might be replaced by yet another standard in the future.

I think, since userid are quite tightly bound to email addresses, that a 
way to tell the sender how the key owner expects to receive digitally 
signed/encrypted email is something that would solve an actual problem.

Remember, rfc1847 is now almost 10 years old, and rfc2015[*] is 8 years 
old, and still the dominant email client fails horribly on such 
messages, and still inline signed email is widely in use (you said that 
not many PGP product until recently supported PGP/MIME.) So I think 
being friendly to users of legacy solutions is one lession one should 
have learned by now in the IT world.

greetings
- -- vbi

[*] yes, I know the current standard is 3156, but I think the 
differencies do not matter for mailers *not* supporting that standard. 
In case the MIME rfcs are unclear on what to do with 
multipart/<unknown> messages, rfc1847 should be enough for people to be 
aware of the existence of such messages.
- -- 
featured link: http://fortytwo.ch/gpg/intro

---

From: Len Sassaman <[email-masked]>
Date: Fri, 16 Apr 2004 03:22:37 -0700 (PDT)

> versions of shipping products. Since PGP products never (before PGP

For the record, I believe this "solution" to be ill-advised. Implementing
such hacks without discussion in this group will result in continued
compatibility issues between OpenPGP implementations.

I informed the product manager of PGP Universal of this error before the
product originally shipped, but was told it was too late to change tactics
at that point. Nevertheless, I still believe that the "preferred
keyserver" packet should indicate preferred keyservers, and that
MIME-encoding preferences should be indicated elsewhere.

Your solution is a hack, and an unnecessary one, since there is an elegant
means of expressing such information already built into OpenPGP -- the
notation data packet. I hope this is corrected in future releases of PGP
Universal.

--Len.

---

From: Ian Grigg <[email-masked]>
Date: Fri, 16 Apr 2004 08:47:09 -0400

>  - PGP/MIME might be replaced by yet another standard in the future.

To add to that,

   - email itself is being overtaken by IM.

I read somewhere (can't recall where) that the IM
traffic already exceeds that of email.  Thinking
in terms of "OpenPGP is for email" is akin to saying
"dinosaurs rule the earth" ... it's only true for so
long.

> signed/encrypted email is something that would solve an actual problem.

Why can't you invent a convention that adjusts the
userid to include an OpenPGP/MIME hint?  It could be
some small char like *, or some longer string:

    Ian Grigg <[email-masked]>   *
    Iang <[email-masked]>   MIME++"
    <[email-masked]>   I'm a lover of OpenPGP/MIME

This is what we did in our use of OpenPGP for a
different application:

    Ian Grigg [certification] (dss2) <[email-masked]>

The application goes searching for words in square
brackets.  If you wanted to use the same convention,
then, add in [MIME] to each userid.

iang

---

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
Date: Fri, 16 Apr 2004 15:25:29 +0200

[no cc:s, please]

On Friday 16 April 2004 14.47, Ian Grigg wrote:

> userid to include an OpenPGP/MIME hint?

Ugh. And then I'm forced to change the userid when I change my mailer, 
and lose all signatures on the userid that I've collected so far? I 
think embedding this info in the selfsig is the way to go - I can 
replace that and if the software is clever enough to silently ignore 
all but the newest selfsig, all users won't even notice that the 
underlying technology doesn't allow you to change your key, but only to 
add to it. I still think that this is a perfect example where notations 
would be the solution.

cheers
- -- vbi

- -- 
featured product: Debian GNU/Linux - http://debian.org

---

From: David Shaw <[email-masked]>
Date: Fri, 16 Apr 2004 10:56:52 -0400

> if somebody wants to explicitly discourage PGP/MIME usage.)

I have no objections to this, though a more complex encoding of
PGP/MIME desires (aside from yes or no) may be overkill for the
problem at hand.

David

---

From: David Shaw <[email-masked]>
Date: Fri, 16 Apr 2004 10:52:28 -0400

While I was aware of PGP's already deployed double meaning for the
"preferred keyserver" field (being both a preferred keyserver and "use
PGP/MIME" flag), I did not want my proposal to be interpreted as an
indictment of that method and so did not discuss it.  A desire to
avoid confict with that already deployed method is why there is an
entire paragraph of bending backwards in my proposal to insist that
programs can use any heuristics they want to determine PGP/MIME usage.
PGP would be completely compliant even if it ignored the proposed flag
altogether.

Nevertheless, some comments:

> waters are already moving in the proper direction.

Unfortunately, this is not true.  No version of GnuPG sets the
"preferred keyserver" flag on keys.  It is a feature scheduled for
1.4, but only exists on my laptop at this moment.

> insignificant levels.

I believed that as well, back in 1996.  I believed it again in 1998,
and so on. ;)  Here we are in 2004, and I still can't send PGP/MIME to
many correspondants.

As recently as two years ago, I sent PGP/MIME mail to Philip
Zimmermann.  He was unable to read it.

Note that I am not arguing against using PGP/MIME.  I use it whenever
I can, and I honestly believe it is the way to go.  Unfortunately, not
everyone is able to use it.  Since I do not forsee this situation
changing anytime soon - I've waited 8 years now - a features flag or
notation is a simple indicator of the mail preference of the
keyholder.

David

---

From: Ian Grigg <[email-masked]>
Date: Fri, 16 Apr 2004 11:09:57 -0400

> add to it. I still think that this is a perfect example where notations 

Well, right.  All that above has to be balanced
against the fact that email is a user application,
and it's not good to pollute OpenPGP with special
hacks and bits.  (I'm not wedded to my above
suggestion, it's more in the vein of searching
for alternates.  And there seem to be plenty of
bits available for this sort of use...)

If the choice were between adding a bit as per the
original thread suggestion by David, and overloading
another bit already utilised, as a "version" indicator,
(the "preferred keyserver attribute" ?) then I'd
definately plumb for the former - define a special
bit:

(etc.)  I think David's original post still rules.

As a standard, it's good to keep an eye on
compatibility amongst implementations, but
overloading should be discouraged.  There's
no reason why future implementations couldn't
adopt that bit, even if they used some
overloaded bit in the past/absence.

iang

PS:  at what point do we go for feature freeze?
How long does this process of minor additions
go on for?  Derik, what is the process to get
this thing signed off and passed into law?

---

From: Holger Sesterhenn <[email-masked]>
Date: Fri, 16 Apr 2004 17:46:50 +0200

Hi,

> notation is a simple indicator of the mail preference of the

Well, as soon as someone contributes a PGP/MIME capable plugin for a
specific mail client from a very specific company I am willing to say
that PGP/MIME might have a chance becoming a new standard (*).

In the meanwhile we should not use a rarely spread flag indicating the
use of keyservers to say "hey, I like PGP/MIME". I don't like hacks anymore.

Using a notation sounds ok for me.

Best Regards,

Holger Sesterhenn
---
Internet   http://www.utimaco.com

(*) Yes, Enigmail for Outlook or Outlook Express would be great!

---

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
Date: Mon, 19 Apr 2004 09:57:19 +0200

On Friday 16 April 2004 17.09, you wrote:
> > Ugh. And then I'm forced to change the userid when I change my
> > mailer, and lose all signatures on the userid that I've collected
> > so far? I think embedding this info in the selfsig is the way to
> > go[...] 

> hacks and bits. 

Yep, fully agree. Perhaps you've not read my first mail in this thread: 
I feel this bit to be unnecessary, IMHO notation data was invented 
exactly for cases like this.

cheers
-- vbi

-- 
P'tang!

---

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
Date: Mon, 19 Apr 2004 10:01:42 +0200

> that PGP/MIME might have a chance becoming a new standard (*).

Won't solve the problem for those who like to sign their mail per 
default - the problem is not people who are aware of OpenPGP (those 
usually know the PGP/MIME problem when they use MSOE, which in my 
experience is quite rare anyway.) The problem is people who do not know 
anything and do not care about OpenPGP (or any other form of email 
protection.) They won't be ready (or able) to install something on 
their machine to be able to read my mail.

cheers
-- vbi

-- 
Conquest is easy. Control is not.
		-- Kirk, "Mirror, Mirror", stardate unknown

---

From: Jon Callas <[email-masked]>
Date: Mon, 19 Apr 2004 14:20:58 -0700

I'm considering this to be so controversial that there is no consensus 
for it, and what bits of consensus there are lean away from it.

	Jon

---

From: David Shaw <[email-masked]>
Date: Tue, 20 Apr 2004 11:12:56 -0400

> for it, and what bits of consensus there are lean away from it.

I think there is consensus that such a flag should not be set in the
"features" subpacket.  There seemed to be at least some consensus that
such a flag would be better placed in a "notation" subpacket.

I'll leave it to the folks advocating a notation solution to propose
something for that ;)

David

---

From: Len Sassaman <[email-masked]>
Date: Wed, 21 Apr 2004 19:32:00 -0700 (PDT)

> for it, and what bits of consensus there are lean away from it.

My reading of the thread is that there is consensus that overloading the
preferred key server packet is the incorrect way to denote PGP/MIME
capabilities.

There also appears to be consensus that we do need some way of indicating
PGP/MIME capability.

I advocate the use of the notation data packet for this purpose, but I
would be perfectly happy if David's suggestions were implemented instead,
and a new subpacket created to handle the issue.

Either approach is valid, and I don't think anyone would criticize you for
picking either.

I do think this issue needs to be addressed decisively in the document,
though, and I encourage you to pick one of the two options above.

--Len.

---

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
Date: Thu, 22 Apr 2004 13:34:46 +0200

> I'll leave it to the folks advocating a notation solution to propose

My proposal would be to use the reserved '@'-less notation namespace, 
and establish a pseudo-hierarchy just for the case notations for other 
areas of application should ever be needed. The name of the notation 
would be 'email.mimeencoding', the value either 'rfc3156' or 
'clearsigned'. (I considered specifying rfc2440 instead, but I fear 
that's not clear enough as rfc3156-formatted email will still use 
rfc2440 technology...)

Also, the specification should IMHO state that the default for v4 keys 
without this notation should be to use what the user specifies 
explicitely, or make a guess based on other data (mail headers of the 
mail I'm replying to, features of the key of the recipient, whatever 
the MUA developers can think of), or use PGP/MIME in the absence of any 
such information.

This would have to go into an RFC (of its own - as stated, I don't think 
it should go into 2440++ since it is entirely application related), I 
guess, if this should become a standard.  I question, however, if there 
is any chance that this is ever going to get implemented - I guess the 
gnupg side would be easy enough (set it on key generation or selfsig 
generation), but I don't know about the MUA side (and I certainly won't 
spend any efforts there, even though I'd welcome the feature.)

One big drawback: all this is only useful when a key of the recipient is 
available. The situation I'm having a problem with is where the 
recipient does *not* have a public key at all, so all this won't solve 
that :-(

But the happy conclusion: this certainly should not affect further work 
on rfc2440++

greetings
- -- vbi

- -- 
The content of this message may or may not reflect the opinion of me, my
employer, my girlfriend, my cat or anybody else, regardless of the fact
whether such an employer, girlfriend, cat, or anybody else exists.  I
(or my employer, girlfriend, cat or whoever) disclaim any legal
obligations resulting from the above message.  You, as the reader of
this message, may or may not have the permission to redistribute this
message as a whole or in parts, verbatim or in modified form, or to
distribute any message at all.

---

From: Jon Callas <[email-masked]>
Date: Thu, 22 Apr 2004 12:12:05 -0700

I disagree with where this is going.

The point of having notations is so that someone can put data into a 
signature without having to have it be part of the standard -- without 
having to get a consensus on it.

If we put this in the standard, but define it to be a notation of 
"rfc3156":{y|n} (or some other syntax) then we've done exactly what 
David proposed, but improved his proposal by making it bigger and 
harder to parse.

If the answer to the proposal is "put it in a notation" then to me that 
is implicitly saying it should not be part of the standard; it should 
be handled in an ad-hoc manner. That's a fine answer. If the answer to 
the proposal is that it should be in the standard, than a syntax like 
David's is the correct way.

I don't hear a consensus for putting this in. If other people want to 
use notations for an ad-hoc implementation, great.

	Jon

---

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
Date: Fri, 23 Apr 2004 08:56:18 +0200

[text reordered to take the interesting bits to the top]

> use notations for an ad-hoc implementation, great.

Reviewing the thread, I see 
 - Ian proposing not to add this issue to OpenPGP
 - David originally bringing up the matter and later:
|    I think there is consensus that such a flag should not be set in
|    the "features" subpacket.  There seemed to be at least some
|    consensus that  such a flag would be better placed in a "notation"
|    subpacket.  
 - Will describing a hack used by the PGP, Inc. folks.
 - Holger speaking out against a flag, in favour of the notation.

Thus I think consesus is more or less not to include this topic in 
OpenPGP. The open questions would be
 - if this topic should be put into an RFC as a notation in IETF name 
space, is this WG on-topic for this? (I think probably yes.)
 - who does the work? (I might be persuaded to write the RFC, if 
somebody with IETF experience helps.)
 - is it worth it? (I still believe that the chances for MUAs to 
actually implement this are slim. Any MUA developers here?)

(Obviously, I won't be offering my time to write the RFC if no MUA will 
ever implement it. I don't have the time to dig into MUA developing 
anytime soon, though.)

=========== 
> signature without having to have it be part of the standard --
> without having to get a consensus on it.

Right, insofar as it concerns the OpenPGP standard.

I think you misunderstand me. The main objection I see is that starting 
such application specific flags into the standard will bloat it - can 
we have bits for OpenPGP applications in IRC or instant messaging 
systems, too, please?

By using a notation without '@' in the name (IETF reserved namespace) we 
get a way to leave this out of the OpenPGP standard, and have the 
possibility to standardize this in another RFC.

[...]
> If the answer to the proposal is "put it in a notation" then to me
> that is implicitly saying it should not be part of the standard;

I believe I was saying this explicitly, not just implicitly.

> it 
> should be handled in an ad-hoc manner.

No, it should be standardized (as, presumably, all notations using the 
IETF reserved namespace should be), but the standard should not be part 
of OpenPGP.
[...]

Greetings
- -- vbi

- -- 
Available for key signing in Zürich and Basel, Switzerland
                    (what's this? Look at http://fortytwo.ch/gpg/intro)

---

From: Len Sassaman <[email-masked]>
Date: Sat, 24 Apr 2004 09:59:33 -0700 (PDT)

> having to get a consensus on it.

Agreed. This was my reason for bringing it up in the first place -- I
think that, without a means in OpenPGP for specifying the MIME preference,
this is what PGP Universal *should have* done.

> David proposed, but improved his proposal by making it bigger and

[snip]

> use notations for an ad-hoc implementation, great.

Okay. Then in the interest of achieving a consensus on this matter, I
hereby retract my suggestion that the OpenPGP/MIME preference be expressed
in the notation data field, and endorse David's proposal that we add an
additional subpacket flag. Are other backers of the notation-data proposal
willing to do the same? Please speak up.

The primary use of OpenPGP is email. While that may change in the future,
hypothetical concerns about instant messaging foo aren't presently an
issue. We have MUAs claiming "inline messages" are "old-format" and
deprecated, and we have users generating PGP/MIME messages which cannot be
processed by their recipients. Obviously there's a need for a means of
expressing this preference -- the GnuPG authors are asking for it, and the
PGP authors have already gone ahead with their own hack.

This additional flag adds minimal bloat to the standard, and addresses a
major usability problem with OpenPGP. I think it is a mistake to dismiss
this issue or require that yet another RFC be created to address it.

--Len.

---

From: "Brian G. Peterson" <[email-masked]>
Date: Sun, 25 Apr 2004 09:56:38 -0500

On Sat, 2004-04-24 at 11:59, Len Sassaman wrote:
> We have MUAs claiming "inline messages" are "old-format" and

I think this is the core problem that requires a solution.  RFC 3156
doesn't deprecate inline messages, and I would like to see a way of
making it clear that MUA's that refuse to decrypt/verify in-line
messages are *not* compliant with the OpenPGP standard set forth in
RFC2440bis because the can't verify/decrypt valid OpenPGP data.  

As an implementor, I don't care whether it is in the notation or in a
data packet.  notation is easier for human-parsing, and only marginally
more difficult for machine parsing.  A data packet cannot be parsed by a
human reader, so adoption will be slowed until at least GnuPG and
Commercial PGP release versions that support the new standard.  I think
that is the central trade-off.

Any future revision of RFC3156 will need to take into account
verification of message data or signatures outside of MUA's as well, but
that is another topic for a different thread.

Regards,

   - Brian

---

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
Date: Mon, 26 Apr 2004 09:04:21 +0200

> > I don't hear a consensus for putting this in. If other people want
> > to use notations for an ad-hoc implementation, great.
>
> hereby retract my suggestion that the OpenPGP/MIME preference be
> expressed in the notation data field, and endorse David's proposal
> that we add an additional subpacket flag. Are other backers of the
> notation-data proposal willing to do the same? Please speak up.

As I my role here is that of interested bystander and as I won't be the 
one to implement any of the proposed solutions, I say it's up to the 
people really working with this stuff.

greetings
- -- vbi

- -- 
Could this mail be a fake? (Answer: No! - http://fortytwo.ch/gpg/intro)

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: "Yes, I can handle PGP/MIME"
Date: Mon, 26 Apr 2004 09:04:21 +0200
Sender: [email-masked]

> > I don't hear a consensus for putting this in. If other people want
> > to use notations for an ad-hoc implementation, great.
>
> hereby retract my suggestion that the OpenPGP/MIME preference be
> expressed in the notation data field, and endorse David's proposal
> that we add an additional subpacket flag. Are other backers of the
> notation-data proposal willing to do the same? Please speak up.

As I my role here is that of interested bystander and as I won't be the 
one to implement any of the proposed solutions, I say it's up to the 
people really working with this stuff.

greetings
- -- vbi

- -- 
Could this mail be a fake? (Answer: No! - http://fortytwo.ch/gpg/intro)

Subject: Re: "Yes, I can handle PGP/MIME"
From: "Brian G. Peterson" <[email-masked]>
Reply-To: [email-masked]
To: OpenPGP <[email-masked]>
Date: Sun, 25 Apr 2004 09:56:38 -0500
Sender: [email-masked]

Regards,

   - Brian

Date: Sat, 24 Apr 2004 09:59:33 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: "Yes, I can handle PGP/MIME"
Sender: [email-masked]

[snip]

--Len.

To: Lutz Donnerhacke <[email-masked]>
Cc: [email-masked]
Subject: Re: Whither the 0x40 timestamp signature?
From: Florian Weimer <[email-masked]>
Date: Sat, 24 Apr 2004 11:48:06 +0200
Sender: [email-masked]

Lutz Donnerhacke <[email-masked]> writes:

> I do have an application for this type of signature without providing the
> full meaning of notary (0x50) signatures.
>
> There is a full blown enviroment which requires timestamping at users end
> without involving a real notary timestamping service. The German signature
> law contains a protocol error in proofing signatures of withdrawn keys. The
> only sound solution requires an additional timestamp of every signature. The
> law assumes that the sender is responsible for providing the timestamp.

SigG/SigV conformance of OpenPGP applications is not going to happen
(and is not even desirable IMHO).

RFC 2440bis should simply state that there are a few flags for which
future RFCs may specify semantics.  Consensus on this list seems to be
that RFC 2440bis should remain a format spec, and signature semantics
would clearly be beyond its scope.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk,
tiscali.cz, tiscali.it, voila.fr.

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: "Yes, I can handle PGP/MIME"
Date: Fri, 23 Apr 2004 08:56:18 +0200
Sender: [email-masked]

=========== 

[...]

Greetings
- -- vbi

- -- 

From: Jon Callas <[email-masked]>
Subject: Re: "Yes, I can handle PGP/MIME"
Date: Thu, 22 Apr 2004 12:12:05 -0700
To: OpenPGP <[email-masked]>
Sender: [email-masked]

	Jon

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups:  iks.lists.ietf-open-pgp
Subject:  Re: Whither the 0x40 timestamp signature?
Date: Thu, 22 Apr 2004 14:14:33 +0000 (UTC)
Organization:  IKS GmbH Jena
Lines: 22
NNTP-Posting-Host: taranis.iks-jena.de
NNTP-Posting-Date: Thu, 22 Apr 2004 14:14:33 +0000 (UTC)
Sender: [email-masked]

* Ian Grigg wrote:
> Lutz Donnerhacke wrote:
>> I do have an application for this type of signature without providing
>> the full meaning of notary (0x50) signatures.
>
> When you say "I do have ..." are you saying that this
> is in existence, or that you are proposing this as a
> potential future use of 0x40 sigs?

Only a potential future use. I'd only show a real world need for such things.

> some obscure sense, I think it's better to leave old
> uses to die, and allocate new codes to new purposes,
> even if close.

Ok. Remove it.

> Thirdly (as I mooted in a prior post) I think we should
> be seriously considering putting the RFC process into
> feature freeze.

Ack.

Date: Thu, 22 Apr 2004 08:13:07 -0400
From: Ian Grigg <[email-masked]>
To: Lutz Donnerhacke <[email-masked]>
CC: [email-masked]
Subject: Re: Whither the 0x40 timestamp signature?
Sender: [email-masked]

Lutz Donnerhacke wrote:

> I do have an application for this type of signature without providing the
> full meaning of notary (0x50) signatures.

When you say "I do have ..." are you saying that this
is in existence, or that you are proposing this as a
potential future use of 0x40 sigs?

[description of App elided]

> Should I provide detailed description, or should we remove the whole part?

There are three reasons against your suggestion.

One, that you seem to be defining a new app for an
apparently unused but similar feature.  If it is only
a similar application, then we'd want to show that
there are no extant uses of the allocated 0x40 code,
etc, so that we don't end up with any confusion.

(It's relatively ok for implementations to be confused,
but the standard should not be...)

(I guess it would be fine to *document* the prior use
of the feature, from code.)

Secondly, even if you could show that the old number
was out of use, I'd still suggest formatting a new
application with new bits and bobs, new meanings,
and new text.  Unless we are running out of bits in
some obscure sense, I think it's better to leave old
uses to die, and allocate new codes to new purposes,
even if close.

Thirdly (as I mooted in a prior post) I think we should
be seriously considering putting the RFC process into
feature freeze.  So if there is anything *new* about
this, such as a meaning, or an app still to be written,
then I'd say the onus would be on the proposer to
carefully make the case that this should go forward.

E.g., once in feature freeze, we should switch attention
to chopping deprecated and other dead-wood out there, and
to fixing grammer and spelling and whatnot, and thinking
about how it is that the darn thing gets finished.

iang

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: "Yes, I can handle PGP/MIME"
Date: Thu, 22 Apr 2004 13:34:46 +0200
Sender: [email-masked]

greetings
- -- vbi

- -- 

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups:  iks.lists.ietf-open-pgp
Subject:  Re: Whither the 0x40 timestamp signature?
Date: Thu, 22 Apr 2004 08:23:19 +0000 (UTC)
Organization:  IKS GmbH Jena
Lines: 50
NNTP-Posting-Host: taranis.iks-jena.de
NNTP-Posting-Date: Thu, 22 Apr 2004 08:23:19 +0000 (UTC)
Sender: [email-masked]

* David Shaw wrote:
> If the intent is that 0x40 is in fact a signature over a signature
> (and nothing else), then a simple fix is to change section 5.2.1,
> which currently says:
>
>     0x40: Timestamp signature.
>         This signature is only meaningful for the timestamp contained
> 	in it.
>
> Change to read:
>
>     0x40: Timestamp signature.
>         This signature is a signature over some other OpenPGP
> 	signature packet(s).  It is only meaningful for the timestamp
> 	contained in it.
>
> I'm not advocating that outcome.  I'm equally content to see it
> defined, marked for future use, or dropped.

I do have an application for this type of signature without providing the
full meaning of notary (0x50) signatures.

There is a full blown enviroment which requires timestamping at users end
without involving a real notary timestamping service. The German signature
law contains a protocol error in proofing signatures of withdrawn keys. The
only sound solution requires an additional timestamp of every signature. The
law assumes that the sender is responsible for providing the timestamp.

A simple (non notary) timestamp to be included consists of two values:
  - name of the timestamping service
  - value of the timestamp

Those values can be included in three ways:
  a) Defining (one or two) notation data packets to optionally include such
     a timestamp in every signature packet.
  b) Defining a 0x40 signature as hashing the refered signature, and both
     fields.
  c) Defining a 0x40 signature as hashing the refered signature and include
     the notation data packets from version a.

Variant a seems the most interesting one. Variant c extents this variant to
the possibility of timestamping a signature later (by an other person).

So I'd vote for defining a signature subpackets or two notation data
subpackets for providing (non notary) timestamping pruposes, and defining
the 0x40 signature type to as a hash over the whole signature subpacket
(followed by the normal signature process). It's recommented to include the
timestamp subpackets into every 0x40 signature.

Should I provide detailed description, or should we remove the whole part?

Date: Wed, 21 Apr 2004 19:32:00 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: "Yes, I can handle PGP/MIME"
Sender: [email-masked]

--Len.

From: Jon Callas <[email-masked]>
Subject: Re: Whither the 0x40 timestamp signature?
Date: Wed, 21 Apr 2004 13:07:15 -0700
To: OpenPGP <[email-masked]>
Sender: [email-masked]

It's really easy to remove this. Ian has a good reason to remove it. 
I'll take Ian and David proposing removing it, as 0x50 has more 
function and is better defined. Does anyone object strongly? Anyone, 
anyone?

	Jon

Date: Tue, 20 Apr 2004 11:12:56 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: "Yes, I can handle PGP/MIME"
Mail-Followup-To: OpenPGP <[email-masked]>
Sender: [email-masked]

David

Date: Tue, 20 Apr 2004 11:10:28 -0400
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Whither the 0x40 timestamp signature?
Mail-Followup-To: Jon Callas <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Apr 19, 2004 at 09:19:18PM -0700, Jon Callas wrote:
> >I'm not necessarily requesting that 0x40 be fleshed out and clarified:
> >I'd be just as content to see it dropped.  If, as I assume, the 0x40
> >is just the same as the 0x50 with a different (human) interpretation,
> >then perhaps we should just drop it.  If people want to assign human
> >interpretations to their signatures, let them use notations.
> >
> 
> As I remember, it stays there for the same reason that some other 
> seldom-to-never-used
> signature types are there: for backwards compatibility with their never 
> being used. They are there for the same reason there is old stuff in my 
> garage -- we hope to use it someday.
> 
> I'm not sure spring cleaning is warranted, but it's easy enough, if 
> people think so.

I'm not sure about spring cleaning, either.  Underspecified parts of
the standard trouble me, however.  They can't be implemented, and they
aren't marked "for future use" either.

The 0x40 signature was mentioned in 1991 as a signature over a
signature, but no information was given on how to actually make one.
2440 redefined the 0x40 as a "timestamp signature", but still no
information was given on how to make one, and it was no longer stated
to be a signature over a signature.

The 2440bis drafts add a little hint in that 0x40 gets a signature
target, which only makes sense if 0x40 has a signature as at least
part of its input.

I'll defer to the feeling of the WG on whether to drop or not.
However, if are going to keep 0x40 in the standard, we should at least
say how to make one or explicitly mark it for future use.

If the intent is that 0x40 is in fact a signature over a signature
(and nothing else), then a simple fix is to change section 5.2.1,
which currently says:

    0x40: Timestamp signature.
        This signature is only meaningful for the timestamp contained
	in it.

Change to read:

    0x40: Timestamp signature.
        This signature is a signature over some other OpenPGP
	signature packet(s).  It is only meaningful for the timestamp
	contained in it.

I'm not advocating that outcome.  I'm equally content to see it
defined, marked for future use, or dropped.

David

Date: Tue, 20 Apr 2004 07:54:28 -0400
From: Ian Grigg <[email-masked]>
To: [email-masked]
CC: Jon Callas <[email-masked]>, David Shaw <[email-masked]>
Subject: Re: Whither the 0x40 timestamp signature?
Sender: [email-masked]

Jon Callas wrote:
> 
>> I'm not necessarily requesting that 0x40 be fleshed out and clarified:
>> I'd be just as content to see it dropped.  If, as I assume, the 0x40
>> is just the same as the 0x50 with a different (human) interpretation,
>> then perhaps we should just drop it.  If people want to assign human
>> interpretations to their signatures, let them use notations.
>>
> 
> As I remember, it stays there for the same reason that some other 
> seldom-to-never-used
> signature types are there: for backwards compatibility with their never 
> being used. They are there for the same reason there is old stuff in my 
> garage -- we hope to use it someday.
> 
> I'm not sure spring cleaning is warranted, but it's easy enough, if 
> people think so.

If it can be marked with a SHOULD NOT use / deprecated
then that would be good.  More spring cleaning is better.
OpenPGP's incessant algorithmic messiness slows its migration.

(a general comment, not specific.  for clarification I
have no clue as to the particular number.)

iang

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Whither the 0x40 timestamp signature?
Date: Mon, 19 Apr 2004 21:19:18 -0700
To: David Shaw <[email-masked]>
Sender: [email-masked]

> I'm not necessarily requesting that 0x40 be fleshed out and clarified:
> I'd be just as content to see it dropped.  If, as I assume, the 0x40
> is just the same as the 0x50 with a different (human) interpretation,
> then perhaps we should just drop it.  If people want to assign human
> interpretations to their signatures, let them use notations.
>

As I remember, it stays there for the same reason that some other 
seldom-to-never-used
signature types are there: for backwards compatibility with their never 
being used. They are there for the same reason there is old stuff in my 
garage -- we hope to use it someday.

I'm not sure spring cleaning is warranted, but it's easy enough, if 
people think so.

	Jon

Date: Mon, 19 Apr 2004 20:49:20 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Whither the 0x40 timestamp signature?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

When we defined the 0x50 notary signature, the old 0x40 from 1991 was
the insipration for it.  0x40 was defined in 1991 as more or less what
the 0x50 sig is defined for today.  Now we have both the 0x40 and
0x50, and the 0x40 seems rather underdefined to me.

For starters, there are no hashing rules specified for it, so how do
you make one?  Since both the 0x40 and 0x50 get a target subpacket,
one could infer that they are similar, but there is nothing concrete.

I'm not necessarily requesting that 0x40 be fleshed out and clarified:
I'd be just as content to see it dropped.  If, as I assume, the 0x40
is just the same as the 0x50 with a different (human) interpretation,
then perhaps we should just drop it.  If people want to assign human
interpretations to their signatures, let them use notations.

David

From: Jon Callas <[email-masked]>
Subject: Re: "Yes, I can handle PGP/MIME"
Date: Mon, 19 Apr 2004 14:20:58 -0700
To: OpenPGP <[email-masked]>
Sender: [email-masked]

	Jon

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: [email-masked]
Subject: Re: "Yes, I can handle PGP/MIME"
Date: Mon, 19 Apr 2004 10:01:42 +0200
Sender: [email-masked]

--Boundary-02=_md4gAyUtQZ+KDKp
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

> that PGP/MIME might have a chance becoming a new standard (*).

Won't solve the problem for those who like to sign their mail per=20
default - the problem is not people who are aware of OpenPGP (those=20
usually know the PGP/MIME problem when they use MSOE, which in my=20
experience is quite rare anyway.) The problem is people who do not know=20
anything and do not care about OpenPGP (or any other form of email=20
protection.) They won't be ready (or able) to install something on=20
their machine to be able to read my mail.

cheers
=2D- vbi

=2D-=20

--Boundary-02=_md4gAyUtQZ+KDKp
Content-Type: application/pgp-signature
Content-Description: signature

--Boundary-02=_md4gAyUtQZ+KDKp--

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: [email-masked]
Subject: Re: "Yes, I can handle PGP/MIME"
Date: Mon, 19 Apr 2004 09:57:19 +0200
Sender: [email-masked]

--Boundary-02=_fZ4gAZtljhBcduX
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 16 April 2004 17.09, you wrote:
> > go[...]=20

> hacks and bits.=20

Yep, fully agree. Perhaps you've not read my first mail in this thread:=20
I feel this bit to be unnecessary, IMHO notation data was invented=20
exactly for cases like this.

cheers
=2D- vbi

=2D-=20
P'tang!

--Boundary-02=_fZ4gAZtljhBcduX
Content-Type: application/pgp-signature
Content-Description: signature

--Boundary-02=_fZ4gAZtljhBcduX--

Date: Fri, 16 Apr 2004 17:46:50 +0200
From: Holger Sesterhenn <[email-masked]>
Organization: Utimaco Safeware AG, NL Aachen
To: [email-masked]
Subject: Re: "Yes, I can handle PGP/MIME" 
Sender: [email-masked]

Hi,

Best Regards,

Holger Sesterhenn
---

Date: Fri, 16 Apr 2004 11:09:57 -0400
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: Re: "Yes, I can handle PGP/MIME"
Sender: [email-masked]

iang

Date: Fri, 16 Apr 2004 10:56:52 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: "Yes, I can handle PGP/MIME"
Mail-Followup-To: [email-masked]
Sender: [email-masked]

David

Date: Fri, 16 Apr 2004 10:52:28 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: "Yes, I can handle PGP/MIME"
Mail-Followup-To: [email-masked]
Sender: [email-masked]

David

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: [email-masked]
Subject: Re: "Yes, I can handle PGP/MIME"
Date: Fri, 16 Apr 2004 15:25:29 +0200
Sender: [email-masked]

[no cc:s, please]

cheers
- -- vbi

- -- 

Date: Fri, 16 Apr 2004 08:47:09 -0400
From: Ian Grigg <[email-masked]>
To: [email-masked]
CC: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
Subject: Re: "Yes, I can handle PGP/MIME"
Sender: [email-masked]

To add to that,

iang

Date: Fri, 16 Apr 2004 03:22:37 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: Will Price <[email-masked]>
Cc: [email-masked]
Subject: Re: "Yes, I can handle PGP/MIME"
Sender: [email-masked]

--Len.

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: [email-masked]
Subject: Re: "Yes, I can handle PGP/MIME"
Date: Fri, 16 Apr 2004 12:08:45 +0200
Sender: [email-masked]

[...] 

greetings
- -- vbi

From: Will Price <[email-masked]>
Subject: Re: "Yes, I can handle PGP/MIME"
Date: Fri, 16 Apr 2004 02:24:38 -0700
To: [email-masked]
Sender: [email-masked]

- --

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: [email-masked]
Subject: Re: "Yes, I can handle PGP/MIME"
Date: Fri, 16 Apr 2004 09:52:03 +0200
Sender: [email-masked]

greetings
- -- vbi

- -- 

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: "Yes, I can handle PGP/MIME"
Date: Thu, 15 Apr 2004 15:21:46 -0700
To: David Shaw <[email-masked]>
Sender: [email-masked]

	Jon

Date: Thu, 15 Apr 2004 12:35:38 -0400
From: David Shaw <[email-masked]>
To: Kazu Yamamoto <[email-masked]>
Cc: [email-masked]
Subject: Re: "Yes, I can handle PGP/MIME"
Mail-Followup-To: Kazu Yamamoto <[email-masked]>, [email-masked]
Sender: [email-masked]

Section 5.2.3.3 says:

David

Date: Fri, 16 Apr 2004 01:22:32 +0900 (JST)
To: [email-masked]
Cc: [email-masked]
Subject: Re: "Yes, I can handle PGP/MIME"
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

Interesting.

--Kazu

Date: Thu, 15 Apr 2004 11:46:56 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: "Yes, I can handle PGP/MIME"
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Proposed text:

to:

David