Subject: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Constraints

From: Santosh Chokhani <[email-masked]>
Date: Mon, 9 Apr 2012 11:07:39 -0400

This relates to the name constraints discussion going on in another thread.

Does anyone know how the browsers handle a Server certificate if subject alternative name is absent and the DN (specifically Common Name) contains the FQDN?

Related to this does anyone know what the browsers do with this name form if the certification path has URL or DNS Names constrained?  Do, they enforce the applicable constraints on them.

I did not find language in 5280 that deal with this.  I may have missed something.

Santosh Chokhani
CygnaCom Solutions

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 09 Apr 2012 17:21:35 +0200

On 2012-04-09 17:07, Santosh Chokhani wrote:
> Does anyone know how the browsers handle a Server certificate if subject
> alternative name is absent and the DN (specifically Common Name) contains the FQDN?

That works fine with all major browsers.

> Related to this does anyone know what the browsers do with this name form if
> the certification path has URL or DNS Names constrained?  Do, they enforce
> the applicable constraints on them.

I guess few of us has ever seen a certificate with name constraints.
I haven't at least so I can unfortunately not help you on this one.

Thanx
Anders

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Ryan Sleevi" <[email-masked]>
Date: Mon, 9 Apr 2012 08:22:45 -0700

>  Related to this does anyone know what the browsers do with this name form
>  if the certification path has URL or DNS Names constrained?  Do, they
>  enforce the applicable constraints on them.
>

NSS, used by both Mozilla Firefox (all platforms) and Google
Chrome/Chromium (Linux) constrains the CN-ID if the CN-ID appears to have
a FQDN and dNSNames are constrained. The applicable bug number that
implemented this behaviour is
https://bugzilla.mozilla.org/show_bug.cgi?id=394919

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 10 Apr 2012 09:58:10 +0200

Hi,

Can someone describe how in sight of rfc 6125 one can effectively
construct name constraints that allow to only have services
maiul, web, etc to *.example.com, fallback to common name
included.

    C=NN; O="white rabbit";  cn="www.example.com"

Thanks.

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 10 Apr 2012 10:05:00 +0200

---------- Message transféré ----------
De : "Erwann Abalea" <[email-masked]>
Date : 9 avr. 2012 18:00
Objet : Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name
Constraints
À : <[email-masked]>

Only when you use libpkix.
I played with NC yesterday, critical and non critical, constrained with
dnsname. An SSL certificate containing a bad CN is not detected. The same
certificate with the fqdn placed in the SAN is detected and rejected.
Firefox 3.6.8.

-- 
Erwann.

Le 9 avr. 2012 17:22, "Ryan Sleevi" <[email-masked]> a écrit :

> >  alternative name is absent and the DN (specifically Common Name)
contains
> >  the FQDN?

---

From: Martin Rex <[email-masked]>
Date: Thu, 12 Apr 2012 21:05:19 +0200 (MEST)

Santosh Chokhani wrote:
> contains the FQDN?
> Related to this does anyone know what the browsers do with this name
> form if the certification path has URL or DNS Names constrained?
> Do, they enforce the applicable constraints on them.
> 

You did not miss it, that is currently undefined.

NameConstraints processing happens entirely within the certificate
path validation algorithm of the PKIX module (rfc5280, section 6.1),
whereas server endpoint identification is something completely
unrelated, that is performed by the application on top of TLS
(such as rfc2818 or rfc6125).

These two operations are conceptually unrelated, and the application
does its server endpoint identification based only on the Server
certificate and typically ignorant of any other certs in the
server's certification path and potentially at a different time.
E.g. basic certificate path validation might be performed by
TLS itself when processing the respective Certificate handshake
message and before using the crypto keys, whereas (Server) endpoint
identification and certificate revocation checking might be performed
after the TLS handshake has successfully completed.

The issue of name constraints and its interaction with CN-ID matching
by TLS clients doing server endpoint identification was discussed
on the certid  (-> rfc6125) mailing list in mid of 2010, but I'm not
aware of any changes of PKIX processing rules for name constraints
so far.

-Martin

Btw. just today a customer message floated by from a customer that was
trying to use a server cert from a PKI with name constraints in the
CA cert above the leaf cert.  Those name constraints were marked critical
an therefore the server cert rejected by our PKI software.

The size of the name constraints was "impressive" and some of the
contents confusing.  Among it, an otherName MS-UPN constraint (both
permitted and excluded subtree) -- but I'm not aware of a public
specificiation for this SAN and its name constraints processing).

The contents were:
    permitted:    1x MS-UPN, value ""
                  1x rfc822name, value "[email-masked]"
                  5x DNSName, values like ".somedomain.dir"
                 37x directoryName
                  5x URI, values exactly same as DNSName values
    excluded:     1x MS-UPN, value "."
                  8x DNSName, values like ".root.somedomain.dir"
                  8x URI, values exactly same as DNSName values

Processing such a large list of name constraints probably burns more
CPU cycles than processing the 1024-bit sha1WithRSA signature verification
with that cert...

