Subject: Re: Certificates by e-mail address in directory schemas

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 26 Sep 2000 10:40:07 -0600

Good questions, Tom. And in response I promise not to include an MPEG of my cat in the DN of the certificate, OR in the subjectAltName, although I'm still considering whether it deserves to be enshrined in subjectDirectoryAttributes. I'll have to ask the cat -- after all, pets have privacy rights too, don't they? :-) 

More seriously, the issue of how, and whether, to look up a certificate deserves a lot of thought. 

I have you listed in my address book as "Tom Gindin," and if I had your certificate I would probably look it up that way. But if you weren't in my personal address book or frequent contact list, would I really want to automatically look up your certificate by e-mail address, prior to sending you an encrypted message? Would I even know who you were well enough to send you a sensitive message in the first place? 

One of the risks here is that I somehow mistype a name, and automatically I get the wrong certificate, as well as the wrong addressee. I'm sure that we've all heard of the executive who sent her lover an e-mail telling him exactly and explicitly what she was going to do to him the next time they got together. Unfortunately, when she typed the first part of his name, the auto-complete function filled 
in the rest, and without looking she accidentally sent it off to an "all hands" list instead of the intended. Embarrassing, to say the very least. 

The only thing worse would have been to send off such a message in encrypted form to the wrong person or list. (Well, I guess that digitally signing it would have been even worse -- without her signature she could perhaps claim that someone was forging mail from her account to embarrass her.) 

So although I would very much like to get out of the practice of always sending my entire certificate chain to the same person over and over again, just because I signed the message, I not so sure that I want to automatically look up someone's certificate in a directory prior to sending them an encrypted message, because I'm not sure that have a suitably established basis for TRUST. 

An exception would be the case for a legitimate all-hands encrypted message, using the S/MIME v3 ESS capability for sending an encrypted message to a secure mail list server, and having that server look up the certificates of everyone on that list and send them an encrypted copy. But I think that is a special case. 

Note that I am not arguing about the desirability of looking up a certificate in a directory. I just want to be a little careful how I use that capability. 

Bob 

Robert R. Jueneman 
Security Architect 
Novell -- the leading supplier of Net services software. 

>>>< [email-masked] > 09/25/00 05:45PM >>> 
Since PKIX suggests that e-mail addresses be placed in the 
SubjectAltName extension, and much relying party software would find 
looking certificates up by e-mail address highly useful, what publication 
technique is endorsed which would allow relying party software to find 
certificates in a directory using the e-mail address as the primary input 
to their "find heuristic"? Irrespective of where in the certificate the 
e-mail address should go, relying parties are interested in where in the 
directory they can find the certificate. This does not imply that there is 
anything wrong with having S/MIME, TLS, or CMS send the originator's 
certificate (IMO that is perfectly reasonable), but that many applications 
want to discover a potential recipient's e-mail certificate without having 
to rely on a previous message sent by that user. 
I am not sure whether it should be part of the PKIX LDAP schema work 
to define where in the directory CA's who wish to publish a certificate 
under its e-mail address should put it, or whether that work belongs in the 
S/MIME WG, but shouldn't the location be defined within one of those 
efforts? 
BTW, In view of some of the reasons why e-mail addresses are 
deprecated within DN's, I am fairly sure that the MPEG of your cat would be 
better placed in SubjectDirectoryAttributes. 

Tom Gindin 

P.S. These opinions are mine personally, and not necessarily those of my 
employer.

---

From: [email-masked]
Date: Tue, 26 Sep 2000 20:25:54 -0400

Responses below.  However, IMHO letting RP software know where the
certificate for a given e-mail address would be published if the subject
and/or CA chose to make it searchable by e-mail address would be a very
useful thing.  Is there any standard location which I have missed?
     Neither the CA nor the subject are under any obligation to make
certificates searchable in that way, of course.  That is why I didn't
address "whether", but merely "where" a certificate should be indexed.

          Tom Gindin

"Bob Jueneman" <[email-masked]> on 09/26/2000 12:40:07 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   <[email-masked]>
Subject:  Re: Certificates by e-mail address in directory schemas

Good questions, Tom. And in response I promise not to include  an MPEG of
my cat in the DN of the certificate, OR in the subjectAltName,  although
I'm still considering whether it deserves to be enshrined in
subjectDirectoryAttributes. I'll have to ask the cat -- after all, pets
have  privacy rights too, don't they? :-)

More seriously, the issue of how,  and whether, to look up a certificate
deserves a lot of thought.

