Subject: OpenPGP mail/news header

From: Simon Josefsson <[email-masked]>
Date: Sat, 08 Jan 2005 00:08:28 +0100

Hello.

Atom and I would appreciate your thoughts on the following document.

http://www.ietf.org/internet-drafts/draft-josefsson-openpgp-mailnews-header-00.txt

For a few references to earlier discussions on this proposal, see:

http://josefsson.org/openpgp-header/

(Alas, some of the links are not working, due to problems with gmane.)

Thanks.

---

From: Jon Callas <[email-masked]>
Date: Tue, 11 Jan 2005 16:29:00 -0800

I have some comments:

* We're deprecating V3 keys. You should either not mention them, or 
mention that they're deprecated.

On the other hand, you could just punt the whole issue by allowing a 
fingerprint to just be a string of hex digits. The length tells you 
what you need to know. If it's 128 bits in length, it's a V3 key; 160 
means V4. Even key ids are implicit based on length. (And with V4 keys, 
the key id is just a truncation of the fingerprint.)

* I also don't think you need the 0x. Just define it to be hexadecimal. 
The breaker is needed to know that literals in a programming language 
are of one base or another. Key IDs and fingerprints come in only one 
base. I know it's a MAY. Drop it anyway, because if it's there, an 
implementation has to handle both its presence and absence. It's merely 
noise.

* I understand why you have the url header, and think it's nice. But 
once you have that, (or the key is uniquely identified by key id or 
fingerprint) you don't need the algorithm, size, and created fields. 
These are merely comments all on their own, and if you have them there, 
you have to deal with what happens if they are wrong.

Let's suppose a URL points to my key and the header erroneously states 
that it's a DSA key, when it is in fact an RSA key. Now what? What if 
the creation time in the header is wrong? Since all that information is 
in the key itself, better to just get it from the key.

So to answer the question in section 6, I think you should drop them.

* I think the other open question you have, as to whether someone wants 
MIME encodings or not is much more important. At PGP, we're starting to 
code that into the certificates themselves, so the encryption mechanism 
can do the right thing.

	Jon

---

From: "Brian G. Peterson" <[email-masked]>
Date: Sun, 16 Jan 2005 08:14:54 -0600

On Sunday 16 January 2005 05:04 am, Simon Josefsson wrote:
> Jon Callas <[email-masked]> writes:
> I realize it is a big issue, and potentially a contentious one.
>
> I'd hate to see disagreement on this part stop the document, though,
> so if consensus on this matter cannot be reached, I think we should
> simply drop it.

I would very much like to see the approach that Jon and Hal have outlined of 
putting the preference in a notation packet on the key self signature be put 
into the RFC, and made official.

This issue is extremely important, and the proposed solution is well thought 
out, and easy to understand and implement.  Lack of guidance on this issue in 
the standard has already led to unnecessary incompatibilities between mail 
implementations.  Let's get that resolved with the new standard.

Regards,

  - Brian

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 16 Jan 2005 17:58:34 +0100

"Brian G. Peterson" <[email-masked]> writes:

> My concern with a 'supports' token is that this is probably/potentially 
> controlled by the MUA, not the user.

I'm not sure I agree with this view.

I believe OpenPGP should be an ultimately user controlled field, much
like From/To/Reply-To/Newsgroups etc are ultimately user controlled
fields.

> This may (already has?) provide a loophole to MUA implementations
> that don't want to support inline/partitioned.  I'm very much in
> support of a user preference notation packet, because this puts the
> control in the hands of the key holder, and implies that MUA's
> SHOULD (RFC language intentional here) support partitioned and mime.

Oh.  It seems we do disagree.

I believe that inline/partitioned should never be recommended by any
RFC, at least without more specification.  I believe RFCs should
clearly recommended against its use in e-mail because we have PGP/MIME
that, to my knowledge, solve all known problems, if implementors were
to actually support it.  RFC 2440 does this correctly.

