Executive summary:
- I'm dropping my pkalg suggestion.
- There seems to be consensus on micalg.
- A suggestion with respect to ASCII armor and and binary
representation of PGP objects is made.
On Fri, Sep 04, 1998 at 07:22:49AM +0900, Kazu Yamamoto
wrote:
If the purpose of the pkalg parameter is to distinguish
PGP format version in MUA level, how about version
control that I mentioned?
You got me on this one. Ok, just forget what I wrote
about different PGP versions.
(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.
Let me elaborate my point in a different manner. We have
several layers between which we should distinguish:
1. Inner PGP packets. These beasts consist of a packet
type, version byte, and lots of information. What
packets are handled depends from implementation to
implementation. E.g., pgp 2 only handles v2 packets,
OpenPGP compliant software handles v2 and v3 packets,
etc.
Most important, implementations should be able to
graciously bail out upon unknown packets or packet
versions.
2. Outer PGP packets. By this, I denote the encapsulation
of "inner packets", mostly consisting of the packet tag
and length bytes.
A new style outer packet can carry any inner packet; an
old style outer packet an carry any inner packet with a
3-bit packet tag.
PGP 2 is about the only implementation which can't
handle new-style outer packets. It should be pretty
simple to add this support (Lutz, have you done it in
2.6.3in?), so we can IMTAO assume that pretty much
every implementation in common use can handle these
packets sooner or later.
(Both are called "packet" in the OpenPGP draft. Maybe we
should change this in the next version?)
3. Packet representation. PGP knows about two of them:
ASCII armor and binary.
4. MIME encoding. This is the encoding we apply at the
MIME level.
5. MIME encapsulation.
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.
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.
Now, let's revisit the version control problem.
Three things can happen with the content types currently
supported by PGP/MIME:
- 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.
Clearly, this is a layer 1 incompatibility.
- 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.
Once again, this is a problem on layer 1.
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.
Now, for the MIME parameters. If we apply the model
above, the pkalg parameter I proposed for signature body
parts should be left out.
I'm completely clear about the fact that this leaves MUAs
who support several back-ends in parallel in the rain;
such software would have to try every back-end in turn, or
implement a back-end selection on the lower levels on the
protocol.
About micalg, you write:
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.
OK, fine with me. Can I state the consensus that we leave
everything as it is now and simply add the new hash
algorithms?
(2) Conformance
(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.
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.
(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.
That's correct, but:
On the other hand, this would break existing software
which relies on the content-transfer-encoding
restrictions in RFC 2015. => Don't do this.
But 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.
It's nice that your implementation has this extension of
the required behaviour, making it more robust. But other
implementations which comply to the current RFC may _not_
have this extension. We should _not_ deliberately break
that software without good reasons.
Additionally, there is the consistency argument: I don't
think having different content transfer encoding
restrictions for every content type we define is a good
thing.
So if we want to drop ASCII armor on the long run, we
should do so _everywhere_.
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.
- Implementations MUST be able to generate ASCII armor
representations, and they SHOULD NOT generate the binary
representation.
This should open a smooth upgrade path for the case that
ASCII armor is finally dropped from some future version of
the OpenPGP document.
(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)
(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.
So it's case-sensitive in PGP/MIME as well, that's what
I've said. Where's the problem with that?
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