Subject: [Spasm] Can we address the emailAddress DN issue

From: Sean Leonard <[email-masked]>
Date: Sat, 18 Jun 2016 07:29:56 -0700

Since we are spending all this time on eai addresses in GeneralName, can 
we address the emailAddress DN issue, and the mail (or other identifier) 
LDAP issue?

Many LDAP directories store e-mail addresses in the mail 
0.9.2342.19200300.100.1.3 attribute (derived from COSINE).

RFC 5280 (and S/MIME) say specific things about handling the 
emailAddress 1.2.840.113549.1.9.1 attribute (derived from PKCS #9).

I think we ought to deal with it/them.

Even if you are of the view that emailAddress is a legacy attribute that 
ought not be used for "new applications", there's no denying that CAs 
still issue certificates with that attribute. Furthermore, the mail 
attribute is actively used in LDAP, including (for example) as an LDAP 
search query term to look up certificates.

Ideally we could unify the attributes so that both LDAP and 
(PKIX-related) DN use the same attribute.

Sean

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Jun 2016 12:53:32 -0400

Sean:

The emailAddress attribute is defined n PKCS#9 (which was republished as RFC 2985).  I do not see how we could redefine this attribute.  A new attribute would need to be defined to carry an internationalized email address, and then the various procedures for name constraints would also need to be specified.

Russ

On Jun 18, 2016, at 10:29 AM, Sean Leonard <[email-masked]> wrote:

> Since we are spending all this time on eai addresses in GeneralName, can we address the emailAddress DN issue, and the mail (or other identifier) LDAP issue?
> 
> Many LDAP directories store e-mail addresses in the mail 0.9.2342.19200300.100.1.3 attribute (derived from COSINE).
> 
> RFC 5280 (and S/MIME) say specific things about handling the emailAddress 1.2.840.113549.1.9.1 attribute (derived from PKCS #9).
> 
> Even if you are of the view that emailAddress is a legacy attribute that ought not be used for "new applications", there's no denying that CAs still issue certificates with that attribute. Furthermore, the mail attribute is actively used in LDAP, including (for example) as an LDAP search query term to look up certificates.
> 
> Ideally we could unify the attributes so that both LDAP and (PKIX-related) DN use the same attribute.
> 
> Sean

---

From: Sean Leonard <[email-masked]>
Date: Mon, 20 Jun 2016 10:09:26 -0700

My jab is that we ought to work on a new attribute, 
"internationalizedEmailAddress" (or simply "eai"), that is used by both 
security applications (i.e., PKIX) and directory applications (i.e., LDAP).

It is a thorn in our collective side that mail and emailAddress are 
defined as IA5String and caseIgnoreMatch /pkcs9CaseIgnoreMatch. RFC 5280 
even has a warning about that issue (based on PKCS #9 aka RFC 2985). I 
am not proposing that we redefine the emailAddress or mail attributes. 
However, if we do work on an eai attribute, the overlap will have to be 
addressed.

(May I suggest that an eai attribute be case sensitive, and that 
local-part email addresses that are known to be case sensitive, or are 
unknown whether they are case sensitive or not, ought to be put in eai 
attribute and NOT in emailAddress/mail attributes.)

Sean

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 20 Jun 2016 11:22:35 -0700

I would be against defining a new attribute unless there was someplace other
than a certificate where this attribute was going to be used.  Certificates
are defined to use subject other names for this type of entry, putting into
the subject field means that there are two places that need to be checked.
This does not seem to be an advantage.

Jim

> -----Original Message-----
> From: Spasm [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Monday, June 20, 2016 9:54 AM
> To: Sean Leonard <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Spasm] Can we address the emailAddress DN issue
> 
> Sean:
> 
> The emailAddress attribute is defined n PKCS#9 (which was republished as
RFC
> 2985).  I do not see how we could redefine this attribute.  A new
attribute would
> need to be defined to carry an internationalized email address, and then
the
> various procedures for name constraints would also need to be specified.
> 
> Russ
> 
> 
we
> address the emailAddress DN issue, and the mail (or other identifier) LDAP
issue?
> > RFC 5280 (and S/MIME) say specific things about handling the
emailAddress
> 1.2.840.113549.1.9.1 attribute (derived from PKCS #9).
> >
ought
> not be used for "new applications", there's no denying that CAs still
issue
> certificates with that attribute. Furthermore, the mail attribute is
actively used in
> LDAP, including (for example) as an LDAP search query term to look up
> certificates.
> >
(PKIX-related) DN
> use the same attribute.
> >
> > Sean
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Sean Leonard <[email-masked]>
Date: Mon, 20 Jun 2016 17:50:38 -0700

Again, the mail attribute is used extensively by many LDAP 
implementations, and by certificate-fetching systems when looking up 
certificates via LDAP.

I am not aware how prevalent it is to store the emailAddress attribute 
in LDAP. We need an LDAP expert to say. However, I would venture a guess 
that it's more than 0.

I agree that it would be a good idea to discourage or prohibit putting 
e-mail addresses of any kind in the Subject DN. Perhaps the eai draft 
should say something about that, i.e., don't attempt to shoehorn 
emailAddress in when a SAN is an eaiName (because it's not syntactically 
compatible).

However, there are CA issuers who issue free e-mail certificates, where 
the only thing they really check is the e-mail address. What therefore 
should those issuers put in the subject field, when they can't put an 
e-mail address properly identified as an emailAddress?

They could put the e-mail address in the Common Name, but that runs the 
same risk as what happened with ye olde SSLv3- certificates, where 
people checked the CN for domain name content. (Some CAs to my knowledge 
put e-mail address content in both the E and CN fields in the subject DN.)

It seems that since E can't be used and you don't want to put a 
different field in, the draft should say something about the 
consequences of either a blank DN (namely the UI and identification 
issues), or that it's necessary to put some random junk such as 
SERIALNUMBER, UUID, DESCRIPTION, etc. in the subject field anyway.

Sean

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 20 Jun 2016 19:44:35 -0700

> From: Spasm [mailto:[email-masked]] On Behalf Of Sean Leonard
> Sent: Monday, June 20, 2016 5:51 PM
> To: Jim Schaad <[email-masked]>; 'Russ Housley'
> <[email-masked]>
> Cc: [email-masked]
implementations, and
> by certificate-fetching systems when looking up certificates via LDAP.
> 
> I am not aware how prevalent it is to store the emailAddress attribute in
LDAP.
> We need an LDAP expert to say. However, I would venture a guess that it's
more
> than 0.
e-mail
> addresses of any kind in the Subject DN. Perhaps the eai draft should say
> something about that, i.e., don't attempt to shoehorn emailAddress in when
a
> SAN is an eaiName (because it's not syntactically compatible).
> 
the only
> thing they really check is the e-mail address. What therefore should those
> issuers put in the subject field, when they can't put an e-mail address
properly
> identified as an emailAddress?

You do not put anything in the subject field.  It is an empty sequence.  You
put the name in the SubjectAltName extension and mark it critical.  The only
case that this would be a problem for is if you had a CA which has an email
name as it's only subject name.   However, this is a corner case that I
would be happy to let die.

RFC 5280 says that you should not be using the emailAddress field in the
subject anyway.  This is deprecated behavior.

Jim

> They could put the e-mail address in the Common Name, but that runs the
same
> risk as what happened with ye olde SSLv3- certificates, where people
checked
> the CN for domain name content. (Some CAs to my knowledge put e-mail
> address content in both the E and CN fields in the subject DN.)
> 
> It seems that since E can't be used and you don't want to put a different
field in,
> the draft should say something about the consequences of either a blank DN
> (namely the UI and identification issues), or that it's necessary to put
some
> random junk such as SERIALNUMBER, UUID, DESCRIPTION, etc. in the subject
> field anyway.
> 
> Sean
> 
> > I would be against defining a new attribute unless there was someplace
> > other than a certificate where this attribute was going to be used.
> > Certificates are defined to use subject other names for this type of
> > entry, putting into the subject field means that there are two places
that need
> to be checked.