A question was raised earlier in this WG why 2440bis do not include
the same text, but I'm not sure there was consensus declared.

I'd be disappointed if IETF approved a standard that implied use of
PGP in e-mail in any other way than PGP/MIME.

If you are seriously proposing to make inline/partitioned a standard
scheme for PGP in e-mail, you should describe how it should be
implemented.  I have experience with the inline style, and
non-deployed experience with the "partitioned"-style.  The problems
that need to be addressed to make this a serious alternative is RFC
1991-compatibility wrt dash-escaping, interaction with non-ASCII (both
in bodies and PGP headers), trailing white space interaction with
format=flowed, interaction with QP and '-' and '=' in the PGP armor.

> I'm not opposed to a 'supports' Header in the email headers.  I am most 
> concerned with strengthening the language on user preferences in the key self 
> signature, as I think lack of clarity has been a big problem.  

Agreed.  More clarity is needed.

> As an MUA implementor, I'm very concerned with the poor interoperability 
> caused by the current lack of clarity, so I want this strengthened for the 
> benefit of the users, who shouldn't need to worry too much about this if the 
> standard is clear.

Right.

If everyone implemented PGP/MIME we wouldn't have this problem.

I believe that standardizing inline/partitioned may turn out to be
more painful than implementing PGP/MIME.

To be clear: I'm not against the notation packet idea.  I think it is
a great idea.  But it shouldn't imply that the "partitioned" approach
is something which the IETF recommend.  It should be seen as a way to
smooth the upgrade path into PGP/MIME.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 16 Jan 2005 16:38:43 +0100

> implementations.  Let's get that resolved with the new standard.

I agree completely.

The OpenPGP: header does not yet include a "supports" token, so this
is an open issue.  I wasn't aware of Jon and Hal's proposal when I
mentioned "supports" as an open question, nor when we discussed this
problem with MUA implementors earlier.

Perhaps we can get some input on the viability of a "supports"-token
in the OpenPGP-header by resolving the following question:

Will the proposed notation packet scheme be sufficient to tell whether
MUAs should use PGP/MIME, plaintext PGP, or the "partitioned" scheme,
in every situation that MUA users care about?

For encryption, the question seems clear.  You need the key to
encrypt, and the notation packet tell you which PGP-in-mail style to
use.

For signing, the answer is not so clear to me.  I'm not sure there are
no situations where you want to send signed mail, but doesn't posses,
or care about, the recipients keys, but do wish to follow a loose
recommendation on which PGP-in-mail style to use.  In theory, for
signing, you might not even know who the recipients are, so you can't
inspect a notation packet.  But you may be sending mail to a mailing
list that require signed messages, that add 'OpenPGP: supports=mime'
to all posts to signal what kind of PGP-style to use.

Fundamentally, what I'm asking is whether the notation packet solve
all problems that a "supports"-tokens in the OpenPGP: header would.

If it does, then I don't think we shouldn't have a "supports"-token.

If it doesn't, then I don't see what harm it would cause by adding it,
and I'd probably would support adding it.

Thanks,
Simon

---

From: "Brian G. Peterson" <[email-masked]>
Date: Sun, 16 Jan 2005 10:04:28 -0600

On Sunday 16 January 2005 09:38 am, Simon Josefsson wrote:
>> I would very much like to see the approach that Jon and Hal have outlined
>> of putting the preference in a notation packet on the key self signature
>> be put into the RFC, and made official.
>>
>> This issue is extremely important, and the proposed solution is well
>> thought out, and easy to understand and implement.  Lack of guidance on
>> this issue in the standard has already led to unnecessary
>> incompatibilities between mail implementations.  Let's get that resolved
>> with the new standard.
>
> I agree completely.
>

My concern with a 'supports' token is that this is probably/potentially 
controlled by the MUA, not the user.  This may (already has?) provide a 
loophole to MUA implementations that don't want to support 
inline/partitioned.  I'm very much in support of a user preference notation 
packet, because this puts the control in the hands of the key holder, and 
implies that MUA's SHOULD (RFC language intentional here) support partitioned 
and mime.

