ietf-openpgp
[Top] [All Lists]

Re: OpenPGP mail/news header

2005-01-16 09:04:30

On Sunday 16 January 2005 09:38 am, Simon Josefsson wrote:
"Brian G. Peterson" <brian(_at_)braverock(_dot_)com> writes:
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.

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:

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.

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.  
<...>
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.

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.  

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.  

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.

Regards,

  - Brian