Christian,
I am convinced that there simply isn't _any_ guaranteed,
foolproof way to associate a user's (or a CA's) Internet email
address with his certificate/distinguished name. There are
just too many possible mappings, both 1:many and many:1.
I may have multiple certificates (for different roles) and only
one mailbox, or I may have one certificate and multiple mailboxes
depending on the content (e.g., one for PEM, one for personal,
one for urgent business use, etc.)
As I said in my message to Hoyt Kesterson on 5 Oct regarding
X.509 DN semantics, there is too much overlap of constructs
going on here. If I intend my DN to reflect my affiliation with
my company, I may have C=US, O=GTE, OU=GTE Labs,
CN=Robert Jueneman, but I may choose to send and receive
my email via CompuServe or some other VAN, in which
case my email address might be #12345(_at_)Compuserve(_dot_)COM(_dot_)
How could you possible derive that from my DN?
Although we could cram additional attributes into the DN
and make use of a multivalued RDN to contain such
additional useful information, almost everyone has
expressed some degree of revulsion to such hacks.
The proper answer, I believe, is to add these additional,
optional attributes to X.509 outside of the DN, but
still signed by the CA. Then you can do what you proposed,
whether the ultimate solution is based on a TCP socket
or an SMTP mail responder.
BTW, I don't see any need for "loose" queries or searches.
If you submit either the user's DN or the certificate number
and issuer name, the results should be unambiguous.
Also, I think that implementing cache handling or allowing
clients to go through their "local CA" would subvert the
entire mechanism. The intent was to obtain the latest
authoritative information direct from the horse's mouth,
as it were. Only the originator's CA can provide that information.
(I am assuming that you were not referring to a means of
simply redirecting the inquiry to the correct CA a la DNS.)
Bob