[cabfpub] Defining BR scope

Erwann Abalea Erwann.Abalea at docusign.com
Thu Feb 4 17:36:11 UTC 2016

Le 4 févr. 2016 à 18:26, Erwann Abalea <Erwann.Abalea at docusign.com<mailto:Erwann.Abalea at docusign.com>> a écrit :


Le 2 févr. 2016 à 20:02, Peter Bowen <pzb at amzn.com<mailto:pzb at amzn.com>> a écrit :

On Feb 2, 2016, at 10:06 AM, Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>> wrote:


And it is certs like https://crt.sh/?id=11880495 that prove that this is true.  That certificate was issued in the last month, has no SAN or EKU, has a FQDN in the CN, and chains back to one or more roots trusted by every browser (https://gist.github.com/pzb/c55a802c283c7b44002d).  https://www.ssllabs.com/ssltest/analyze.html?d=aflsa.jag.af.mil shows that the certificate is in use at the FQDN in the CN.

According to the ssllabs analysis, the chain should fail due to policy constraints, but I’m not sure if anything enforces such constraints.


From top to bottom, the chain is:

  *   DST ACES CA X6 (trust anchor)
  *   IdenTrust ACES CA 1
  *   Federal Bridge CA 2013
  *   Federal Common Policy CA
  *   SHA-1 Federal Root CA
  *   DoD Interoperability Root CA 1
  *   DoD Root CA 2
  *   DOD CA-28
  *   aflsa.jag.af.mil

Using RFC5280 wording, valid_policy_tree is equal to NULL at « SHA-1 Federal Root CA », and the chain fails at the « DoD Root CA 2 » certificate, because now explicit_policy is equal to 0 (and valid_policy_tree is NULL).
Strangely, certificate for « DoD Interoperability Root CA 1 » has a PolicyMappings extension, but policy mapping is forbidden since « SHA-1 Federal Root CA ».
Strangely again, the PolicyConstraints extension contained in « DoD Root CA 2 » is not critical. It’s a MUST for RFC5280, and a MAY for X.509 (with a recommendation to set it critical). It’s the extension that requires an explicit policy and makes the chain fail.

OpenSSL is able to reject such a chain (it doesn’t seem to handle the policy mappings), I’ve been told that MS can correctly reject it, I’m pretty sure that the recent Mozilla PKIX lib accepts it while the previous one rejects it. (And I wouldn’t bet a cent on GnuTLS to do such things correctly)

A correction here. Mozilla should be able to reject this chain because of unhandled critical extensions upper in the chain (Federal Bridge CA 2013 and Federal Common Policy CA).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160204/798b1f2d/attachment-0003.html>

More information about the Public mailing list