Thomas,
Sorry for my late response. I was busy for the last few day.
From: Thomas Roessler <roessler(_at_)guug(_dot_)de>
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