What confused me:
 - is an name constraint URI with a value ".somedomain.dir"
   correct, doesn't that need to start with a schema?
 - the rfc822name looks like _completely_ hardwired for certs issued
   by that subCA 
 - the server cert that the customer was trying to install did not
   contain a DNSName SAN, but only a hostname in CN of the subject name
   (i.e. unconstrained).

A CA software that is capable of creating a TLS Server certificate with
the id-kp-serverAuth and a CA-cert with DNSName name constraints ought
not issue a TLS Server cert without the hostname in a DNSName SAN...

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 12 Apr 2012 15:11:50 -0400

Martin,

May be you can send me the actual certificate chain and I can see what the issues are.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Thursday, April 12, 2012 3:05 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Constraints

Santosh Chokhani wrote:
> Does anyone know how the browsers handle a Server certificate if 
> subject alternative name is absent and the DN (specifically Common 
> Name) contains the FQDN?
> 

NameConstraints processing happens entirely within the certificate path validation algorithm of the PKIX module (rfc5280, section 6.1), whereas server endpoint identification is something completely unrelated, that is performed by the application on top of TLS (such as rfc2818 or rfc6125).

These two operations are conceptually unrelated, and the application does its server endpoint identification based only on the Server certificate and typically ignorant of any other certs in the server's certification path and potentially at a different time.
E.g. basic certificate path validation might be performed by TLS itself when processing the respective Certificate handshake message and before using the crypto keys, whereas (Server) endpoint identification and certificate revocation checking might be performed after the TLS handshake has successfully completed.

The issue of name constraints and its interaction with CN-ID matching by TLS clients doing server endpoint identification was discussed on the certid  (-> rfc6125) mailing list in mid of 2010, but I'm not aware of any changes of PKIX processing rules for name constraints so far.

-Martin

Btw. just today a customer message floated by from a customer that was trying to use a server cert from a PKI with name constraints in the CA cert above the leaf cert.  Those name constraints were marked critical an therefore the server cert rejected by our PKI software.

The size of the name constraints was "impressive" and some of the contents confusing.  Among it, an otherName MS-UPN constraint (both permitted and excluded subtree) -- but I'm not aware of a public specificiation for this SAN and its name constraints processing).

The contents were:

Processing such a large list of name constraints probably burns more CPU cycles than processing the 1024-bit sha1WithRSA signature verification with that cert...

What confused me:

A CA software that is capable of creating a TLS Server certificate with the id-kp-serverAuth and a CA-cert with DNSName name constraints ought not issue a TLS Server cert without the hostname in a DNSName SAN...

---

From: Martin Rex <[email-masked]>
Date: Fri, 13 Apr 2012 02:32:21 +0200 (MEST)

Santosh Chokhani wrote:
>>     permitted:    ...
>>                   ...

Re-scanning rfc5280 (where the syntax of GeneralName in the context of
NameConstraints appears to be specified here):

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

it seems that the name constraints specified for URI are correct,
but the NameConstraints specified for DNSName are invalid.
Different to domain names in URI and rfc822Name Constraints,
DNSName Constraints do not permit a leading dot.

