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

From: Thomas Roessler <[email-masked]>
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.

- 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

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Wed, 02 Dec 1998 01:32:08 +0900

From: Thomas Roessler <[email-masked]>
Subject: Revising RFC 2015 (was: OpenPGP agenda for Dec 7)
Date: Tue, 1 Dec 1998 15:12:12 +0100

> objections against Kazu Yamamoto's internet-draft document.

May I discuss with you?

>   the beginning.  I'd prefer using an appropriately modified version

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.

>   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.

>   messages.  They won't be able to do this with MIME encoding of

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.

>   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."

>   of OpenPGP objects.  

I agree.

>    Additionally, one should note that a PGP/MIME

Why don't you claim that the OpenPGP RFC shouldn't talk about
PGP/MIME?

>   that it MUST be ignored.  

True.

>   On the other hand, the micalg parameter

Sorry. I don't understand. Please expalin this more concretely?

>   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.

>   the definition of PGP/MIME content types.  

Sorry. I don't understand this. Please explain this more concretely.

>   Other notes, e.g., that

Which part are you referring to?

>   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.

> list within the next two days, possibly even this evening (European

Please do what you think is right. :)

--Kazu

---

From: Thomas Roessler <[email-masked]>
Date: Tue, 1 Dec 1998 18:55:34 +0100

Kazu Yamamoto wrote:

> 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?

>>   with non-MIME aware user agents is wrong.  More specifically,
>>   such MUAs could still PGP-decrypt PGP/MIME encapsulated encrypted

> for multipart/signed is not friendly to PGP-aware but MIME-unaware

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

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.

> 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.

> 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."

> 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.

> Yes, this is a very interesting point. I also hope that someone will

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

---

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 01 Dec 1998 15:21:38 -0500

In <[email-masked]>, on 12/01/98 
   at 09:52 AM, Kazu Yamamoto (山本和彦) <[email-masked]> said:

>    There are two ways to support multiple signatures.  One is storing
>    them in an OpenPGP object.  The other is storing a multipart/*
>    object in the second part.  Such functionality is outside the scope
>    of this memo.

Hi,

Just reading through the ID here and I would really like to see the functionality of multiple signatures added. There are several scenarios where multiple signatures per data object would be useful and it would be helpful to have this outlined so there is compatibility between the openpgp apps in processing such messages.

I can write something up on it after I have gone through the complete ID.

Thanks,

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
---------------------------------------------------------------

---

From: Michael Elkins <[email-masked]>
Date: Tue, 1 Dec 1998 17:15:18 -0800

> 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.

> Yes, by not using it.  Describing the mapping seems to be more

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.

> 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.

> multipart/alternative (?) part doesn't seem to make too much sense

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

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Wed, 02 Dec 1998 22:07:52 +0900

From: "William H. Geiger III" <[email-masked]>
Subject: Re: OpenPGP agenda for Dec 7
Date: Tue, 01 Dec 1998 15:21:38 -0500

> Just reading through the ID here and I would really like to see the
> functionality of multiple signatures added. There are several
> scenarios where multiple signatures per data object would be useful
> and it would be helpful to have this outlined so there is
> compatibility between the openpgp apps in processing such messages.
>

OK. Let me give you historical information on such efforts.

I wrote a multi-signature extension for PGP/MIME and submitted to
IETF. Since it has been expired, I put it on web.

	http://pgp.iijlab.net/draft-kazu-pgpmime-multisig-00.txt

Then, when the ietf-pgp-mime ml was active, Dave Del Torto worte a
revision of RFC 2015, called P/MIME. This draft was not submitted to
IETF but sent the ML only. I also put this draft on web (I'm very
sorry if this is agaist Dave's intentional.)

	http://pgp.iijlab.net/pmime

Both approaches are based on multipart/*. I would ask William to
compare both the multipart/* approach and the PGP packet approach.
(e.g. the multipart/* approach can handle both PGP/MIME and S/MIME
signature at one but the latter can't.)

My experience says that the most difficult point is how to define
semantics of multiple signatures. (e.g. if verification of the first
signature succeeds and that of the second fails, how can we treat
this?)

--Kazu

---

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 02 Dec 1998 12:29:45 -0500

In <[email-masked]>, on 12/02/98 

>signature succeeds and that of the second fails, how can we treat

Well this is going to depend on how the signatures are being used.

Example #1

We have a contract that 3 people need to sign off on. For the contract to be valid all three signatures must be valid.

Example #2 **

We have a memo that is being circulated through the office. After each person reads it they must sign off on it verifying that the memo has been read. In this case a failure of one signature is a minor issue and can be resolved by generating a new signature.

Example #3

A message posted to a public forum is signed with both the authors RSA key and his DSA key to resolve compatibility issues between the various versions. The validity of the message will depend on the capabilities of the verifiers software (if one of the 2 signatures fail).

As you can see we no longer have the black and white scenario of pass/fail on signature verification. I am not sure if we can really codify how to handle partial failure of parallel signatures in the ID and it may be best to leave this up to the application.

It should be noted that when I am discussing multiple signatures I am talking about parallel signatures where all signatures are for the same block of data (as opposed to encapsulated signatures where a signed document is then signed a second time with the hash calculated over the data and first signature).

I will look over the 2 documents mentioned and get back to you on this.

** The inter-office memo becomes real interesting when you have the readers who want to sign off on the memo but also add comments but still be left with a single document in the end.

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 2 Dec 1998 21:29:41 +0100

> Well this is going to depend on how the signatures are being used.

precisely.  This means that it is useless to define specific
semantics in a format description since user agents following the
trivial variant of displaying _all_ signature integrity information
to the user behave optimally.

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1

---

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 02 Dec 1998 16:14:47 -0500

In <[email-masked]>, on 12/02/98 

>precisely.  This means that it is useless to define specific semantics in
>a format description since user agents following the trivial variant of
>displaying _all_ signature integrity information to the user behave
>optimally.

Well curently there is no format at all for creating parallel signatures. This should be documented in the ID. What the users do with those parallel signatures is another matter that should be left to the application and is outside the scope of an ID.

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 03 Dec 1998 14:54:00 +0900

From: "William H. Geiger III" <[email-masked]>
Subject: Re: OpenPGP agenda for Dec 7
Date: Wed, 02 Dec 1998 12:29:45 -0500

> As you can see we no longer have the black and white scenario of
> pass/fail on signature verification. I am not sure if we can really
> codify how to handle partial failure of parallel signatures in the
> ID and it may be best to leave this up to the application.

Please don't jump to a conclusion. :-)

Many people discussed in many places many times. Some thought the same
as you. Some enumerated and categorized semantics. If time allows, I'd
suggest read the archives of pem-dev ml and ietf-pgp-mime ml. 

As you said, there is no spec to define the syntax of multiple
signature. One spec (without semantics definition) is better than
nothing.

It is fine to me that you will define syntax only, and leave semantics
to applications. I like such slow start since we should not repeat the
same history.

I'd suggest that your ID should keep the door open for future
definitions of semantics.

--Kazu