[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Problem for public CAs



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



-----Original Message-----
From: David P. Kemp [mailto:dpkemp@xxxxxxxxxxxxxx]
Sent: Monday, February 7, 2000 13:36
To: ietf-smime@xxxxxxx
Subject: Re: Problem for public CAs


Graham,

The problem with requiring email addresses in certificates (assuming
the address is examined by Mail User Agents) is much more basic:  the
identity certified by a CA has in principle nothing to do with where
email is sent from or delivered to.  Regardless of whether I want my
Certified Net Nym to be "Dave Kemp" or "dpkemp@xxxxxxxxxxxxxx", I
should be able to send and receive S/MIME messages using any address,
including "dave@xxxxxxxxxxxxxxxxx" and "12345@xxxxxxxxxxxxxx", without
having to know in advance where I might be or who I'll be using for
an ISP.

The concept that Identification and Authentication should be independent
of transport addressing seems not to have gained traction last time
around, for some unfathomable reason.  Perhaps the spam and privacy
arguments will resonate more effectively with readers of this list.

Good luck.

Dave



> From: "Graham Laws" <lawsg@xxxxxxxxxxxxxxxxxxx>
> To: "'SMIME IETF'" <ietf-smime@xxxxxxx>
> Subject: Problem for public CAs
> Date: Mon, 7 Feb 2000 14:24:16 -0000
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
> Importance: Normal
> List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
> List-ID: <ietf-smime.imc.org>
> List-Unsubscribe: <mailto:ietf-smime-request@xxxxxxx?body=unsubscribe>
> 
> For public CAs, particularly in Europe, the requirement to place an email
> address in the subjectAltname extension of each x.509 public key
certificate
> in order to enable S/MIME is a big problem.
> 
> Firstly, all such certificates must reside in a public Directory. Any
> determined spammer is going to be able to easily create an immense spam
list
> from the Directory's entire certificate population, using a few LDAP calls
> and an ASN.1 decoder. Our customers are already nervous at the prospect of
> this, and for potential customers it may be a significant bar to take-up.
> 
> Secondly, the European Privacy Directive looks very unfavourably upon
> real-world identities being in any way expressed both in the Subject and
> SubjectAltName attributes of the public key certificate. This would appear
> to rule out S/MIME for those whose names are embedded in their email
> addresses, e.g.  graham.laws@xxxxxxxxxxxxxxxx
> 
> The issues raised by the second point are relatively easy to circumvent.
Use
> pseudonymous names for the Subject, and insist on a pseudonymous email
> address if S/MIME is required.
> 
> But the first point about the ease with which spam lists can be created is
a
> real worrier. I have looked through previous threads, including the one
> entitled "Mail addresses in S/MIME certs", but I can't find where these
> specific issues have been discussed before.
> 
> Comments/discussion via this forum welcome.
> 
> Best Regards
> Graham Laws
> 
> ______________________________________________
> Graham Laws
> PKI Systems Technical Consultant
> Royal Mail ViaCode	Phone : 	+44 (0)1246-293761
> Block A, 1st Floor	Postline : 5453-3761
> St. Mary's Court		Fax : 	+44 (0)1246-293751
> St. Mary's Gate
> Chesterfield
> S41 7TD
> 
> Public Key Validation String : MXZQ-7MM5-9A58
> 
>