Cross-checking with the implementation of name constraints in
openssl-1.0.0h/crypto/x509v3/v3_ncons.c, that code appears to
be according to the spec and fail comparison with
such a malformed DNSName NameConstraints -- in case there is
a DNSName present in the End-Entity cert (which wasn't...).

The openssl-1.0.0x codebase seems to include name constraints processing,
plus a check of rfc822Name Constraints against an EMail= RDName
of the subject name. It does not (currently) seem to contain
a check for DNSName Constraints against CN=f.q.d.n.
(neither rfc5280/PKIX nor X.509 specify such DName cross-checks).

Passing that customers cert-chain to openssl (0.9.8j-fips) on our newest
SLES-11sp1 machines, results in a confusing output:

  openssl verify -verbose -CAfile root.pem -untrusted pathcerts.pem -purpose sslserver server.cer 
  server.cer: /DC=dir/DC=...
  error 34 at 1 depth lookup:unhandled critical extension
  OK

What does this tell me?  I would have expected either an error
or an OK, but not both!

apps/verify.c looks like this:
	i=X509_verify_cert(csc);
	X509_STORE_CTX_free(csc);

	ret=0;
end:
	if (i > 0)
		{
		fprintf(stdout,"OK\n");
		ret=1;
		}

and the documentation for X509_verify_cert() says this:
   http://www.openssl.org/docs/crypto/X509_verify_cert.html

  RETURN VALUES

  If a complete chain can be built and validated this function returns 1 ...

  NOTES

  Applications rarely call this function directly but it is used by OpenSSL
  internally for certificate validation, in both the S/MIME and SSL/TLS code. 

which looks to me like OpenSSL-0.9.8x is (silently) ignoring critical
name constraints.

-Martin

btw. I consider the context-sensitive syntax rule for the
ASN.1 type GeneralName extremely confusing!

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 12 Apr 2012 20:53:56 -0400

Martin,

I do not see either the rfc2818 or rfc6125 addressing name constraints application to DNS names appearing in CN of Subject field.

Am I missing something?

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Thursday, April 12, 2012 3:05 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Constraints

-Martin

The contents were:

What confused me:

---

From: Martin Rex <[email-masked]>
Date: Fri, 13 Apr 2012 03:24:55 +0200 (MEST)

Santosh Chokhani wrote:
> 
> I do not see either the rfc2818 or rfc6125 addressing name constraints
> application to DNS names appearing in CN of Subject field.
> 
> Am I missing something?

No.  There is nothing in those document, and IMO it would be inappropriate
to put it in those documents.

NameConstraints are exclusively a PKIX-internal(!) thing.  For an RP,
NameConstraints processing is completely hidden inside the
certificate path validation function of the PKIX module.

One possible approach might be to add a new optional
input parameter (k) to rfc-5280 6.1.1  so that the caller can
identify the desired key purpose(s), and then extend the
processing in rfc-5280 6.1.3 (c) for two conditions:

  - if the application caller supplied the id-kp-serverAuth as input,
    check whether the cert is allowed for id-kp-serverAuth should it be
    purpose-limited by an EKU extension, and if EKU id-kp-serverAuth
    is asserted, process DNSName constraints for every CN= Attributes
    in the subject DName.

  - if the application caller supplied the id-kp-emailProtection as input,
    check whether the cert is allowed for id-kp-emailProtection should it
    be purpose-limited by an EKU extension, and if EKU id-kp-emailProtection
    is asserted, process rfc822Name constraints for every pkcs9_emailAddress
    Attributes in the subject DName.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 12 Apr 2012 21:29:21 -0400

I was thinking something simpler: Just like RFC 5280 describes name constraints for RFC 822 names need to be enforced when they appear in DN, they need to be enforced on DNS name when they appear in CN.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Thursday, April 12, 2012 9:25 PM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name

> application to DNS names appearing in CN of Subject field.

No.  There is nothing in those document, and IMO it would be inappropriate to put it in those documents.

NameConstraints are exclusively a PKIX-internal(!) thing.  For an RP, NameConstraints processing is completely hidden inside the certificate path validation function of the PKIX module.

One possible approach might be to add a new optional input parameter (k) to rfc-5280 6.1.1  so that the caller can identify the desired key purpose(s), and then extend the processing in rfc-5280 6.1.3 (c) for two conditions:

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 13 Apr 2012 03:45:22 +0200 (MEST)

Santosh Chokhani wrote:
> 
> I was thinking something simpler: Just like RFC 5280 describes name
> constraints for RFC 822 names need to be enforced when they appear in DN,
> they need to be enforced on DNS name when they appear in CN.

pkcs9-emailAddress is a fairly non-ambiguous attribute label,
so applying rfc822Name constraints processing need not necessarily
be limited to the emailProtection purpose.

The situation with 2.5.4.cn(3) might be different, where applying
DNSName constraints should probably be limited to purposes of
id-kp-serverAuth.

-Martin

PS: I hadn't noticed the graf about pkcs9-emailAddress on rfc5280 page41
that appears mislocated because it is seperated from the description
of the EMail constraints processing with the description of DNSName
processing.  Btw. limiting the constraints to situations where no
subjectAltName is present seems _very_ wrong, because the application
code looking at cert attributes and the PKIX code processing name
constraints are _very_ often independently maintained!

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 12 Apr 2012 21:58:10 -0400

Good points.

I would like to apply name constraints  to a field for appropriate name form  if a relevant RFC says that the application can use value from that field as a application specific name.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Thursday, April 12, 2012 9:45 PM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name

Santosh Chokhani wrote:
> constraints for RFC 822 names need to be enforced when they appear in 
> DN, they need to be enforced on DNS name when they appear in CN.

pkcs9-emailAddress is a fairly non-ambiguous attribute label, so applying rfc822Name constraints processing need not necessarily be limited to the emailProtection purpose.

The situation with 2.5.4.cn(3) might be different, where applying DNSName constraints should probably be limited to purposes of id-kp-serverAuth.

-Martin

PS: I hadn't noticed the graf about pkcs9-emailAddress on rfc5280 page41 that appears mislocated because it is seperated from the description of the EMail constraints processing with the description of DNSName processing.  Btw. limiting the constraints to situations where no subjectAltName is present seems _very_ wrong, because the application code looking at cert attributes and the PKIX code processing name constraints are _very_ often independently maintained!

---

From: Martin Rex <[email-masked]>
Date: Fri, 13 Apr 2012 05:42:44 +0200 (MEST)

Having looked more closely at what apps/verify.c really does,
it is shooting itself in the foot with respect to the "OK" output,
because apps/verify.c insert a callback function that converts
X509_V_ERR_UNHANDLED_CRITICAL_EXTENSION into "OK"...

I'm sorry for spreading confusion to others (I am still confused myself).

-Martin