> For signing, the answer is not so clear to me.  
<...>
> In theory, for signing, you might not even know who the recipients 
> are, so you can't inspect a notation packet.  But you may be 
> sending mail to a mailing list that require signed messages, 
> that add 'OpenPGP: supports=mime' to all posts to signal what 
> kind of PGP-style to use. 
>

The proposed 'supports' email header provides guidance on what the receiving 
MUA wants, the user preference provides guidance on what the user wants, and 
the sending MUA should follow the user preference.  The receiving MUA should 
be flexible enough to handle either the inline/partitioned or mime formats 
for both sending and receiving.  

Regards,

  - Brian

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 16 Jan 2005 12:04:37 +0100

> I have some comments:

Thanks for looking at it!

> mention that they're deprecated.

What would a suitable reference for that decision be?

> the key id is just a truncation of the fingerprint.)

This seems like a good solution.  Will there ever be a need to have
key id's of different length than 4, 8, 16 and 20 bytes?  The BNF now
reads:

id        := 4*HEXDIG / 8*HEXDIG / 32*HEXDIG / 40*HEXDIG

And I'm not certain it is a good idea to allow the flexibility of

id        := *HEXDIG

However, I have replaced the references to v3/v4 with:

   The length of the field imply the kind of key id, i.e., short or
   long form, or a v3 or v4 key.

   Note that each of the following examples includes a comment, which is
   optional.

   	    id=12345678 (short key ID)
   	    id=1234567890ABCDEF (long key ID)
   	    id=1234567890ABCDEF01234567890ABCDEF0123456 (v4 fingerprint)
   	    id=1234567890ABCDEF01234567890ABCDE (v3 fingerprint, deprecated)

> implementation has to handle both its presence and absence. It's merely 

I agree, I've dropped it.

> So to answer the question in section 6, I think you should drop them.

Thanks for this input.  I have been trying to understand why
algo/size/created are needed, but nobody has been able to explain it
to me.

The reason was supposedly that with v3 keys, you subject to something
called the 0xDEADBEEF attack, where I infer that keys can be created
easily with any given key id.  The attack is not possible with v4
keys.  Someone said the attack is harder for v3 keys if you also
compare the key size, key algorithm and creation time.

What nobody has explained to me is how much difficult the attack is.
If the attack is only slightly more difficult, I don't think it is
worth the added complexity in OpenPGP:.  However, if the attack is
completely avoided by comparing these fields, there may be some point
to it.  On the other hand, if v3 keys are deprecated, it might be
simpler to forget about all v3 issues.

Without understanding the motivation for size/algo/created, I'm in
favor of dropping them.

Thanks,
Simon

---

From: Ian G <[email-masked]>
Date: Sun, 16 Jan 2005 17:17:22 +0000

>What would a suitable reference for that decision be?

It's been debated on this list many times.  I
don't think there is a suitable single for
this.  Here's the summary of the issues that
I know of, but bear in mind that I am biased.

1.  V3 keys are subject to a few quirky security
issues.

2.  V3 usage is quite low.  I don't think this has
been tested properly, but we are talking in the
low 1-10% area.

3.  V3 architecture is old.  A rewrite is well
over due.  (Note that the same applies to the
V4 architecture which is now a good 8 years
old or so ;)

4.  Supporting both key types is a drain on
the implementors.  If they are supporting
old / dying key formats, they are not writing
other crypto code.

5.  As it is security code, the notion of clearing
out deadwood is always good.  Complexity
leads to security holes.  This is different to
the (say) Microsoft world where customer
compatibility is the important issue.  (hmmm,
maybe I need to revise that?  Nah...)

