Subject: Re: Revising RFC 2015

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Wed, 09 Sep 1998 20:28:22 +0900

Thomas, 

Sorry for my late response. I was busy for the last few day.

From: Thomas Roessler <[email-masked]>
Subject: Re: Revising RFC 2015
Date: Fri, 4 Sep 1998 14:38:25 +0200

> Let me elaborate my point in a different manner.  We have
> several layers between which we should distinguish:

[deleted]

> Layers 1-3 (including ascii armor for signatures) are
> specified in the OpenPGP draft and should be handled as
> mostly opaque by a PGP/MIME text (they are by RFC 2015).
> If there are problems on these layers, they should be
> dealt with in the next generation OpenPGP RFC.

This layer model seems good.

But I have another *conceptual* model. (Probably we are explaining the
same thing with different terminology.) In my model, there are two
entities: PGP/MIME MUA and PGP engine. The PGP/MIME MUA drives the PGP
engine.

So, PGP/MIME should
	(1) define PGP/MIME formant
and
	(2) provide necessary information for MUAs to drive PGP engines.

> Layers three and four are pretty much the interface
> between MUA and PGP application.  Essentially, one of the
> two mappings applied is usually the identity, while the
> other one is more or less base64.

This is perhaps the same of my conceptual model.

> - Alice signs a message with a key and/or signature format
>   which is not understood by Bob's software.  In this
>   case, Bob's software will kindly bail out and tell him
>   that the signature can't be verifyed for this and that
>   reason.  Nevertheless, Bob's MUA will be able to display
>   the text of the message since the message is present in
>   MIME clear-text.

Right.

>   Clearly, this is a layer 1 incompatibility.

Uhhhm. From the PGP/MIME implementors of view, I like to have
semantics of this case. What kinds of action does PGP/MIME take?

> - Alice encrypts a message with Bob's public key and sends
>   it to Bob.  Now, this is an issue already dealt with in
>   the OpenPGP draft, so it's out of the scope of PGP/MIME.
> - Alice sends a public key to Bob, but Bob's PGP version
>   is not able to handle this kind of public key.  Well,
>   that's tough luck, so they won't be able to communicate
>   securely.

Ah-ha! Your point is that a sender can guess receiver's PGP version
thanks to his public key.

But with PGP 5.x spec, it is possible to encrypt a message with Triple
DES, which can be not handled by PGP 2.x, whose session key is
encrypted by RSA. I think that the story is not so simple.

> All this means that there are no version control issues to
> be dealt with on the MIME layer, so I think we should
> leave them out.

Sorry, I disagree. Please see below.

> OK, fine with me.  Can I state the consensus that we leave
> everything as it is now and simply add the new hash
> algorithms?

I agree. But please define semantics for mismatch between 
the micalg parameter and parameters inside PGP packets. 

I'd suggest that PGP/MIME implementations MUST enumerate correct hash
algorithms onto the micalg parameter when generating and PGP/MIME
implementations MAY ignore the micalg parameters when accepting.

> >>> (2.1) What kinds of algorithm (for symmetric crypt,
> >>> asymmetric crypt, hash) is preferred when generated?
> >>> (2.3) What kind of actions should be taken if MUA
> >>> receives unrecognized PGP packets?
> >>> (2.4) Generating: what kind of content-type must MUA be
> >>> able to generate? If MUA can sign only text/plain, is it
> >>> conformable?
> >>> (2.5) Accepting: what kind of content-type must MUA be
> >>> able to handle? If MUA can't verify signed text/plain
> >>> under multipart/mixed, is it conformable?
> > This is not a format issue but a standardization issue.
> > Thus certainly protocol issue. Recently, many other
> > protocols define minimum conformant set for generating
> > and accepting.
> Let's revisit these points, and let's think layers while
> doing so.
> 
> 2.1, 2.2 and 2.3 are clearly issues on layers one and two,
> so I'd consider them to be outside the scope of the
> PGP/MIME spec.

No. Please remember my conceptual model. PGP/MIME UA must tell what
kind of symmetric crypto (and more) to PGP engine. (2.1)

