ietf-openpgp
[Top] [All Lists]

Re: The purpose of this mailing list

1997-09-12 14:27:12
Death rays from Mars made Hal Finney <hal(_at_)rain(_dot_)org> write:
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.  
 
[For non-X.509 types, what you need to do is leave the DN empty and add an 
 altName attribute containing the email address, which is marked as critical 
 so that the program using the cert has to handle the altName]
 
This is a very risky move, because it makes the resulting cert unusable with 
X.500/LDAP directories (I have some comments on this usage in my X.509 style 
guide, http://www.cs.auckland.ac.nz/~pgut001/x509guide.txt).
 
Here is a test 509 cert which one of our employees got from Entrust last 
year, decoded:
[...]
Note the trick of putting liability statements into the issuer DN!
 
Which is very naughty, and another X.500/LDAP-breaking kludge.  
 
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.
 
Given the rather broken DirectoryString string formats (again, see the 
'guide), you're going to see a lot of Unicode strings in non-English-speaking 
countries which will mean people have to resort to odd encodings like UTF 
variants for RFC 1779-compatibility (I'll have to check to see what 1779 says 
about non-ASCII character sets, but I assume you have to mangle things to get 
7-bit characters).
 
Peter.


<Prev in Thread] Current Thread [Next in Thread>