o=Internet
Nope. Should be c=Internet
domainComponent=COM
domainComponent=USWEST
domainComponent=ADVTECH
commonName=huntting
When did the Internet become a country? Or did someone redefine
Country to mean Naming Authority?
Whatever. @O=Internet exists today at the top of the directory
information tree, @C=Internet makes no sense.
Is domainComponent a recognized attribute type that should be supported by
PEM software?
According to ISODE "domainComponent" has the following OID:
0.9.2342.19200300.100.1.25
spelled out thats:
ccitt.data.pss.ucl.pilot.pilotAttributeType.domainComponent
Of course I may be confused. Has the rfc822 address to DN mapping
already been chosen? If so, what is it? If not, the above example
seems like a very reasonable place to start. The Attribute types are
defined, part of the tree is already in place even.
By the way: Once a PEM implementation maps the rfc822 address onto a
DN, looks that up and find it's entry in the DIT. What attributes does
it ask for to get a certificate chain for the remote user/address?
I thought that RFC822 specified that the local part was case insensitive.
The last time this issue came up, no one could cite a system that depended
on case sensitivity, and the general reaction was that if there was such a
system it ought to be fixed.
Then commonName should suffice to hold an rfc822 local part.
Although I understand that some PCAs may support this type of DN structure,
I certainly hope that it doesn't become commonplace. I know that some
other PCAs intend to disallow such names, insisting on the use of valid
Organizations, qualified as necessary with their location.
I think this DN makes allot of sense. Can you think of a more
reasonable mapping from rfc822 address to Distinguished Name?
brad