6.  Finally, deprecating the V3 in the standard
doesn't mean you can't support it.  By all means,
support it if you think there is some use for it.
Dropping it from the standard just means that
we are not telling all the implementors that
they *have* to support it.  So now, V3 can move
over to a market-driven retirement.  In practice,
I suspect it will take another 5 years before the
major apps drop support for it.

7.  Our decision not to support it in the Java
library is indicative of a small budget;  there's
no way we can do "it all".  I imagine a lot of
small implementors will think the same,
RFC2440bis is already so big that something
has to give.

Hmm... having written all that, I'm not sure
there is a case for keeping them above :)  I'll
let someone else write that.

iang
-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

---

From: "Brian G. Peterson" <[email-masked]>
Date: Sun, 16 Jan 2005 12:11:03 -0600

I'm changing the subject of my replay, to denote that UI think that this is a 
somewhat separate issue from whether the preference notation packets should 
be added to RFC 2440bis.

> PGP in e-mail in any other way than PGP/MIME.

Here's my issue with PGP/MIME (RFC 3156)  The PGP/MIME standard defines 
placing an email-specific Content-Type header inside the section covered by 
the signature, making verification of binary content difficult outside of a 
mail client.  Further, almost all implementations generate a single signature 
across all parts, generating a signature for the entirety of the 
email-specific MIME structure, and not signing individual attachments.  I 
believe that this is a serious flaw in RFC 3156.

One of the users of the GPG Plugin for Squirrelmail the I am the primary 
implementor of is human rights workers (via the CryptoRights Foundation).  
For evidentiary reasons in this implementation, it is critical that each 
binary attachment (documents, pictures, whatever) have independently 
verifiable signatures.  The 'partitioned' method accomplishes this, by 
encrypting/signing each part, so that each part is independently 
decryptable/verifiable, even outside of an MUA.  I think that independent 
verification of a signature on each part, and a signature across the whole, 
are a feature that should be required of any email implementation (although 
this is a bit out of scope for the current discussion of preference 
notations).

> format=flowed, interaction with QP and '-' and '=' in the PGP armor.

Many MUA's have chosen to not support inline or partitioned methods of 
Encrypting/Signing mail content.  This seriously limits interoperability, and 
I think that this needs to be addressed in RFC 2440bis (because that is what 
is under discussion now) and in any future revision of RFC 3156.

> The problems that need to be addressed to make this a serious 
> alternative is RFC 1991-compatibility wrt dash-escaping, 
> interaction with non-ASCII (both in bodies and PGP headers), 
> trailing white space interaction with format=flowed, 
> interaction with QP and '-' and '=' in the PGP armor. 

I do not believe that support for partitioned in the notation packet implies 
RFC 1991 compatibility.  We have decided that 2440bis will obsolete RFC 1991, 
if I recall the concensus of the group correctly.  We have also otherwise 
addressed dash-escaping and trailing whitespace issues.  I think that a 
'partitioned' scheme is the only option currently available to implementors 
who require independent verification of each part, as well as verification of 
the whole.

Regards,

  - Brian

---

From: Ian G <[email-masked]>
Date: Sun, 16 Jan 2005 18:43:36 +0000

>the same text, but I'm not sure there was consensus declared.

If I follow you, you are saying that 2440bis should
recommend email as being done in a certain way
(PGP/MIME?).  But that way is specified in another
RFC which is higher layer.  This is the normal way
of things, the lower layers specify things like data
packet preparation and key issues, and the higher
layer applications sort out transport issues in their
medium.

(What could be said is that the ascii-armoured form
would be better off in another RFC.  But I think it
is a bit of a sidetrack at this late stage of the game,
the historical circumstance is that PGP includes
a legacy method of ascii-armouring for email and
other things, and I don't think there is much support
for removing it ... which would be far preferable to
muddying RFC2440bis with PGP/MIME.)

>PGP in e-mail in any other way than PGP/MIME.

