Jon writes:
* My addendum to the key algorithm preferences text, that allows someone to
use IDEA in an algorithm conflict with a V3 key. I cleaned up the language
there a little more from what I sent before. The new language is:
An implementation that is striving for backward compatibility MAY consider
a V3 key with a V3 self-signature to be an implicit preference for IDEA,
and no ability to do TripleDES.
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.
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).
but an implementation MAY violate the above rule in this case only
and use IDEA to encrypt the message, provided that the message
creator is warned.
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.
Ideally,
though, the implementation would follow the rule by actually generating two
messages, because it is possible that the OpenPGP user's implementation
does not have IDEA, and thus could not read the message. Consenquently, an
implementation MAY, but SHOULD NOT use IDEA in an algorithm conflict with a
V3 key.
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.
* Phil's request for a reason-for-revocation subpacket addresses one of my
longstanding gripes about PGP -- that there is no way to distinguish
between a key compromise and events that are much more likely to happen,
such as getting a new ISP, deciding it's simply time for a new key, etc. My
only addition would be that when the key is superceded by a new key, that
the fingerprint of the new key be put there, which makes it a suitable
implementation of the "I-used-to-be" feature I've wanted for years.
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.)
(This is the negative side of new features, they introduce new required
semantics and rules, and we get more complexity in the coding and in
the specs.)
Adam