On Fri, 12 Sep 1997, Hal Finney wrote:
X.509 V3 does not require distinguished names. You can use alternate
names and leave the DN field blank. It should be possible to put the
PGP userid in as one of the alternate name forms, probably an email name.
So the PGP->X509V3 direction seems simple enough as far as converting just
the data in old certs.
Some issues remain:
- Signature verification is the difficult one. Even if we can structurally
reformat the information in PGP certs into an X.509 arrangement, the PGP
signatures are not going to validate once the data is reformatted. For
importing 509 into PGP, we could specify a new signature type which meant
to use 509 formatting for the sig verification. But going from PGP to
509 using legacy PGP certs looks impossible.
My thought is more to find places where X509 calls are made and fake an
X509 library that uses the PGP WoT model. Integrating with everything
else in fully standard format woudl be difficult, but at the point where
there is a callback when there is a failure (when something says it
doesn't recognize the authority that signed the cert), install a second
mechanism.
- People may want to put more information into PGP certs than just email
address and common name. For those, the kinds of extensions proposed
by Charles Breed seem useful.
- People may want to convert 509 certs to PGP and keep the various extension
fields and DN tricks which have been used for policies and such. Here is
a test 509 cert which one of our employees got from Entrust last year,
decoded:
I used the SSLeay certificate oneline as the "userid" string when going to
PGP, and do some parsing for the common name and email going the other
way. Quick and dirty, but PGP seems good at extracting the data.