Dave,
What you describe is also the practice in our organisation: a fairly simple
addressing structure is presented to the "external world" and a much richer
structure is used internally . I also agree with you that having multiple
e-mail addresses in certificates is a bad idea for several reasons: it gives
away organisational structure that in some cases is sensitive. Furthermore, it
may give away other things about the organisation, such as which employees are
involved in mobile working, for example.
In order to address this kind of requirement in S/MIME, this is precisely the
motivation for the "domain Signature" in the domain security services draft. We
have there a name mapping convention (section 3.1.1) that says that the bit on
the right-hand side of the '@' symbol in the certificate of the domain signer
must be the same as, or an ascendant of that in the originator's address. (
thus for my e-mail address,
t(_dot_)dean(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk, the domain signature
could
contain domain-signing-authority(_at_)dera(_dot_)gov(_dot_)uk).
At the last meeting, I believe there was a question raised as to whether
allowing a subset of the originators address in the domain signature is such a
good idea. Some people felt that forcing them to be identical would be better -
ie for t(_dot_)dean(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk the domain signer
must be
domain-signing-authority(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk, nothing more,
nothing less. (The
arguments were not discussed in detail.) We can't make up our minds on this
one: we are probably leaning in favour of allowing the greater flexibility, and
therefore relying on the CA naming policy to prevent certificates with
non-sensible names (e.g. tim(_at_)uk!). However, if you or others have views on
this, they would be most appreciated. We very much hope to nail down this issue
soon, so we can move the Draft towards last call.
Regards,
Tim
-----Original Message-----
From: David P. Kemp [SMTP:dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil]
Sent: 09 February 2000 14:37
To: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Problem for public CAs
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