From: Thomas Roessler <roessler(_at_)guug(_dot_)de>
Subject: Revising RFC 2015 (was: OpenPGP agenda for Dec 7)
Date: Tue, 1 Dec 1998 15:12:12 +0100
I don't want to go into the details, but just enumerate some basic
objections against Kazu Yamamoto's internet-draft document.
May I discuss with you?
- 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.
My draft clarifies, at least, version control between PGP and OpenPGP.
And your observation seems unfair to me. Please remember the history
of MIME. RFC 1521 doesn't provide any new information againt RFC 1341
(in your words). But I think it is worth publishing. Other exapmles
are found in IPv6, IPsec, and etc.
- 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.
Even if your observation is ture, it's a trade-off problem. If you
restrict an object to be signed 7bit, implementation of OpenPGP/MIME
will be very complex. You should compare this trade-off. Please don't
just say there are still some broken MTAs.
- 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.
This aslo sounds unfair to me. You at least agreed that ASCII armor
for multipart/signed is not friendly to PGP-aware but MIME-unaware
viewers.
Yes, PGP-aware but MIME-unaware viewers can decrypt PGP/MIME but the
content header must be removed by hand. Also, my draft says that
Open/MIME composers SHOULD generate PGP objects encoded with ASCII
armor.
- 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.
My draft says that "This conceptual model is descriptive and does NOT
impose any restrictions or requirements on implementations."
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.
I agree.
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.
Why don't you claim that the OpenPGP RFC shouldn't talk about
PGP/MIME?
- 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.
True.
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.
Sorry. I don't understand. Please expalin this more concretely?
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.
In my conceptual model, how the MIME composer know what kind of hash
algorithm is actually used?
And my proposal avoids 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.
Sorry. I don't understand this. Please explain this more concretely.
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.
Which part are you referring to?
- 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.)
Yes, this is a very interesting point. I also hope that someone will
propose a good one.
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).
Please do what you think is right. :)
--Kazu