(2.3) is semantic issue of PGP/MIME.

> 2.4 and 2.5 are yet another category: Here, you are
> dealing with general MIME handling.  Now, this is an issue
> to be handled in the "generic" MIME documents, but once
> again not in a PGP/MIME text.  For the purpose of
> PGP/MIME, we can simply assume that a MUA should behave
> according to the generic texts.

Maybe. Nonetheless, implementation note of this kind is useful to let
implementators program correctly.

> So if we want to drop ASCII armor on the long run, we
> should do so _everywhere_.

I agree. 

I don't know you know the old discussions on PGP/MIME when RFC2015 was
IDs. Actually, I proposed to use MIME encoding instead of ASCII armor
at that time. This proposal was rejected but I couldn't see any
technical reasons why rejected.

To my experiences, ASCII armor is less friendly to non-PGP/MIME UAs
than it seems to be. PGP/MIME signed objects can't be verify by the
PGP program(note: PGP 5.0 can do this if compiled with the MIMEPARSE
macro). So, the second part, detached signature, is not necessary to
be encoded with ASCII armor.

For PGP/MIME encrypted object, RFC2015 is not friendly to the PGP
program, neither. Yes, the object can be decrypted by PGP but it is
not so easy to remove MIME header preceding the target object. Please
imagine that you remove CT: preceding a GIF image file by your editor.
All in all, manual processing is necessary and MIME encoding programs
are out there. So, I don't see any technical reasons for ASCII armor.

Also, I proposed not to use multipart/encrypted since it's just
lengthy(note: the first part is mostly empty). Ned suggested that it's
nice to align PGP/MIME to the standard way(i.e. multipart security). I
think this alignment is nice only if ALL encryption mail protocols
align themselves since these protocol can share reporting mechanism to
users(e.g. telling users that target objects were automatically
decrypted). Then S/MIME comes and it doesn't use
multipart/encrypted. Moreover, MOSS is going to historic. Currently, I
don't see any reasons why PGP/MIME uses multipart encrypted. It's just
lengthy.

Anyway, past is past. This is just for your information.

> A suggestion on this topic:
> 
> - Implementations MUST be able to accept ASCII armor
>   representations of PGP objects.  They SHOULD be able to
>   accept the binary representation.

I like to change the last SHOULD to MUST because accepting syntax is
like that.

> >>> (4.1) Why not text/pgp?
> 
> >>> (4.2) S/MIME doesn't use multipart/encrypted. Why does
> >>> PGP/MIME?

> > No. RFC is the best place to answer any technical
> > questions. 
> 
> Correct.  But RFCs are _not_ the best place to extensively
> discuss the rationale behind certain basic decisions.
> Specifically, an RFC which is merely a revised version of
> an existing one should not start to explain the design
> decisions behind that existing RFC.  (IMHO)

OK, let me enumerate an example with my IPsec hat.

The IPsec architecture draft explains why two protocols, namely AH and
ESP, are provided.

Also, RFC2015 starts with objections to the application/pgp approach.

# I don't like this relative prologue. I think that PGP/MIME RFC
# should start with "why PGP/MIME". Comparison with other approaches
# should go to a later session.

> > MIME clearly defines any MIME parameters are
> > case-*sensitive* if it is not defined so. And RFC 1847
> > doesn't say the protocol parameter is case-insensitive.
> 
> So it's case-sensitive in PGP/MIME as well, that's what
> I've said.  Where's the problem with that?

I believe that the protocol parameter is case-insensitive since it
refers to content-type which is certainly case-insensitive. 

--Kazu

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 9 Sep 1998 14:34:02 +0200

On Wed, Sep 09, 1998 at 08:28:22PM +0900, Kazu Yamamoto

> Uhhhm. From the PGP/MIME implementors of view, I like to
> have semantics of this case. What kinds of action does
> PGP/MIME take?

As we are talking about layer 1 incompatiblities, OpenPGP
defines some behaviour for the PGP engine.  This behaviour
is passed to the PGP/MIME MUA.  So there is absolutely no
need to specify anything about such incompatibilities in a
PGP/MIME text.

