William H. Geiger III, <whgiii(_at_)openpgp(_dot_)net>, writes:
I had done a detailed analysis of this key for the PGP-Keyserver Operators
group this weekend (I can post here if desired).
Yes, that would be useful to see.
IMHO the signature looks
foobared and violates several aspects of RFC 2440. I don't mind creating a
method to convert X.509 stuff to OpenPGP, I don't even mind the X.509
certs being encapsulated in a hashed subpacket. But if we are going to do
all this the end result should be a valid OpenPGP Key that contains the
following 3 elements:
Valid OpenPGP Public Key Packet
Valid OpenPGP UserID Packet
Valid OpenPGP SelfSignature
I don't think that the X.509 packet alone should qualify as a valid
SelfSignature but instead during the conversion process a OpenPGP
SelfSignature should be generated. Of course this would require that a
corresponding OpenPGP secret key be generated during the conversion
process. Otherwise I really don't see the point of going through the
conversion process at all.
Most of the time there is no secret key available because the signature
is made by someone other than the person importing the key. That is
the typical case for an X.509 certificate. In that case there is no
possibility of creating an equivalent PGP secret key because the secret
key material is not available.
I don't see the X.509 support in PGP 6.5 as something which will be part
of the OpenPGP standard. X.509 is a complex data format and most PGP
implementations should not have to carry the burden of adding a full X.509
library just to support OpenPGP. The intention is that X.509 certificates
will get turned into signature packets which other implementations can
ignore without difficulty. This is done most directly by giving it an
unused public key algorithm, so that no implementations will attempt
to verify the signature. I used zero, but we could use 100 if that
would help. Implementations need to be able to handle unrecognized
public key algorithms, even those which are not defined in the current
OpenPGP standard.
I can make changes for version 6.5.1 which will come out in a few weeks
(bug fix version) to address problems which are tripping up current
implementations.
Hal Finney
Network Associates, Inc.