Other than the inclusion of the ascii-armouring
thing, I don't think there is a need to specify
email at all in RFC2440bis.  PGP is a way of
creating messages for sending, and it cares
not whether the transport is over email or
over IM or over pigeon post.

>format=flowed, interaction with QP and '-' and '=' in the PGP armor.

The RFC is pretty much fixed in the large.  I
don't think it does what you say:  propose a
standard scheme for email.

Having said that, there is some scope for
including some warnings, seeing as the
scheme is in there.

>If everyone implemented PGP/MIME we wouldn't have this problem.

Yes, but we are in the world of standardising
practice, not hopes and desires.

---

From: David Shaw <[email-masked]>
Date: Sun, 16 Jan 2005 13:39:42 -0500

> And I'm not certain it is a good idea to allow the flexibility of

I like the simplicity and flexibility of this.  The key ID field is a
message from the OpenPGP user to the world.  Specifying that the ID
must be a particular length doesn't really help anyone, since it is up
to the recipient to decide how the key ID is going to be handled
anyway.  Plus, someday we'll have a v5 key.  Chances are it won't be
40 hex digits long.

> compare the key size, key algorithm and creation time.

There are actually two different attacks.  It is trivial to create a
V3 key with any key ID you like.  That's the 0xDEADBEEF attack.  There
is a different attack altogether (but lacking a catchy name), which is
against the V3 fingerprint.  Since the V3 fingerprint consists of the
RSA values n and e, but not their lengths, you can do tricks with
'sliding' bits from one into the other.  The end result is a
constructed V3 key with the same fingerprint as the 'victim' V3 key.
The trick is that such a constructed key will always have a different
size than the original key.

> Without understanding the motivation for size/algo/created, I'm in

Even understanding the motivation, I'm in favor of dropping them.  V3
keys are deprecated.  If someone desperately needs to use V3 keys, and
desperately needs to include their key size in the OpenPGP header to
foil this attack, well, there is already a way to include arbitrary
free-text comments in the header.

David

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 16 Jan 2005 20:21:20 +0100

Ian G <[email-masked]> writes:

> (PGP/MIME?).

It may be a good idea, yes.  Having more than one way to do things is
generally bad.

> But that way is specified in another RFC which is higher layer.
> This is the normal way of things, the lower layers specify things
> like data packet preparation and key issues, and the higher layer
> applications sort out transport issues in their medium.

If that way worked, then it would be fine, but it seems that many
organizations are not using PGP/MIME but rather use inline or
"partitioned".  I doubt they all do it because they have considered
PGP/MIME and rejected it on a technical basis, although Brian's post
made me recall that there are some unaddressed matters in PGP/MIME as
well.

> muddying RFC2440bis with PGP/MIME.)

Continuing this hypothetical discussion, perhaps PGP/MIME should have
been just that ASCII-armor layer on top of a binary PGP format.  The
ASCII limitation come from the e-mail world, after all, if I
understand correctly, so it make sense for the e-mail world to handle
it, instead of the PGP format itself.

I think this would also make things more similar between OpenPGP and
CMS, and how CMS is used in e-mail.

However, all this is probably not a practical course of action.

> over IM or over pigeon post.

However, there is a lot of confusion about how to use OpenPGP in
e-mail.  If there is an opportunity to resolve that confusion by
adding text to 2440bis, then I think it would help.

> including some warnings, seeing as the

I didn't mean 2440bis would standardize "partitioned".  For what it's
worth, I think it should go into a separate document, much like
PGP/MIME.  Specifying a notational packet that indicate implementors
should support a specific scheme that isn't specified appear to invite
interoperability problems.

>>> As an MUA implementor, I'm very concerned with the poor
>>> interoperability caused by the current lack of clarity, so I want
>>> this strengthened for the benefit of the users, who shouldn't need
>>> to worry too much about this if the standard is clear.
>>>    
>>>
>>
>>Right.
>>

But when existing practice are problematic for users, it needs to be
improved, and I have viewed PGP/MIME as being an improvement like
that.

