Subject: Re: Problem for public CAs

From: "David P. Kemp" <[email-masked]>
Date: Mon, 7 Feb 2000 13:36:16 -0500 (EST)

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 "[email-masked]", I
should be able to send and receive S/MIME messages using any address,
including "[email-masked]" and "[email-masked]", 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" <[email-masked]>
> To: "'SMIME IETF'" <[email-masked]>
> 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:[email-masked]?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.  [email-masked]
> 
> 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
> 
>

---

From: Brad Smith <[email-masked]>
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:[email-masked]	http://www.entrust.com

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Monday, February 7, 2000 13:36
To: [email-masked]
Subject: Re: Problem for public CAs

Graham,

Good luck.

Dave

---

From: Alfred Arsenault <[email-masked]>
Date: Mon, 7 Feb 2000 15:34:43 -0500

Well, I don't know how AlphaTrust does this, but one system I've been
involved with in the past works as follows:

	- the directory mandates "strong authentication"; i.e., you have to
authenticate yourself cryptographically as part of binding to the directory;

	- the directory enforces the policy that only people who have
certificates issued by an approved CA can query the directory.  That is,
when you ask the directory for a certificate for user "Paul Hoffman", it
verifies via the strong authentication that:
		- you possess the private key associated with a certificate
		- that certificate was issued by an approved CA.
If you pass this check, the directory will search for the cert you want and
return it if it can find it.

	- requests from other than approved users are rejected.  If you
aren't already in my community, you don't get information from my directory.
Enforcement is via authentication to the directory; no matter who you claim
to be, if you can't authenticate using a cert from an approved CA, it's the
bit bucket for ya.

Then, the only people who can violate the policy on combing the directory
for email addresses to later be used for spam are your own users, and you
have their pledge - I hope backed up with the threat of legal action - that
they won't do so.

Bill, is that roughly how your system works?

				Al Arsenault

-- As usual, this posting reflects my own opinions only, and does not
represent the opinions or policies of my employer or any other organization
with which I may have a relationship.

Graham Laws wrote:

> Bill,
> Thanks for the reply. I am intrigued by item 3 as to how, if I wanted to
> encrypt a message to you, I would be able to find your public key
> certificate, if the CA's directory entries are not open to the public ?
(to
> avoid cross-cert issues, lets assume we both belong to the same CA).
>
> Are you assuming that correspondents will swap key files and use some
> out-of-band authentication mechanism ? Or can your clients only gain
access
> to the directory for searches, etc., by using their certificates, e.g. by
> LDAPv3 TLS or SASL ?
>
> The S/MIME requirement to place email address in the certificate severely
> weakens the PKI model with regard to privacy, and will no doubt lead to
all
> sorts of bespoke solutions for public Directories. I suspect this will
also
> lead to many interoperability problems later.
>
> Best Regards
> Graham
>
> From: Bill Brice (listserv) [mailto:[email-masked]]
> Sent: 07 February 2000 15:54
> To: 'Graham Laws'
> Subject: RE: Problem for public CAs
>
> Graham,
>
> As a US based public CA that incorporates EU Privacy and Data Protection
> directives into our PKI, we have addressed this issue as follows:
>
> 1) Our Members give their permission, as required by EU law, to
incorporate
> common names and email addresses into their certificates.
> 2) Our Members pledge, as part of their Member Agreement, not to use
another
> Members information for purposes such as spam.
> 3) Our directory entries are not open to the public, unless the Member has
> agreed
> to publish such information publicly.
> 4) Relying parties have agreed to respect the privacy rights of our
Members
> and
> not to use personally identifiable information without the Member's
> permission.
>
> Such a solution is possible with a contractually-based public PKI such as
> AlphaTrust. It is more difficult to implement with an enterprise model
> or an open model (i.e. Verisign). But then that's why we exist - to solve
> the
> sticky issues of privacy, legality and transaction risk.
>
> Food for thought.
>
> Bill Brice, CEO
> http://alphatrust.com
>
> From: Graham Laws [mailto:[email-masked]]
> Sent: Monday, February 07, 2000 8:24 AM
> To: 'SMIME IETF'

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 9 Feb 2000 09:37:13 -0500 (EST)

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 "[email-masked]'.

Internally, email addresses include hostnames - my internal address could
be (but isn't :-) something like [email-masked]'.  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 [email-masked]' and [email-masked]' 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 <[email-masked]>
> To: [email-masked]
> Date: Mon, 7 Feb 2000 14:39:57 -0500 
>

---

From: Tim Dean <[email-masked]>
Date: Wed, 9 Feb 2000 16:44:35 -0000

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, [email-masked], the domain signature could 
contain [email-masked]).

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 [email-masked] the domain signer must be 
[email-masked], 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@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:[email-masked]]
Sent:	09 February 2000 14:37
To:	[email-masked]
Subject:	RE: Problem for public CAs

Brad,

Dave

---

From: [email-masked]
Date: Wed, 9 Feb 2000 15:34:39 -0500

