1444455 - DocuSign/Keynectis: Non-Compliant Technically Constrained Intermediates

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

Two Keynectis subordinate CAs have not been properly disclosed: https://crt.sh/mozilla-disclosures#disclosureincomplete

The two CAs contain non-critical name constraints extensions in violation of RFC 5280:
https://crt.sh/?id=278954844&opt=zlint
https://crt.sh/?id=21654893&opt=zlint

For the problem listed above, please provide an incident report as described here:

https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 1

[Rob Stradling]

Wayne,

The Mozilla Root Store Policy does not mention RFC5280.  It does however require CAs to conform to the Baseline Requirements, which incorporate RFC5280 but permit some exceptions.  This is one such exception...

BR 7.1.2.2(f) says:
> f. nameConstraints (optional)
> If present, this extension SHOULD be marked critical*.
> * Non-critical Name Constraints are an exception to RFC 5280 (4.2.1.10), however, they MAY be used until the
> Name Constraints extension is supported by Application Software Suppliers whose software is used by a
> substantial portion of Relying Parties worldwide.

ZLint is flagging both the RFC5280 rule (ERROR) and the BR rule (WARNING).

Comment 2

[Wayne Thayer]

(In reply to Rob Stradling from comment #1)
> Wayne,
> 
> The Mozilla Root Store Policy does not mention RFC5280.  It does however
> require CAs to conform to the Baseline Requirements, which incorporate
> RFC5280 but permit some exceptions.  This is one such exception...
> 
> BR 7.1.2.2(f) says:
> > f. nameConstraints (optional)
> > If present, this extension SHOULD be marked critical*.
> > * Non-critical Name Constraints are an exception to RFC 5280 (4.2.1.10), however, they MAY be used until the
> > Name Constraints extension is supported by Application Software Suppliers whose software is used by a
> > substantial portion of Relying Parties worldwide.
> 
> ZLint is flagging both the RFC5280 rule (ERROR) and the BR rule (WARNING).

Ah, thank you Rob. If this is the case, then why is the crt.sh report flagging these intermediates as requiring disclosure?

Comment 3

[Rob Stradling]

To be considered Technically Constrained, Mozilla Root Store Policy 5.3.1 says:
"If the certificate includes the id-kp-serverAuth extended key usage, then the certificate MUST be Name Constrained as described in section 7.1.5 of version 1.3 or later of the Baseline Requirements."

BR 7.1.5 says:
"For a Subordinate CA Certificate to be considered Technically Constrained, the certificate MUST include an
Extended Key Usage (EKU) extension specifying all extended key usages that the Subordinate CA Certificate is
authorized to issue certificates for. The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this
extension.
If the Subordinate CA Certificate includes the id-kp-serverAuth extended key usage, then the Subordinate CA
Certificate MUST include the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress
and DirectoryName as follows:-
(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the Applicant has registered
the dNSName or has been authorized by the domain registrant to act on the registrant's behalf in line
with the verification practices of section 3.2.2.4.
(b) For each iPAddress range in permittedSubtrees, the CA MUST confirm that the Applicant has been
assigned the iPAddress range or has been authorized by the assigner to act on the assignee's behalf.
(c) For each DirectoryName in permittedSubtrees the CA MUST confirm the Applicants and/or
Subsidiary’s Organizational name and location such that end entity certificates issued from the
subordinate CA Certificate will be in compliancy with section 7.1.2.4 and 7.1.2.5."

Neither of these 2 intermediates meet the "MUST...and DirectoryName...(c)..." requirement, and so they are not considered to be Technically Constrained per the Policy.  Therefore, they need to be Publicly Disclosed and Audited.

Comment 4

[Wayne Thayer]

The amended bug is:

Two Keynectis subordinate CAs have not been properly disclosed: https://crt.sh/mozilla-disclosures#disclosureincomplete

The following two CAs appear to be intended to be technically constrained and are marked as such in CCADB, however they are missing DirectoryName constraints as required by BR 7.1.5:
https://crt.sh/?id=278954844&opt=zlint
https://crt.sh/?id=21654893&opt=zlint

For the problem listed above, please provide an incident report as described here:

https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 5

[Erwann Abalea]

Here's the incident report.

"Orange LB Auth CA Class 2" and "Orange LB Auth CA G1" - Non technically constrained CAs, Incident Report

Date we were informed of the problem: 2017-11-22, by an email from Kathleen Wilson

Timeline:
 - 2015-11-04: creation of these 2 CAs, one under the Certplus Class 2 Primary CA hierarchy, the other under the OpenTrust Root CA G1 hierarchy, with EKU extension containing serverAuth, and NameConstraints extension containing a dnsName in the permittedSubtrees and the whole IPv4+IPv6 in the excludedSubtrees
 - 2016-06-xx: CCADB populated, these CAs being technically-constrained, we didn't inject them
 - 2017-11-22: start of email exchanges with Kathleen Wilson and Rob Stradling about the missing directoryName in the NameConstraints
 - 2017-12-15: insertion of the 2 CA certificates in CCADB, which displays them as technically-constrained
 - 2018-03-09: Bugzilla bug opened

At their issuance date, the CA certificates were technically-constrained for Mozilla (policy was version 2.2 at this moment) but not for the CABForum BR; the small difference between the two was missed, and it consists of the absence of a constraint on the directoryName form.
The purpose of these CAs is to issue TLS serverAuth certificates for customer-rented internet boxes. All these certificates have a single CN as their subject, ending with the ".livebox.orange.fr" domain, conforming to the NameConstraints extension. Two additional SAN:dnsName entries end with the same ".livebox.orange.fr" domain (for example: CN=Livebox4-LK15356DP990429-A01B29FD9E80.livebox.dns-orange.fr, SAN:dnsName=Livebox4-LK15356DP990429-A01B29FD9E80.livebox.dns-orange.fr, SAN:dnsName=rgw.A01B29FD9E80.livebox.dns-orange.fr, SAN:dnsName=A01B29FD9E80.livebox.dns-orange.fr).
In addition, OCSP responder certificates are issued, with a subject composed of "C=FR, O=Orange, OU=0002 380129866, CN=OCSP<incremental number>".
More than 3 million certificates have been issued under the "Orange LB Auth CA Class 2", expiring at most in July 2019.
Few test certificates have been issued under the "Orange LB Auth CA G1", and a set or corresponding OCSP responder certificates with the same naming.

It's not possible to recertify the CA and modify the NameConstraints extension to add a directoryName form, because the DV certificates have no other fixed attributes before the variable CN, and the directoryName form doesn't allow to express attributes ending with a suffix (as it's possible with the dnsName and rfc822Name forms).

We propose the following actions:
 - we'll request to disable the serverAuth flag on our "OpenTrust Root CA Gx" and "Certplus Root CA Gx" Root CAs
 - we'll revoke the existing Orange Auth LB CA G1 issuing CA

Comment 6

[Wayne Thayer]

(In reply to Erwann Abalea from comment #5)
> Here's the incident report.

Thank you.

> We propose the following actions:
>  - we'll request to disable the serverAuth flag on our "OpenTrust Root CA
> Gx" and "Certplus Root CA Gx" Root CAs

Distrusting 5 roots for serverAuth is a big change. Would this impact any certificates beyond the 3 million issued from the "Orange LB Auth CA Class 2" subCA certificate? Are those 3 million certs ever accessed via Firefox?

As an alternative, I would suggest just to add the "Orange LB Auth CA Class 2" subCA certificate to OneCRL.

>  - we'll revoke the existing Orange Auth LB CA G1 issuing CA

This sounds good.

Comment 7

[Erwann Abalea]

(In reply to Wayne Thayer [:wayne] from comment #6)
> (In reply to Erwann Abalea from comment #5)
> > Here's the incident report.
> 
> Thank you.
> 
> > We propose the following actions:
> >  - we'll request to disable the serverAuth flag on our "OpenTrust Root CA
> > Gx" and "Certplus Root CA Gx" Root CAs
> 
> Distrusting 5 roots for serverAuth is a big change. Would this impact any
> certificates beyond the 3 million issued from the "Orange LB Auth CA Class
> 2" subCA certificate? Are those 3 million certs ever accessed via Firefox?

It may impact a small technically-constrained CA only.
The 3+million issued under Orange LB Auth Class 2 shouldn't be impacted, and some of them may be accessed via Firefox (consumer ADSL triple-play boxes).

> As an alternative, I would suggest just to add the "Orange LB Auth CA Class
> 2" subCA certificate to OneCRL.

As end-users may use Firefox to configure their ADSL boxes, adding this CA to OneCRL will certainly break this functionality for them.

Comment 8

[Wayne Thayer]

(In reply to Erwann Abalea from comment #7)

> > Distrusting 5 roots for serverAuth is a big change. Would this impact any
> > certificates beyond the 3 million issued from the "Orange LB Auth CA Class
> > 2" subCA certificate? Are those 3 million certs ever accessed via Firefox?
> 
> It may impact a small technically-constrained CA only.
> The 3+million issued under Orange LB Auth Class 2 shouldn't be impacted, and
> some of them may be accessed via Firefox (consumer ADSL triple-play boxes).
> 
I see that the "Orange LB Auth Class 2 CA" does not chain up to any of the 5 roots for which you have suggested removing serverAuth in Mozilla products. How are these roots related to the issue described in this bug?

> > As an alternative, I would suggest just to add the "Orange LB Auth CA Class
> > 2" subCA certificate to OneCRL.
> 
> As end-users may use Firefox to configure their ADSL boxes, adding this CA
> to OneCRL will certainly break this functionality for them.

You are suggesting that we do nothing about the "Orange LB Auth CA Class 2" other than wait for all the certificates issued under it to expire in July 2019, is that correct? Since this CA certificate does not meet the definition of technically constrained, is it possible to have it audited to meet Mozilla policy section 5.3.2?

Comment 9

[Erwann Abalea]

(In reply to Wayne Thayer [:wayne] from comment #8)
> (In reply to Erwann Abalea from comment #7)

> > As end-users may use Firefox to configure their ADSL boxes, adding this CA
> > to OneCRL will certainly break this functionality for them.
> 
> You are suggesting that we do nothing about the "Orange LB Auth CA Class 2"
> other than wait for all the certificates issued under it to expire in July
> 2019, is that correct? Since this CA certificate does not meet the
> definition of technically constrained, is it possible to have it audited to
> meet Mozilla policy section 5.3.2?

Orange is going to pass an audit for this CA. They are negotiating an audit date with a Qualified Auditor, it will be run within the next weeks.
I'll update the bug once we know the dates.

Comment 10

[Wayne Thayer]

I see that the Orange LB Auth Class 2 CA is now listed on the audit for the Class 2 Primary CA. Subject to the same audit period violation as the root (described in a bug 1465629), this issue is now resolved.