From: Thomas Roessler <roessler(_at_)guug(_dot_)de>
Subject: Revising RFC 2015
Date: Thu, 3 Sep 1998 20:37:20 +0200
- 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.
If the purpose of the pkalg parameter is to distinguish PGP format
version in MUA level, how about version control that I mentioned? (e.g
The pgpmime-version parameter for application/pgp-signature.) This
approach is, I think, symmetric if we will decide Version: in
application/pgp-encrypted.
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.
I have not discussed command line interface issue. My point is that
implementors are free of how to implement PGP/MIME if it is
conformable to the spec.
I seemds that you assume that MUA interacts underlying a
PGP-conformable program. But it's ok that MUA itself has an ability to
produce PGP format.
Explanation that everything is fine if you use PGP or GNUPG is not
appealing to me.
Again, my point is that we should be very careful when design PGP/MIME
based on PGP 5. We should not say that it's ok becase the PGP program
can handle it correctly.
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.
Maybe you may misunderstand my point. You proposed new values. It's
great. Thanks.
What I wanted to say is that the parameter itself seems less useful
than we expected. The micalg parameter is defined with the hope that
it is useful for one pass verification. But I don't know any
implementations use it.
Since future implementations may make use of this parameter, I'm not
particular to this topic.
But again, if micalg is really meaningless, we should feedback this to
RFC 1847.
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.
It's nice if RFC2015 aware (but not aware to PGP/MIME based on PGP 5)
program can skip further processing according to Version: 2.
And if your observations are correct, it means that many defined
parameber of RFC 2015 is meaningless.
(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).
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.
(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.
And I don't see any benefits of PGP armor when used to encode detached
signatures. Note I can see benefits of PGP armor when used to encode
encrypted message for backward compatibility.
On the other hand,
this would break existing software which relies on the
content-transfer-encoding restrictions in RFC 2015. =>
Don't do this.
Maybe. Bute many implementation of PGP/MIME can handle it
(e.g. encoded signature with base64), I guess. At least, my
implementation can do it though it is not my intention.
(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.
No. RFC is the best place to answer any technical questions. And if
such observations will be included in the new PGP/MIME RFC, the same
discussion will never repeat.
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.
Great. Mutt can encode, for instance, a message, to be attached then
signed, which contains multipart whose second part is 8bit text, to
7bit? How about very recursed messages?
Not too beautiful, but feasible.
Interesting. You are the first European for me to accept RFC 1847's
7bit restriction. :-)
I'm not a European and I don't use 8bit charset usually. Nonetheless,
I disagree with RFC 1847's 7bit restriction. The world is really
coming back to 8bit transportation while 7bit transportation spread in
the beginning of the MIME days.
(5.2) No RFC says that the protocol paramter is
case-insensitive.
So it isn't. Where's the problem here?
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.
--Kazu