On Wed, Sep 09, 1998 at 08:28:22PM +0900, Kazu Yamamoto
wrote:
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?
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.
- 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.
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.)
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.
(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.
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.
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