Yes, but just what is it that is cryptographically bound?  In many cases,
requests for a certificate are submitted via mail and the certificate is
returned by mail (or at least the notification that the certificate is ready).
We are starting to cross the line of the CA's policy.  It seems to me that the
approach to both Signature Verification and the faith put in non-disclosure have
been far too simplified.  In cases where the CA Policy is based solely on the
e-mail address then it makes sense that ALL that is cryptographicalyly bound IS
the e-mail address and this have no relevance at all to the source's claimed
identity.  If you want more than that then you should not trust such a CA, and
the binding should be to some other credential which must somehow be
incorporated into the message.

>Russ,
>
>Please describe a security vulnerability that is caused by lack of
>email address in subjectAltName.
>
>* In the case of authentication:
>I sign my own messages with (one of) my own certs.  The subject name of
>my cert is displayed to the recipient when the message signature is
>validated.  What vulnerability is introduced if a message signed by
>"C=US ... CN=David Kemp" comes from any email address, or mail list
>address, in the world?  The "from" and "reply-to" fields are both
>irrelevant to the authentication.
>
>* In the case of confidentiality:
>I want to send a message to "C=CA ... CN=Joe Smith".  I look up Joe's
>email address in my address book, which might be correct or incorrect.
>If Joe receives the message using whatever email address I have for him,
>he can read the message.  If my address book is incorrect and Fred
>receives the message, he can't read it because he doesn't have Joe's
>private key.
>
>It seems to me that if there are security vulnerabilities, they are
>the result of a flawed HMI, not a flawed certificate profile.  If
>the HMI does not associate the subjectName with the message to which
>it is cryptographically bound, you will have vulnerabilities.
>
>Dave

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 10 Feb 2000 12:02:43 -0500 (EST)

RFC 2632 is fairly clear on the requirements for email addresses:

   3. Using Distinguished Names for Internet Mail

   End-entity certificates MAY contain an Internet mail address as
   described in [RFC-822]. The address must be an "addr-spec" as defined
   in Section 6.1 of that specification.  The email address SHOULD be in
   the subjectAltName extension, and SHOULD NOT be in the subject
   distinguished name.

   Receiving agents MUST recognize email addresses in the subjectAltName
   field. Receiving agents MUST recognize email addresses in the
   Distinguished Name field in the PKCS #9 emailAddress attribute.

   Sending agents SHOULD make the address in the From or Sender header
   in a mail message match an Internet mail address in the signer's
   certificate. Receiving agents MUST check that the address in the From
   or Sender header of a mail message matches an Internet mail address
   in the signer's certificate, if mail addresses are present in the
   certificate. A receiving agent SHOULD provide some explicit alternate
   processing of the message if this comparison fails, which may be to
   display a message that shows the recipient the addresses in the
   certificate or other certificate details.

It should be obvious, but apparently is not, that "Sending and receiving
agents MUST accept certificates that do not contain an email address
in either the subject distinguished name or the subjectAltName extension."

For the son of RFC 2632, I propose:

  1) appending a sentence to that effect to the first paragraph
     of section 3.
  
  2) changing the last sentence of the third paragraph from SHOULD to MUST:
     "A receiving agent MUST provide some explicit alternate processing ..."

Individual communities of interest will profile whether their CAs
populate the subjectAltName extension, based on their judgement of
whether it is a benefit or an operational headache and security risk.
I just want to ensure that community-specific CAs have that choice, and
are not forced to populate the extension by a proliferation of
non-compliant user agents.

---

From: [email-masked]
Date: Tue, 15 Feb 2000 10:29:11 +0000

Just to play Devils advocate...
There is a third address to be considered, the Reply-to. This is a specific 
request from the originator of the message to reply to another address. If it 
is present we ought not reply to either of the other 2 addresses.

Regards,

Bartley O'Malley
Citibank NA
Lewisham House
25 Molesworth Street
London
SE13 7EX
England

Tel +44-020-7500-6473
Fax +44-020-7500-8880

-----Original Message-----
From: phoffman [SMTP:[email-masked]]
Sent: Tuesday, February 15, 2000 12:01 AM
To: ietf-smime
Cc: phoffman
Subject: Re: Problem for public CAs

At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote:
>Instead, in the case of a signed message the From address should be viewed
>as secondary, and the certificate contents the primary information.

 From a security standpoint, this is right. From a UI standpoint, it might 
not be. Assume I have a different email address in my cert than in the 
From: header of a message I send you, that your S/MIME client has informed 
you of that, and you agreed. Now you want to reply to my message. You 
probably don't want to reply to the email address in my cert, but you 
might. There are essentially two From vales: the certificate one and the 
insecure-and-possibly-altered one.

>Of course, we have to face the fact that NEITHER the DN nor the RFC822 address
>may be particularly relevant or informative.

Exactly right.

And, no, I'm not proposing a solution here.

--Paul Hoffman, Director
--Internet Mail Consortium