>> - Alice encrypts a message with Bob's public key and
>>   sends it to Bob.  Now, this is an issue already dealt
>>   with in the OpenPGP draft, so it's out of the scope of
>>   PGP/MIME.

> Ah-ha! Your point is that a sender can guess receiver's
> PGP version thanks to his public key.

> But with PGP 5.x spec, it is possible to encrypt a
> message with Triple DES, which can be not handled by PGP
> 2.x, whose session key is encrypted by RSA. I think that
> the story is not so simple.

I have to repeat myself: This is an issue which is dealt
with in the OpenPGP draft, so it's out of the scope of
PGP/MIME.

> I'd suggest that PGP/MIME implementations MUST enumerate
> correct hash algorithms onto the micalg parameter when
> generating and PGP/MIME implementations MAY ignore the
> micalg parameters when accepting.

There is nothing in the RFC which says an implementation
MUST evaluate the micalg parameter when accepting, so your
letter point is precisely what's in the RFC right now.

That hash algorithms MUST be listed correctly is evident
from the text and doesn't need to be mentioned separately.

If a user agent creates a message which doesn't conform to
the spec, the receiver will conform to the GIGO principle:
Garbage in, garbage out.  All this is not so new...

> Please remember my conceptual model. PGP/MIME UA must
> tell what kind of symmetric crypto (and more) to PGP
> engine. (2.1)

That's an issue _every_ PGP front-end has to deal with. It
isn't MIME-specific at all.  Additionally, the OpenPGP
spec does already deal with this issue.  May I point you
to section 5.2.3.6 of the draft?

> (2.3) is semantic issue of PGP/MIME.

Sorry, no.  This is a semantic issue of _any_ OpenPGP
implementation, at any layer, and it's not at all specific
to PGP/MIME.  (2.3 was the question what kind of action a
MUA should take if it receives unrecognized PGP packets.)

>> dealing with general MIME handling.  Now, this is an
>> issue to be handled in the "generic" MIME documents, but
>> once again not in a PGP/MIME text.  For the purpose of

(2.4 and 2.5 were the question what kinds of MIME
content-types am MUA must be able to handle and generate
in order to conform to the spec.)

> Maybe. Nonetheless, implementation note of this kind is
> useful to let implementators program correctly.

Pardon me?  The content-types supported by a MUA have
absolutely nothing to do with PGP/MIME; they have
everything to do with MIME.  Essentially, this is a
decision you have to make as a MUA author.  Your
"customers" will tell you if your program is usable or
not.

> I believe that the protocol parameter is case-insensitive
> since it refers to content-type which is certainly
> case-insensitive.

May I quote from RFC 2045?

   The type, subtype, and parameter names are not case
   sensitive.  For example, TEXT, Text, and TeXt are all
   equivalent top-level media types.  Parameter values are
   normally case sensitive, but sometimes are interpreted
   in a case-insensitive fashion, depending on the
   intended use.  (For example, multipart boundaries are
   case-sensitive, but the "access-type" parameter for
   message/External-body is not case-sensitive.)

So, where precisely is your problem?

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: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 10 Sep 1998 06:52:53 +0900

From: Thomas Roessler <[email-masked]>
Subject: Re: Revising RFC 2015
Date: Wed, 9 Sep 1998 14:34:02 +0200

> So, where precisely is your problem?

I said that RFC 1847 doesn't say the protocol parameter is
case-*in*sensitive.

RFC 2045 says that MIME parameter is case-sensitive unless explicitly
defined so.

According to these two things, readers think that the protocol
parameter is case-sensitive.

However, I think that the protocol parameter is case-*in*sensitive
since content-type is case-*in*sensitive as you quoted.

I'm talking about values of MIME parameter, not parameter name.

--Kazu

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 10 Sep 1998 07:10:22 +0900

> There is nothing in the RFC which says an implementation

Which does this "the RFC" refer to, RFC 1847 or RFC 2015?

> letter point is precisely what's in the RFC right now.

