Re: Revising RFC 2015 (was: OpenPGP agenda for Dec 7)

[Michael Elkins <Michael_Elkins@xxxxxxx>]

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