[This is a repost of a message from another account, where the email is
getting held or lost. Apologies if you see it again later.]
At 03:34 PM 9/12/97, Peter Gutmann wrote, quoting tzeruch:
One of my other "stupid PGP tricks" is to convert X.509 to and from PGP
(easier now that X509 has DSS, and maybe DH). I can't really convert
signatures, but I can move the moduli and other information around.
I've been working on this too. X.509 -> PGP is doable, but going the other
way is pretty challenging since the only thing in a PGP cert is what might
be
a commonName, and usually an email address, but not a full DN. What
thoughts
do people have on handling the naming issues?
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.
- 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:
Serial number:
840717480
Signature Algorithm:
MD5 with RSA encryption (1.2.840.113549.1.1.4)
Issuer name:
C=Ca (country name)
L=Nepean (locality name)
OU=No Liability Accepted (organizational unit name)
O=For Demo Purposes Only (organizational name)
CN=Entrust Demo Web CA (common name)
Validity:
Not before: Thu Aug 22 13:38:00 1996 +0000
Not after: Fri Nov 22 12:38:00 1996 +0000
Subject name:
C=US (country name)
ST=Michigan (state or province name)
L=Kalamazoo (locality name)
O=I/Net, Inc. (organization name)
OU=Test PKCS 1024 (organizational unit name)
CN=www.inetmi.com (common name)
Note the trick of putting liability statements into the issuer DN!
509V3 has a different mechanism for this, but I don't know how widely
used it is yet. In order to import this kind of cert into PGP, we could
again use the userid extension fields to capture all this cruft.
Another alternative is to use the standard RFC1779 encoding of DN's in
ASCII, similar to what I used above, and to directly create userids of
the form C=Ca, L=Nepean, OU=No Liability Accepted,... Then we might get
by with just one new userid type (or even use the existing packets and
rely on a parser to recognize when RFC1779 is being used). We wouldn't
need multiple new packet types, we'd just use ASCII.
Hal Finney
hal(_at_)pgp(_dot_)com