Regards,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 16 Jan 2005 20:26:54 +0100

> this is a bit out of scope for the current discussion of preference 

That was a good summary of issues with PGP/MIME.  I hadn't been fully
aware of these before, although now that you make them clear, I recall
several situations (think proxies) where this has been an issue.

> is under discussion now) and in any future revision of RFC 3156.

Or a separate document.  I agree.  I think the reason people don't
implement inline/partitioned is that there simply is no specification
for how to do it.  And there are a number of complicated things to
solve to implement it.  Whether to apply the non-ASCII processing in
MIME before or after the PGP layer is one open issue.  If QP is
applied before PGP, it is also unclear how to deal with escaping of
'=' for QP in the PGP CRC24 field.

Regards,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 16 Jan 2005 21:00:26 +0100

> anyway.  Plus, someday we'll have a v5 key.  Chances are it won't be

Ok, I'm convinced.

> size than the original key.

Thanks for explaining this, I finally understand.  So it seems
"created" never help to mitigate any attacks.  Only size does (and
from your description, perhaps also algo).

> free-text comments in the header.

Right, unless someone has a good argument to keep them, I believe they
will be dropped.

Thanks,
Simon

---

From: Konrad Rosenbaum <[email-masked]>
Date: Mon, 17 Jan 2005 07:03:11 +0100

> from your description, perhaps also algo).

Actually: only V4 helps. Everything else with V3 can (theoretically, as 
unlikely as it is) be changed during transmission (length, timestamps, 
etc.pp.) without the receipient noticing, since the fingerprint does not 
change (well, with recent advances against MD5 even the V3 key material 
cannot be considered secure any more).

	Konrad

---

From: Werner Koch <[email-masked]>
Date: Mon, 17 Jan 2005 10:47:12 +0100

> believe that this is a serious flaw in RFC 3156.

That is not a flaw in rfc 3156 but in the implementations. The same UI
requirements hold true for that partitioned format.

Kmail for example allows to select the attachments to be signed. By
using forwarding and combining messages you are able to select
different signatures with any fully MIME aware MUA.

> decryptable/verifiable, even outside of an MUA.  I think that independent 

Again, that is a matter of the tools and not of the protocol.  In fact
it is not that hard to verify PGP/MIME with a simple script and the
usual mime tools.  The real challenge is to present the signature
status in an appropriate way to the user.

> are a feature that should be required of any email implementation (although 

Kmail as well as Mutt allow exactly for this.  Any MUA with proper
MIME and OpenPGP support will handle this.

> is under discussion now) and in any future revision of RFC 3156.

There is only one MUA which causes all the problems and that one is
notriously known for its security flaws.  MUAs not doing PGP?MIME do
this to be compatible to that one other MUA.

> RFC 1991 compatibility.  We have decided that 2440bis will obsolete RFC 1991, 

Please recall that 1991 is informational and not on the standard
track.

> who require independent verification of each part, as well as verification of 

Wrong.  The only reason is allowing plugins for Outlook.  I don't
expect that Cryptorights suggests the use of that MUA.

I am not against these preferences but they should not in any way
endorse non-PGP/MIME.  Keeping that off the standard and using agreed
on notation data is thus the better decision.  For technical reasons
I'd like to see it done in the same way as the preferences but I fear
that this will lead to practically abolish PGP/MIME.

Salam-Shalom,

   Werner

---

From: "Brian G. Peterson" <[email-masked]>
Date: Mon, 17 Jan 2005 08:07:59 -0600

> different signatures with any fully MIME aware MUA.

Your examples serve to show the flaw in the RFC. Because the RFC does not 
specify that each attachment should be signed as a digital file with a 
detached signature to allow external verification, the user is required to do 
a lot of work that should be unnecessary.

A signature across all the MIME parts to verify the entire email structure, 
plus separate detached signatures on each *attachment* (without the 
unecessary Content-Type header that RFC 3156 unwisely requires) would allow 
for simple signature verification of the signature on any attachment, using 
any OpernPGP compliant tool, and requiring no MIME knowledge for the 
verifier.

