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(_at_)missi(_dot_)ncsc(_dot_)mil'.
Internally, email addresses include hostnames - my internal address could
be (but isn't :-) something like
'dpkemp(_at_)popcorn(_dot_)missi(_dot_)ncsc(_dot_)mil'. 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(_at_)missi(_dot_)ncsc(_dot_)mil' and
'dpkemp(_at_)popcorn(_dot_)missi(_dot_)ncsc(_dot_)mil' 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(_dot_)smith(_at_)entrust(_dot_)com>
To: ietf-smime(_at_)imc(_dot_)org
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(_dot_)smith(_at_)entrust(_dot_)com http://www.entrust.com