On Thu, 30 Apr 1998, Jon Callas wrote:
Rot-N is gone. There is an algorithm identifier for Elgamal
encrypt-and-sign keys. I have a question on this -- we wanted to deprecate
the usage-types on RSA keys (i.e. separate algorithm numbers for, but the
issues surrounding Elgamal signatures make it apparent that it's good to
have a separate algorithm ID for an encrypt-and-sign Elgamal key. See the
algorithm notes for details. Does this mean, then, that we should
de-deprecate the RSA usage-types? I'd just as soon keep them deprecated
because there are real cryptographic reasons for a separate Elgamal ID.
I would keep the RSA extras depricated. It may also be a good idea to
suggest a switch to the stronger E&S ElGamal keys even if they are never
used for signing (and that implementations MUST accept them for
encryption, otherwise I have to create duplicate keys that differ only
in the algorithm number).
I added in MD2 as a hash algorithm. There are people who want to do
PGP/X.509 interoperability, and they need an identifier for MD2.
The material hashed will never be the same, so MD2 won't work *directly*.
The only other possibility I can see is to add to a PGP signature packet a
special hashed material packet with an identifer that means "Hash *ONLY*
this extra material" which would be duplicated from what X509 signs.
We still don't have an OID for HAVAL. Can someone get one? Having HAVAL in
there is nice, but I'm a lazy SOB and it's easier for me to remove HAVAL
than to get it an OID. I also think that if having HAVAL is important to
the community, then there oughta be one person who would stand up and take
it upon themself to get an OID.
Or for TIGER. Actually, the PKCS1 padding with ASN1 OID is only important
for RSA and ElGamal signatures, and only to insure interoperability with
RSAref in the former case. Actually not even that since the decryption
(signature check) simply returns the entire buffer and it is only if you
use higher level routines that it would matter. I have been using an ASN1
octet-string of "HAVAL" in place of an OID and everything works.
Unless you really want to limit PGP to only use things with approved
object numbers, I would strongly suggest using the octet string of the
hash (which you have defined for clear signatures anyway) as an
alternative to an OID. Then this issue disappears. So if I see the ASN1
OBJECT, I look it up in the OID table, but if I see an octet string in the
same place, I match on the string. So [OID]1.2.840.113549.2.5 and
[Octet-string]3,"MD5" would be synonymous.
[While I am near the subject, I would like a number for the TIGER hash -
Werner Koch is implementing it, and it would be easier if it had an
official Algorithm ID, I would suggest the next available one: 6]
Note that to apply for an OID, you have to be one of the players ISO
recognizes (i.e. MD5 = 1.2.840.113549.2.5 meaning:
ISO.Member_body.US.RSADSI.PKCS#2.MD5 If IETF, IMC, or Network
Associates desires to use ASN1 OIDs, I think it would be useful for them
to get an OID for their company or organization (or add one just for
OpenPGP) so they will be recognized in the hierarchy. Then we can drop in
the extra algorithms under that number.
For an online guide to object IDs (from someone active in the IETF) see
http://www.alvestrand.no/objectid
I'm going to go over comments on this draft over the next week or three and
produce a last-call draft. Early revisions will go to the usual gang. If
you have something you really, really want done, let me know. I'll make
sure you get an early revision. I want last call to be quiet, so we can
call this a wrap and then get on to the *real* discussions of what's good
to have in OpenPGP.
--- reply to tzeruch - at - ceddec - dot - com ---