[Top] [All Lists]

RE: Problem for public CAs

2000-02-09 09:41:11

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 
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.


-----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


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.


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 P. Smith   [Development Lead - Entrust/Express]
Entrust Technologies Inc.
750 Heron Road, Suite E800
Ottawa, Ontario, K1V 1A7, Canada

<Prev in Thread] Current Thread [Next in Thread>