I  have you listed in my address book as "Tom Gindin," and if I had your
certificate I would probably look it up that way. But if you weren't in my
personal address book or frequent contact list, would I really want to
automatically look up your certificate by e-mail address, prior to sending
you  an encrypted message? Would I even know who you were well enough to
send you a  sensitive message in the first place?

[Tom] If you were responding to an unencrypted message, you might.  In any
case, you do have my e-mail address and I don't think you know the OU in my
DN.  For people with more common names than mine, that could matter.

One of the risks here is that  I somehow mistype a name, and automatically
I get the wrong certificate, as well  as the wrong addressee. I'm sure that
we've all heard of the executive who sent  her lover an e-mail telling him
exactly and explicitly what she was going to do  to him the next time they
got together. Unfortunately, when she typed the first part of his name, the
auto-complete function filled in the rest, and without  looking she
accidentally sent it off to an "all hands" list instead of the  intended.
Embarrassing, to say the very least.

The only thing worse  would have been to send off such a message in
encrypted form to the wrong person  or list. (Well, I guess that digitally
signing it would have been even worse --  without her signature she could
perhaps claim that someone was forging mail from  her account to embarrass
her.)

[Tom] Actually, looking up a certificate for an all-hands list probably
would have produced a warning (no certificate for this entry) and she would
have avoided a lot of embarrassment.

So although I would very much like to get  out of the practice of always
sending my entire certificate chain to the same  person over and over
again, just because I signed the message, I not so sure  that I want to
automatically look up someone's certificate in a directory prior  to
sending them an encrypted message, because I'm not sure that have a
suitably  established basis for TRUST.

[Tom] I'm a little confused here.  I didn't think that sending an encrypted
e-mail demonstrated trust in the recipient of the message, in comparison to
sending him a clear e-mail.  It's more like demonstrating distrust in the
system administrator of his ISP.  It does imply some trust in the
recipient's CA.

An exception would be the case for a  legitimate all-hands encrypted
message, using the S/MIME v3 ESS capability for  sending an encrypted
message to a secure mail list server, and having that  server look up the
certificates of everyone on that list and send them an  encrypted copy. But
I think that is a special case.

Note that I am not  arguing about the desirability of looking up a
certificate in a directory. I  just want to be a little careful how I use
that capability.

[Tom] The two e-mail clients I know best require you to manually select
encryption for any message you wish to encrypt.  If you have a client like
that and you're sending to a set of named individuals, a user who chooses
encryption presumably wants the recipients' certificates acquired.

Bob

Robert R. Jueneman
Security Architect

under its e-mail address  should put it, or whether that work belongs in
the
deprecated within DN's, I am  fairly sure that the MPEG of your cat would
be

Tom Gindin

---

From: [email-masked]
Date: Wed, 27 Sep 2000 15:57:38 -0400

It is possible to populate the MAIL (actually rfc822Mailbox) attribute
with the contents of the SubjectAltName's rfc822Name, of course, and that
would be a possibility as the standard technique.  However, I still have a
few questions:
1 -  Unless PKIX standardizes a publication location, how could an RP
decide between the use of this directory attribute and PKCS#9's
emailAddress attribute?
2 -  How does an RP find out which directory (not which entry within a
directory) supports a given set of e-mail addresses?  Searches of the
global directory for values of an attribute which doesn't form part of the
name seem likely to be impractical.

          Tom Gindin

Nada Kapidzic Cicovic <[email-masked]> on 09/27/2000
04:14:52 AM

To:   Tom Gindin/Watson/IBM@IBMUS, "Bob Jueneman" <[email-masked]>
cc:   [email-masked], [email-masked]
Subject:  Re: Certificates by e-mail address in directory schemas

the
>S/MIME WG, but shouldn't the location be defined within one of those

A way (the way ?) for doing this is for the CA to populate MAIL attribute
of the EE directory entry with the e-mail address from the subjectAltName
at the same time when it populates userCertificate attribute with the
certificate. In this way users have the possibility to search the directory
tree based on the e-mail addresses, while the naming and directory schema
is not destroyed by having e-mail as one of the RDNs.

Regards,
Nada

be
>P.S. These opinions are mine personally, and not necessarily those of my

______________________________________________________________

Nada Kapidzic Cicovic, Ph.D.
Technical Director

Entegrity Solutions AB

phone:  + 46 (0)8 477 77 37
cell:   + 46 (0)70 495 09 03
fax:    + 46 (0)8 477 77 31

Finlandsgatan 60, SE-164 74 Kista, Sweden