Subject: [pkix] Name constraints on domain name in common name

From: Matt McCutchen <[email-masked]>
Date: Fri, 19 Mar 2010 18:43:31 -0400

The Mozilla community has recognized that to be effective, name
constraints must apply to the common name field when it is being used to
hold the domain name of a TLS server (a legacy practice):

https://bugzilla.mozilla.org/show_bug.cgi?id=394919

RFC 5280 does not mention this issue.  We're currently trying to decide
under what circumstances to accept a certificate that is subject to a
name constraint and has a common name but no dNSName subjectAltNames.
Suggestions would be very welcome.

-- 
Matt

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Mar 2010 16:53:52 -0400

>Suggestions would be very welcome.

Name constraints are name-type specific, so a dNSName constraint 
would not apply to a DNS name (inappropriately :-)) represented as a 
common name. I'm afraid that this is another unfortunate side effect 
of accommodating a wide spread practice that was ill-advised.

You say above "... name constraints must apply to the common name 
field when it is being used to hold the domain name of a TLS server 
..." Name constraints can be applied to distinguished name attributes 
like common names, but they have to be expressed as those attribute 
types. Common name has no general sub-structure, so I don't think you 
can construct a name constraint that applies to the CN other than a 
completely-specified CN value.  That probably does not address the 
problem that the bug report cites.

Steve

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 23 Mar 2010 19:50:52 -0400

On Tue, 2010-03-23 at 16:53 -0400, Stephen Kent wrote:
> completely-specified CN value.

That's all correct.  RFC 5280 is sane and self-consistent.  The trouble
is that, when one adds support for the legacy practice of putting the
server name in the common name (as documented in RFC 2818), name
constraints become insecure, and the RFCs do not contain any guidance as
to what to do about that.

Mozilla currently supports the legacy practice and plans to remove
support, but it isn't realistic to do so yet:

https://bugzilla.mozilla.org/show_bug.cgi?id=552346

In the interim, we want name constraints to be secure, so we're looking
for a reasonable modification to the rules stated in RFC 5280 that will
achieve that.  The current plan is to constrain the common name as an IP
address if it looks like one or a DNS name otherwise, provided that
there are no subjectAltNames of the same type.

-- 
Matt

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 23 Mar 2010 19:52:56 -0400

I think it is a good practice to apply name constraints for things such
as e-mail address (if it appears in the DN) and dnsName appearing CN of
web servers. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Matt McCutchen
> Sent: Tuesday, March 23, 2010 7:51 PM
> To: Stephen Kent
> Cc: [email-masked]
> Subject: Re: [pkix] Name constraints on domain name in common name
> 
> > Name constraints are name-type specific, so a dNSName 
> constraint would 
> > not apply to a DNS name (inappropriately :-)) represented 
> as a common 
> > name. I'm afraid that this is another unfortunate side effect of 
> > accommodating a wide spread practice that was ill-advised.
> > 
> That's all correct.  RFC 5280 is sane and self-consistent.  
> The trouble is that, when one adds support for the legacy 
> practice of putting the server name in the common name (as 
> documented in RFC 2818), name constraints become insecure, 
> and the RFCs do not contain any guidance as to what to do about that.
> 
> Mozilla currently supports the legacy practice and plans to 
> remove support, but it isn't realistic to do so yet:
> 
> In the interim, we want name constraints to be secure, so 
> we're looking for a reasonable modification to the rules 
> stated in RFC 5280 that will achieve that.  The current plan 
> is to constrain the common name as an IP address if it looks 
> like one or a DNS name otherwise, provided that there are no 
> subjectAltNames of the same type.
> 
> --
> Matt
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 23 Mar 2010 20:18:15 -0400

On Tue, 2010-03-23 at 19:52 -0400, Santosh Chokhani wrote:
> as e-mail address (if it appears in the DN)

Right.  RFC 5280 says to constrain an email address in the DN if there
is no subjectAltName email address:

http://tools.ietf.org/html/rfc5280#section-4.2.1.10

Mozilla NSS constrains it unconditionally:

https://mxr.mozilla.org/mozilla/source/security/nss/lib/certdb/genname.c#1112

I agree that a DN email address that violates the name constraint is
dodgy and deserves to be rejected even if there is a subjectAltName.

> and dnsName appearing CN of
> web servers.

Unlike with the email address, it's impossible to guess with perfect
accuracy whether the CN was intended to be a DNS name or something
completely different such as a person's name.  Thus, we were planning to
constrain the CN only when necessary for security, i.e., when there is
no subjectAltName of the same type.

-- 
Matt

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 24 Mar 2010 14:15:09 -0400