OK, fine. I wrote my farmer sentence to make my explanation symmetric.
(I didn't claim any RFCs on this topic.)

> from the text and doesn't need to be mentioned separately.

What do you mean "separately"? I didn't say anything about editorical
issues on this topic.

> Garbage in, garbage out.  All this is not so new...

OK, this is the point of our debate.

This interpretation is just yours. Since RFC2015 doesn't say accepting
manner explicitly, there are two possibilities.

	(1) mis-match is legal
		-> MAY ignore the micalg parameter
	(2) mis-match is illegal
		-> treat it as garbage? (in your terminology)

Again, PGP/MIME RFC should define both syntax and its semantics. RFC
2015 defines syntax but some semantics are missing.

--Kazu

---

From: Thomas Roessler <[email-masked]>
Date: Thu, 10 Sep 1998 11:29:56 +0200

On Thu, Sep 10, 1998 at 07:10:22AM +0900, Kazu Yamamoto

> Which does this "the RFC" refer to, RFC 1847 or RFC 2015?

2015.  1847 says that certain conditions must be treated
as an error, but this doesn't mean that it has to be
evaluated at all.

> 		-> treat it as garbage? (in your terminology)

Now, why do you think that a mis-match being illegal means
that an implementation can't be robust and ignore the
parameter in this case?  The behaviour is simply undefined, so 
the choice is yours - conform to the GIGO principle or try  
to handle things smoothly.

Actually, I find this situation just fine, so why should
anyone want to change it?

tlr

---

From: Steve Hole <[email-masked]>
Date: Thu, 10 Sep 1998 08:55:35 -0600

Message-ID: <[email-masked]>
Priority: NORMAL
X-Mailer: Simeon for Win32 Version Mercury a9 Build (12)
MIME-Version: 1.0
Content-Type: Multipart/signed; BOUNDARY=Part9809100855.B; protocol="application/pgp-signature"; micalg=pgp-sha1

--Part9809100855.B
Content-Type: Text/PLAIN; CHARSET=US-ASCII

> don't see any reasons why PGP/MIME uses multipart encrypted. It's just

Being one of the very few people that has implemented both PGP/MIME and S/MIME
into their mail products, I can tell you absolutely that the use of 
Multipart/Encrypted is a MUST.   Especially for IMAP4 mailers where access to
the MIME body structure allows a client to do intelligent things with an
encrypted body part.    You are simply wrong on this count.   I would fight
to the death any attempt to remove multipart/encrypted from the specification.

Cheers.
---  
Steve Hole                           
The Esys Corporation
Mailto:[email-masked]  
Phone:403-424-4922

--Part9809100855.B
Content-Type: Application/pgp-signature

--Part9809100855.B--

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Mon, 14 Sep 1998 13:54:51 +0900

From: Steve Hole <[email-masked]>
Subject: Re: Revising RFC 2015
Date: Thu, 10 Sep 1998 08:55:35 -0600

> Being one of the very few people that has implemented both PGP/MIME
> and S/MIME into their mail products, I can tell you absolutely that
> the use of Multipart/Encrypted is a MUST.  Especially for IMAP4
> mailers where access to the MIME body structure allows a client to
> do intelligent things with an encrypted body part.  You are simply
> wrong on this count.  I would fight to the death any attempt to
> remove multipart/encrypted from the specification.

I said, "this is just for your information". I didn't propose to
introduce such a drastic change to PGP/MIME.

BTW. I have a couple of questions to you.

(1) Why do you think multipart/encrypted is a MUST? What you do mean
intelligent things? I'm very much curious about them. Could you please
explain more concretely?

(2) S/MIME doesn't use multipart/encrypted. Being one of the few
people, what do you think of it?

--Kazu

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Mon, 14 Sep 1998 14:02:22 +0900

From: Thomas Roessler <[email-masked]>
Subject: Re: the micalg parameter
Date: Thu, 10 Sep 1998 11:29:56 +0200

> to handle things smoothly.

There is a big difference between undefined and implementation choice.

The former means ambiguous. 

The latter menas, yes, you clearly defined. If we will define its
semantics as implementation choice after discussions, it's fine to me.

Personally, I dislike to define it as implementation choice. This is a
signature service, so I think we should share a single semantics.

--Kazu