On Tue, Dec 01, 1998 at 09:55:34AM -0800, Thomas Roessler wrote:
Kazu Yamamoto wrote:
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)?
If you are planning on doing a complete rewrite of RFC2015, it doesn't make
sense to reference it. The new document should be self contained in order
to avoid confusion.
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.
I agree. It MUST be fully specified if it is going to appear anywhere in
the spec, even if it is optional. It does not really seem all that likely
that new hash algorithms will come out so fast that updating the spec in
the future will be a problem. Right now we mostly see MD5 and SHA-1.
- 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."
I agree with this as well. OPENPGP/MIME should stick to discussing how
to encapsulate an OPENPGP protected message in MIME for transport. Anything
beyond that is out of scope for this 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.)
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.
I discussed this with Jim Galvin (one of the Security Multiparts authors)
a while back, and his take on it was that Security Multiparts does not
prevent you from changing the "signature" portion to be a multipart/mixed
which could contain various signature types. Example:
Content-Type: multipart/signed; boundary=foo;
micalg=openpgp-sha1,openpgp-md5; protocol="mutipart/mixed"
--foo
Content-Type: text/plain
This is the signed data portion.
--foo
Content-Type: multipart/mixed; boundary=bar
--bar
Content-Type: application/pgp-signature
Content-Description: signature #1
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
--bar
Content-Type: application/pgp-signature
Content-Description: signature #2
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
--bar--
--foo--
me