Simon Josefsson wrote:
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.
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.)
I'd be disappointed if IETF approved a standard that implied use of
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.
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.
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.
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.
Yes, but we are in the world of standardising
practice, not hopes and desires.
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/