I agree it's a good idea, but I don't think there needs to be a change to 5280 to support it.  Purely an implementation decision.

-- Tim

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Santosh Chokhani
>Sent: Tuesday, March 23, 2010 6:53 PM
>To: Matt McCutchen; Stephen Kent
>Cc: [email-masked]

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 24 Mar 2010 14:24:02 -0400

On Wed, 2010-03-24 at 14:15 -0400, Miller, Timothy J. wrote:
> I agree it's a good idea, but I don't think there needs to be a change
> to 5280 to support it.  Purely an implementation decision.

I'm not seeking an official amendment to RFC 5280, only a consensus
among people facing this issue so I can be more confident that Mozilla
is taking a reasonable approach.

-- 
Matt

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 24 Mar 2010 14:47:26 -0400

> The current plan is to constrain the common 
> name as an IP address if it looks like one or a DNS name otherwise, 
> provided that there are no subjectAltNames of the same type.

Because CN is such a cloaca, almost any non-standardized way of dealing
with the mess is reasonable.  Your problem is easy - we have to deal
with a foul mixture of personal names, unique identifiers and
affiliation types.

+1 on the approach.

Dave

-----Original Message-----
From: Matt McCutchen

---

From: Geoff Beier <[email-masked]>
Date: Wed, 24 Mar 2010 14:52:19 -0400

> no subjectAltName of the same type.

In the context of https without a subjectAltName of type dNSName in
the server's certificate, RFC 2818 says the CN must be used. It also
says that if the URI of the server specifies an IP address rather than
a hostname, "tthe iPAddress subjectAltName must be present in the
certificate and must exactly match the IP in the URI."

So it would seem that in cases where you have dNSName constraints for
the cert path but don't have a dNSName subjectAltName, if you first
make sure the cn matches the server name specified in your URI and
that it's not a numeric IP address, it's perfectly perfectly sane to
apply those constraints to the CN and reject the certificate if it
doesn't meet them. It doesn't seem like you need to guess with perfect
accuracy since you know you're doing HTTPS; if the CN isn't a host
name and there's not an appropriate subjectAltName you've got a bad
cert anyway.

Geoff

---

From: Tom Gindin <[email-masked]>
Date: Thu, 25 Mar 2010 09:03:53 -0400

Matt:

        For whatever it's worth, putting a DNS name in the subject which 
is not also present in SubjectAltName seems to violate the first paragraph 
of RFC 5280 4.2.1.6.  I don't see any wording which prohibits CN's from 
containing DNS names, though.
        This is just my opinion, but isn't a CN attribute which contains 
periods and alphanumerics, and which contains no other characters except 
hyphens and underscores probably either a DNS name or an IP address, and a 
DNS address if it contains a period followed by an alpha?  Contrariwise, 
isn't a CN attribute which contains spaces or commas, or one which doesn't 
contain periods, NOT a DNS name?  While this is hardly definitive, I for 
one have never seen a CN representing a personal name which contained 
periods but no commas or spaces.

                Tom Gindin

P.S. - The opinions above are mine, and not necessarily those of my 
employer

From:
Matt McCutchen <[email-masked]>
To:
Santosh Chokhani <[email-masked]>
Cc:
[email-masked]
Date:
03/23/2010 08:22 PM
Subject:
Re: [pkix] Name constraints on domain name in common name
Sent by:
[email-masked]

-- 
Matt

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 01 Apr 2010 01:59:06 +0100

Matt,

First I fully agree with all statements that the practice to put a dns name
inside the common name is a totally no standardized behavior.

No one that just follow RFC 5280 can be sure that the data stored in CN
actually holds a common name value. This requires some further knowledge
about the practice employed by the CA.

However:
This has for very long been a common practice for web server certificates,
where many certificates in fact use CN for this purpose.

It is also perfectly legal to discard a certificate that is used for server
authentication if the CN does not match name constraints on dNSName.

RFC 5280 states in section 6:
   An implementation MAY augment the algorithm presented in Section 6.1
   to further limit the set of valid certification paths that begin with
   a particular trust anchor.  For example, an implementation MAY modify
   the algorithm to apply a path length constraint to a specific trust
   anchor during the initialization phase, or the application MAY
   require the presence of a particular alternative name form in the
   target certificate, or the application MAY impose requirements on
   application-specific extensions.  Thus, the path validation algorithm
   presented in Section 6.1 defines the minimum conditions for a path to
   be considered valid.

It IS actually common practice to apply dNSName constraints on CN when the
certificate has server auth EKU set. This practice is implemented by the
Microsoft path validation logic in MSCAPI. It is considered the best
security practice considering how server certificates are issued in
practice.

/Stefan