RE: Problem for public CAs

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

Brad,

The problem is that I may not *want* to have two or more E-mail
addresses within the subjectAltName extension of my certificates.

Many organizations choose to present organizational email addresses
for all employees, regardless of how email is delivered within the
organization.  My external address is "dpkemp@xxxxxxxxxxxxxx'.

Internally, email addresses include hostnames - my internal address could
be (but isn't :-) something like 'dpkemp@xxxxxxxxxxxxxxxxxxxxxx'.  Our
network administrators have configured Microsoft Outlook so that users
use internal addresses for their internal workstations.  As far as I
know, that is standard practice.  If S/MIME requires transport addresses
to be present in certificates, that means my certificate MUST contain
both 'dpkemp@xxxxxxxxxxxxxx' and 'dpkemp@xxxxxxxxxxxxxxxxxxxxxx' if I
want to be able to both send and receive S/MIME messages.

This is a defect.  I claim that the defect is with the S/MIME spec,
not with the mail transport infrastructure.

Dave



> From: Brad Smith <brad.smith@xxxxxxxxxxx>
> To: ietf-smime@xxxxxxx
> Subject: RE: Problem for public CAs
> Date: Mon, 7 Feb 2000 14:39:57 -0500 
> 
> Unless I'm misunderstanding what you're saying, recall that 'subjectAltName'
> is allowed to have multiple values. So, for example, your own certificate
> can have all three E-mail addresses within.
> 
> The advantage is that somebody doing a search on any of your known E-mail
> addresses will always return the same certificate.
> 
> The downside (or, certainly, *a* downside) is that if somebody knows, for
> example, your Compuserve address, he can do a directory search for that, get
> your certificate, and from that learn all your other E-mail addresses.
> 
> On the other hand, if you send a signed message, presumably your digital
> signature would contain all that information anyway.
> 
> Alas, I'm unable to suggest any solutions. If it were a major issue to me
> personally, I'd just not allow my certificate to be published in any public
> CAs. But that's probably not the answer you're looking for. :-)
> 
> Brad.
> --
> Brad P. Smith   [Development Lead - Entrust/Express]
> Entrust Technologies Inc.
> 750 Heron Road, Suite E800
> Ottawa, Ontario, K1V 1A7, Canada
> mailto:brad.smith@xxxxxxxxxxx	http://www.entrust.com