This message has been compiled from some private
communications between Kazu Yamamoto, Michael Elkins, John
Noerenberg and myself on the topic of a revision of RFC
2015 ("MIME Security with Pretty Good Privacy (PGP)"). I
have slightly edited the messages; omissions include
consensus on issues being on or off topic and off topic
issues.
Please comment.
tlr
[Begin of old communications.]
I compiled the following list of issues (this is not the
original version; I've added some points):
- RFC 2015 requires a micalg parameter when producing
"multipart/signed; protocol=application/pgp-signature"
body parts. RFC 2015 defines the two hash algorithms
pgp-md5 and pgp-sha1, while the current OpenPGP draft
knows about some more algorithms (section 9.4).
- If I understand draft-ietf-openpgp-formats-06 correctly,
OpenPGP permits parallel signatures with different hash
algorithms applying to one and the same message. We may
wish to permit a comma-separated list of hash algorithms
for the micalg parameter.
Further pursuing this direction of thought, one may be
inclined to permit several application/pgp-signature
body parts in a multipart/encrypted attachment, each of
them corresponding to a specific micalg. This micalg
parameter should additionally be listed in the
Content-Type header of said additional signature parts.
[This one was not in the first version:]
- We may wish to require another parameter with the
application/pgp-signature body parts, namely, "pkalg".
This parameter would identify the public key algorithm
used to generate the signature, e.g., rsa, elgamal, dsa,
etc.
The rationale behind this is that mail user agents may
wish to invoke different external OpenPGP
implementations to verify different kinds of signatures
- e.g., pgp 2 for RSA/MD5, pgp 5 for DSA/SHA1, and gpg
for RSA/RMD160, RSA/SHA1, and so forth.
[Original list continued.]
- Section 6.2 of RFC 2015 explicitly mentions PGP 2.x. We
may wish to update this to reference the OpenPGP RFC
when it comes out - but that's just a nit.
- RFC 2015 does not explicitly specify what type of PGP
signature is to be generated when signing messages
(binary document or text document signature). But
that's pretty much a non-problem since the RFC
_requires_ user agents to convert texts to canonical
format before verifying or generating signatures, thus
making text and binary signatures of the message body
equivalent.
Kazu's reply to this plus my comments:
From the MUA's point of view, pgp 2, pgp 5, and gpg
behave pretty much the same way.
This is true only when we use the PGP program only. At
the last meeting, three people raised their hands to tell
implementation of OpenPGP. One of them is GNUPG, I
believe. We should be very careful to design PGP/MIME
nowadays.
There is no problem with different implementations - all
of them should support the same message format (namely,
OpenPGP). Command line interfaces and similar issues are
outside of the scope of this discussion.
[micalg parameter for multipart/signed]
Yes. But I'm very suspicious that this parameter useful.
Anyway, such discussion is not for PGP/MIME but for
architecture of security
Could you please elaborate? This parameter is as clear as
the signature block, and it repeats information present
inside this signature block.
[binary vs. text signatures]
Here here here. Some PGP/MIME implementors repeatedly
asked me this topic. As Thomas said, RFC 2015 is enough.
But I think it's not readable. It's nice if the next
PGP/MIME draft will include binary vs text packet format
discussions. I'm sick of answering this question.
Additionally, Kazu gave the following list of problems:
(1) version control
(1.1) PGP packet format changed. Should we label
"Version: 2" for multipart/encrypted?
(1.2) How about multipart/signed? Actually, the armor
format for detached signatures changed.
(1.3) What kind of actions should be taken for each
version? Is it OK for OpenPGP/MIME MUA to ignore
PGP/MIME messages?
(1.4) If mismatch happens between the micalg parameter
and PGP signature, what should we do?
The old PGP format is a proper subset of the new one, so
MUA and crypto software which handle OpenPGP properly will
at least be able to properly decrypt and verify material
generated by old PGP versions.
(2) Conformance
(2.1) What kinds of algorithm (for symmetric crypt,
asymmetric crypt, hash) is preferred when generated?
(2.2) What is the relationship between *preferred xxx
algorithm* in PGP signature for each user and the
conformance of (2.1)?
(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 an issue of the message format proper, IMHO.
Anyways, such MUAs are either crippled (2.4) or simply
unable to handle conforming messages (2.5).
(3) Others
(3.1) Some people want to encode PGP signature and/or
encrypted message with MIME encoding(e.g not PGP armor
but base64). Should we allow this?
I don't see any benefits from this. On the other hand,
this would break existing software which relies on the
content-transfer-encoding restrictions in RFC 2015. =>
Don't do this.
(4) FAQ
(4.1) Why not text/pgp?
(4.2) S/MIME doesn't use multipart/encrypted. Why does
PGP/MIME?
I guess this should rather go to news.answers.
(5) security multipart issue (maybe should feedback to
RFC 1847)
(5.1) In many cases, European people exchange their
Latin-1 messages with CTE: 8bit. But RFC 1847 requires
objects to be signed be 7bit. How can sign 8bit
message/rfc822? Ned said that MUA must change 8bit
message to 7bit.
Precisely.
Is it practical? Who has implemented such complex
mechanism?
It has been done. Just parse the message/rfc822
attachment, go through the attachment tree, adjust the
leafs' encodings, set the nodes' (multipart/*, message/*)
encodings to 7bit and write the whole thing to disk. Not
too beautiful, but feasible.
(5.2) No RFC says that the protocol paramter is
case-insensitive.
So it isn't. Where's the problem here?
[End of old communications.]
--
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