I don't want to go into the details, but just enumerate some basic
objections against Kazu Yamamoto's internet-draft document.
- This draft _duplicates_ the length of RFC 2015 without adding
essential new information. Instead, the wheel is re-invented from
the beginning. I'd prefer using an appropriately modified version
of RFC 2015.
- The author's assumption that most E-Mail gateways are 8-bit clean
nowadays is simply not true. There is an incredible amount of
broken gateways out there, so a revised version of 2015 should
stick with the conservative model of that RFC (and the Security
Multiparts standard) and not emit any 8-bit-data.
- The author's assumption about the non-importance of ASCII armor
with non-MIME aware user agents is wrong. More specifically, such
MUAs could still PGP-decrypt PGP/MIME encapsulated encrypted
messages. They won't be able to do this with MIME encoding of
these messages.
- The conceptual model (section 4) doesn't belong into this
document. MUAs _may_ decide to use it, but they may as well
decide to do something completely different, like true one-pass
processing using a complex state machine.
Nevertheless, it's correct and important to have in mind that a
PGP/MIME document should _not_ touch the definition of internals
of OpenPGP objects. Additionally, one should note that a PGP/MIME
document doesn't need to define any semantics which are a
consequence of other MIME documents or of the OpenPGP spec.
- The conceptual model the author describes leads to some funny
conclusions and even funnier "definitions" with respect to the
micalg parameter of multipart/signed body parts. There is no
proper definition of this parameter's value, and finally, we read
that it MUST be ignored. On the other hand, the micalg parameter
is _permitted_ with signed-then-encrypted body parts where it
doesn't belong: Adding it would mean leaking encrypted content.
I'd suggest a complete revision of this part of the draft in the
spirit of the Security Multiparts spec. (Alternatively, stick
with 2015's wording.)
The PGP/MIME document should note that there is a canonical
one-to-one mapping from OpenPGP hash algorithm identifiers to
PGP/MIME micalg parameters. This mapping should be desribed;
additionally, the currently defined micalg parameters should be
listed. Doing so will avoid revising the PGP/MIME document every
time a new OpenPGP hash algorithm identifier is defined.
- Some of the semantic notes (like permitting the user to select the
secret key to use for signatures) have nothing at all to do with
the definition of PGP/MIME content types. Other notes, e.g., that
there may be multiple levels of PGP/MIME encapsulation, are not
needed because they are a corollary from the general MIME semantics.
These notes should not be part of a PGP/MIME document.
- Interesting points, such as the question how to permit multiple
signatures, are left out. (This would be an extension of the
Secure Multiparts RFC and should be carefully considered.)
For these reasons, I'd like to porpose to start from RFC 2015 and
add the absolutely necessary points to that text. If there is
interest in following this direction of work, I'm willing to make up
a revised version of 2015 in ID format and post it to this mailing
list within the next two days, possibly even this evening (European
time).
tlr