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

From: "Hill, Brad" <[email-masked]>
Date: Wed, 18 Apr 2012 02:50:20 +0000

Martin,

 Certificates issued according to the CABF BR 1.0 contain both a Subject CN and a DNSName SAN.

 If the same host name is expressed in both Subject CN and a SAN of type DNSName, and DNSName Constraints apply, what is the behavior if the Name Constraint is violated?

Pass, because Subject CN matches and is not subject to the constraint?

Fail, because the Subject CN is ignored when an appropriately-typed SAN is present, and the SAN is subject to the NC?

Thanks,

Brad Hill

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Rex
> Sent: Thursday, April 12, 2012 5:32 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name
> 
> Santosh Chokhani wrote:
> >
> >> The contents were:
> >>     permitted:    ...
> >>                   5x DNSName, values like ".somedomain.dir"
> >>                   ...
> >>                   5x URI, values exactly same as DNSName values
> >
> > May be you can send me the actual certificate chain and I can see what
> > the issues are.
> 
> 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!
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Apr 2012 05:23:39 +0200 (MEST)

Hill, Brad wrote:
> If the same host name is expressed in both Subject CN and a SAN of
> type DNSName, and DNSName Constraints apply, what is the behavior
> if the Name Constraint is violated?
> 
> Fail, because the Subject CN is ignored when an appropriately-typed
> SAN is present, and the SAN is subject to the NC?

That resulting behaviour is quite implementation-defined.
(i.e. you'll have to test each and every App(!!) individually to find out).

There seem to exist some (newer versions of certain) browsers that
apply DNSName constraints to CN= when matching to CN= and cause a failure.

OpenSSL 0.9.8x (and allegedly iOS 5) unconditionally abort when
they encounter a Name constraints extension that is marked critical.

While OpenSSL 1.0.0x can process name constraints, it will never apply
DNSName constraints to the CN of a certificate's subject DName
(this is not specified in rfc5280), and other than for pkcs9-EmailAddress,
the certificate path validation function of a PKIX module regularly does
not know about the usage scenario in which it is being called anyway
-- blindly applying DNSName constraints on the CN= part of a subject
DName seems like a bad idea.

Applications that are independently maintained from its TLS-implementation
might be looking exclusively at CN= and be completely ignorant about SANs.
Potential candidates: curl/wget.

Or Applications or TLS-using middleware might _always_ be looking
at both, SAN and CN= (ours needs to, for backward compatibility,
and not support NameConstraints or not apply DNS Name constraints to CN=.

Adding support for matching to SANs does not break any usage scenarios
in the installed base, but no longer matching CN= might, so unconditionally
disabling such matching when sneaking out "feature updates" as part of a
patch is not an option for a responsible software supplier.
One could offer a configuration option for callers, so that consumers of
the technology that want strict, and potentiall backwards-incompatible
behaviour, can explicitly request it.

Considering what crappy CA-Software is out there, that will boldly
create certs with invalid DNSName constraints in it, and boldly issue
TLS ServerCerts below such a CA without DNSName SANs it it,
then this is really a minefield, where you hardly would want to
ship backwards-incompatible changes into the installed base.

-Martin