At 07:46 PM 6/1/98 +0100, Adam Back wrote:
I would have thought this should be a MUST rather than a MAY, and that
ability to deal with V3 keys should be the MAY.
This would allow one to implement OpenPGP without having to as an
implication of a MUST clause include a patented algorithm (IDEA, and
RSA), because your option is simply to not be backwards compatible,
which is precisely the implication of the limited backwards
compatibility due to patent problems implication, and no more.
BUT, if you choose to implement RSA and IDEA, then you MUST treat V3
keys as implicit statement that IDEA is the only cipher supported.
That's a good point. I'll think about a re-wording. But it would be nice to
encourage some 2.X users to revise 2.X to do 3DES, too. There are 2.X
implementations with SHA, so why not 3DES?
> This is technically non-compliant,
The above deals with backwards compatibility without introducing need
to be non-compliant. It is just a re-wording effectively, but is more
correct I feel (unless I have misunderstood some implication).
We have to deal with this situation. Imagine that you're using a maximal
(supports everything) OpenPGP implementation, and you're sending a message
a minimal OpenPGP implementation (which is 3DES only) and a 2.6
implementation (which is IDEA only), then there's a conflict.
My wording change is to help some developers who want an exemption there.
Why does the message creator need to be warned? It seems like a
perfectly reasonable thing to do to send an IDEA encrypted message to
someone who can only decrypt IDEA messages.
In the above case, if you send a single message encrypted with IDEA, you're
violating the protocol. I think if we allow this protocol violation, they
oughta at least warn the sender that one of the receivers may not be able
to decrypt the message.
It will be obvious that the OpenPGP users implementation does not
support IDEA if the IDEA algorithm is not on it's algorihtm capability
list in it's public key packet. If it supports IDEA, then you don't
have a problem. If it doesn't support IDEA, you can't send the
message, so you either report this to the user, of if your software
architecture allows (preferable) do as suggested above: generate two
separate messages.
We're in violent agreement -- the correct solution is to generate two
messages. However, that's easier said than done for some people. My
previous wording (to my mind anyway) allowed someone to break protocol in
this one instance.
All useful functionality. I think you need the exception that if the
reason for revocation is private key compromise, then the new
fingerprint is ignored. (Clearly an attacker with the private key
won't create a compromise reason of "key compromise", but this
definition allows you the owner to create a competing compromise cert
which does say "key compromise" and then we can define a "compromise"
revocation to take precedence over a "key retired and here is new key
fingerprint" revocation, where more than one compromise is present on
keyring.)
When I looked at putting it in, I kept it the way it was proposed -- with
the text comment only. The reason is that if I'm retiring a key, I can sign
the new key with my old one, and then put a retiry certification on my old
one. An implementation that wants to propagate trust can easily do it, so I
kept the simpler definition.
Jon
-----
Jon Callas jon(_at_)pgp(_dot_)com
CTO, Total Network Security 3965 Freedom Circle
Network Associates, Inc. Santa Clara, CA 95054
(408) 346-5860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA)