Kazu Yamamoto wrote:
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.
It's no more complex than, e.g., forwarding messages encapsulated in
message/rfc822 attachments. Additionally, there have been
implementations of this. We had that discussion already, didn't we?
- 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.
That's why I've been talking about multipart/_encrypted_ above.
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?
Because it doesn't do so (beyond referencing RFC 2015)?
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?
Quite simple: The complete signed text is encrypted, including all
information on _how_ the signature was generated, and whether the
encrypted text was signed at all. Thus, including the micalg
parameter with encrypted bodies leaks encrypted content and should
be avoided.
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?
It asks the OpenPGP composer about it? Come on, Kazu, this is
trivial.
And my proposal avoids revising the PGP/MIME document every time a
new OpenPGP hash algorithm identifier is defined.
Yes, by not using it. Describing the mapping seems to be more
useful to me.
- 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.
6., first implementation note: "OpenPGP/MIME composers SHOULD
provide a user with a mechanism to select which secret key is used
for signature calculation."
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?
8.1.1 and 8.2. Requiring viewers to accept the format described in
8.1.1 is not necessary as it is a consequence of MIME semantics and
what has been described before. The point behind 8.1 as a whole is
that RFC 1847 and OpenPGP signed-then-encrypted bodies are to be
considered equivalent (and may be transformed into each other
according to RFC 2015 - this is missing from your text). 8.2
doesn't seem to be needed at all.
- 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.
Extend the multipart/signed mechanism to include multiple
signatures. Encapsulating them into yet another
multipart/alternative (?) part doesn't seem to make too much sense
to me.
tlr