RFC 3156 does not forbid this kind of behaviour, but it does not require it 
either, so most implementations have chosen to supply one signature across 
all the MIME parts, making verification outside of an email systems extremely 
difficult.  This is, in my opinion, a serious flaw in RFC 3156.

Partitioned is not much better, because it does, as you note, have UI 
difficulties in presenting the information to the user, verifying signatures 
on each individual part and across the whole.  Partitioned implementations 
currently have the advantage that the signatures on each attachment do not 
require a MIME compliant MUA/program/script to verify.  They are 
independently verifiable once detached from the MUA.  I just want that 
independent verification standardized in MIME implementations as well.
  
> status in an appropriate way to the user.

If each attachment were required to have an independently verifiable 
signature, then there would be no difficulty in doing so, and you wouldn't 
need MIME tools and technical knowledge outside the MUA to verify the 
detached signatures.

> > verification of a signature on each part, and a signature across the
> > whole, are a feature that should be required of any email implementation
> > (although
>

Because they chose to, because it is the right thing to do.  The RFC does not 
require it, which was my point.

> > Encrypting/Signing mail content.  This seriously limits interoperability,
> > and I think that this needs to be addressed in RFC 2440bis (because that
> > is what is under discussion now) and in any future revision of RFC 3156.
>
> > I do not believe that support for partitioned in the notation packet
> > implies RFC 1991 compatibility.  We have decided that 2440bis will
> > obsolete RFC 1991,
>
> > 'partitioned' scheme is the only option currently available to
> > implementors who require independent verification of each part, as well
> > as verification of
>
> Wrong.  

Inserting a MIME-specific Content-Header inside the boundaries of the 
signature is a *problem* for independent verification.  Removal of the 
unneeded Content-Header and MIME junk from attachments, and requiring 
separate signatures on attachments, would remove my complaint about RFC 3156.  
Some MUA implementors (KMail, Mutt, the GPG Plugin for Squirrelmail) do this 
already, because it is the right thing to do.  I just want to see the 
standard (a future revision of RFC 3156) support and require that. 
 
> The only reason is allowing plugins for Outlook.  I don't 

No, Cryptorights does not use Outlook internally, or recommend it to others 
where security is an issue.  However, many *recipients* of mail from human 
rights workers will undoubtedly be using MS Outlook.  Interoperability is in 
everyone's advantage, as I'm sure you agree.  Having the standard be clear on 
what is required for interoperability makes it far more likely than in the 
current state where the right thing to do is not the same as the minimum that 
the standard requires.

> on notation data is thus the better decision.  

It looks as though the PGP Corp folks have chosen to implement it not using 
the standard preferences model.  Perhaps Hal or Jon could comment on this, 
and indicate whether they would be willing to comment on that proposal: 
putting email preference data in the existing preferences packets on the key.
   
> For technical reasons 

I don't think that is the case.  I too would prefer to use PGP MIME with minor 
improvements on the standard to guide MUA implementors to do the right thing.

Regards,

  - Brian

---

From: Werner Koch <[email-masked]>
Date: Mon, 17 Jan 2005 17:43:13 +0100

> detached signature to allow external verification, the user is required to do 
PGP/MIME describes a MIME content type and trhat's it.  It does not
give guidelines on how users should write or sign mail; that is a
policy decision and not in the scope of a MIME.  

> all the MIME parts, making verification outside of an email systems extremely 
In most cases there is no need to separate signatures.  They only make
sense if you either receive and forward a signed attachment with a new
mail or you want to save the attackment independent of the mail.
That is an organizational issue and a technical one.  

> independent verification standardized in MIME implementations as well.

You need a pretty complicated tool to very the signature but don't
want to throw in a couple of lines for a tool for proper MIME parsing?
That is strange.  Go to any vendor or hacker and ask for an
appropriate tool; its easy build.
  
> unneeded Content-Header and MIME junk from attachments, and requiring 

It is not a problem but a MIME requirement.  Without the
content-header you have no way to identify the used charset.  Without
this infotrmation you are not able to display a document correctly -
it might even convey the wrong message: There are similar character
sets using the same encoding for the national currency symbol.  It
makes a lot of difference whether to talk about British Pound or USD.

It sometimes happens that you need to compile a message from different
sources where those message are not all in utf-8.  Indicating the
characterset is thus a requirement; you might not even be able to
recode all character set if you didn't install it or there are no 1-1
conversions possible.  And recoding would break the signature.

> standard (a future revision of RFC 3156) support and require that. 

Huh?  You mean they don't send a content-type if it defaults to
us-ascii?  Well, this is possible but in the majority of the world's
languages this does not work.

> the standard preferences model.  Perhaps Hal or Jon could comment on this, 

Which is the Right Thing to do; unless it is defined by the standard
they may only use the namespace reserved for private use.  

> improvements on the standard to guide MUA implementors to do the right thing.

MIME and PGP/MIME are a reality and both are good and usable standards;
used in all modern IETF protocols - not only for mail.  Its a bit
strange to hear comments against the use of MIME only from people
using almost only English and ASCII for there communication.  The
world is not anymore plain 7 bit; these times have fortunately gone. I
am not the only one glad to see that there are no more printouts like 
"foo_t fooÄ3Ü = ä 'ß', 1ö2, 'Ön' ü;" as common in the pre MIME days.

Shalom-Salam,

   Werner

---

From: Jon Callas <[email-masked]>
Date: Fri, 21 Jan 2005 14:36:55 -0800

On 16 Jan 2005, at 10:11 AM, Brian G. Peterson wrote:

> implies
> implementors

RFC 1991 was an informational RFC. It has no basis in anything. 2440 
tacitly replaces it, since 2440 is standards track and 1991 isn't. 1991 
is pre-OpenPGP history. Please don't drag it in. Thanks.

We had debates before about whether we should explicitly say we 
obsolete 1991. In the old days, you never said that standards-track 
replaced informational-track because informational is merely, well, 
informational. That interpretation has changed and we're now explicitly 
saying we replace something that was never a standard to begin with.

I'm happy to have documents say or not say whatever they need to say or 
not say. Whatever else we do, let's leave 1991 out of discussions. Like 
Mr. Cleese's parrot, it has joined the choir eternal, and only stands 
up if someone nails it to its perch.

	Jon

---

From: Ben Laurie <[email-masked]>
Date: Sat, 22 Jan 2005 12:57:46 +0000

Jon Callas wrote:
> We had debates before about whether we should explicitly say we obsolete 
> 1991. In the old days, you never said that standards-track replaced 
> informational-track because informational is merely, well, 
> Mr. Cleese's parrot, it has joined the choir eternal, and only stands up 
> if someone nails it to its perch.

If only - 1991 is the only place I could find that defines V2 keys, 
which I still see in the wild.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: David Shaw <[email-masked]>
Date: Sat, 22 Jan 2005 09:50:19 -0500

> >I'm happy to have documents say or not say whatever they need to
> >say or not say. Whatever else we do, let's leave 1991 out of
> >discussions. Like Mr. Cleese's parrot, it has joined the choir
> >eternal, and only stands up if someone nails it to its perch.
> 

That's not so - both 2440 in section 5.5.2, and 2440bis in section 14
define V2 keys as the same as V3 keys except for the version number.
Since both documents define V3 keys, that effectively defines V2 keys
as well.

David

---

From: Ben Laurie <[email-masked]>
Date: Sun, 23 Jan 2005 12:18:20 +0000

> Since both documents define V3 keys, that effectively defines V2 keys

So it does. I managed to miss that somehow. Thanks.

Cheers,

Ben.