Ian G <iang(_at_)systemics(_dot_)com> writes:
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?).
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.
(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.)
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.
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.
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.
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.
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.
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.
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