On Tue, 18 May 1999 hal(_at_)rain(_dot_)org wrote:
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 am missing something here. You would need the PUBLIC key to validate
the signature. These are available within the X509 certificate, so you
could use them to come up with a valid PGP signature over the PGP
signature packet (if you own the X509 cert - if you don't you can't vouch
for the validity or would use a PGP key to sign it).
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.
Unused or "private". And it doesn't make sense to treat an X.509 RSA key
as not-an-RSA-key, and the same with DSA. If you are going to use X.509
keys you can pull them into the PGP infrastructure. And if you have any
secure web browser, you have an X.509 implementation.
It would be better to call this a version 5 signature packet.
And the issue of X.509 being a MAY / SHOULD is different from how it
should be implemented if it exists. If OpenPGP MAY support X.509, the
details should be discussed here.
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.
So my implementation (which has an X.509 implmentation in the same library
as the rest of the crypto) should easily work with what you are doing?