Closed Bug 1650018 Opened 5 years ago Closed 5 years ago

GlobalSign: Cross Certificate with non-conforming CABF Policy OIDs

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: arvid.vermote, Assigned: arvid.vermote)

Details

(Whiteboard: [ca-compliance] [ca-misissuance])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

GlobalSign has a contract with Google to create a cross certificate from GlobalSign Root R1 to the Google GTS Root R1. Google will use the GTS Root R1 to issue BR compliant OV and DV leaf certificates as well as Client Auth/Secure Mail and Document Signing certificates which are not currently covered by CABF requirements.

In trying to populate the Certificate Policies extension for this cross certificate of a non-affiliated organization, we've discovered three issues to accomplish this in a BR compliant manner.

Since the cross certificate was issued and does not comply with BR section 7.1.6.1, we are raising this as an incident in all transparency. This certificate was issued on June 17, 2020.

Upon investigation of issued Subordinate CAs, we noted that 4 other CA certificates include policy identifier 2.23.140.1.2.1 and organizationName in the Subject.

Summary

  1. The combination of including the DV OID and OV OID leads to incompatible requirements.

    If the Certificate asserts the policy identifier of 2.23.140.1.2.1, then it MUST NOT include organizationName, givenName, surname, streetAddress, localityName, stateOrProvinceName, or postalCode in the Subject field.

    If the Certificate asserts the policy identifier of 2.23.140.1.2.2, then it MUST also include organizationName, localityName (to the extent such field is required under Section 7.1.4.2.2), stateOrProvinceName (to the extent such field is required under Section 7.1.4.2.2), and countryName in the Subject field.

  2. Including the DV OID prohibits including organizationName, givenName, surname, streetAddress, localityName, stateOrProvinceName, or postalCode. Since the subject is the organization Google, it is anticipated to include organization related fields in the subject field.

  3. Policy identifiers of the Subject CA (Google) must be included for certificate validation purposes, but the provision in the BRs doesn't specify if the CA identifiers must be defined by the subject CA (Google) or the issuing CA (GlobalSign).

In light of the below inconsistencies between the RFC and the BR, we believe that the correct interpretation of Section 7.1.6.1 BR deviates from its natural meaning and that the use of both policy identifiers (OV and DV) must be permitted in the present case.

Additionally, we found certificates of other CAs:

Relevant sections and rationale

#1: BR section 7.1.6.1 Certificate Policy Object Identifier

This section describes the content requirements for the Root CA, Subordinate CA, and Subscriber Certificates, as they relate to the identification of Certificate Policy.

If the Certificate asserts the policy identifier of 2.23.140.1.2.1, then it MUST NOT include organizationName, givenName, surname, streetAddress, localityName, stateOrProvinceName, or postalCode in the Subject field.

If the Certificate asserts the policy identifier of 2.23.140.1.2.2, then it MUST also include organizationName, localityName (to the extent such field is required under Section 7.1.4.2.2), stateOrProvinceName (to the extent such field is required under Section 7.1.4.2.2), and countryName in the Subject field.

Issues:

  • This appears to mean that a certificate may not contain both DV and OV Policy OIDs. This makes sense for Subscriber certificates, but not for Subordinate CAs, Roots or Cross Certificates.
  • We believe that this exclusion was intended only for Subscriber certificates (Referenced section 7.1.4.2.2 is also a Subscriber Certificate section) and that this should not be applicable to CA certificates. See discussion here: https://github.com/cabforum/documents/issues/179.

#2: BR Section 7.1.6.3 "Subordinate CA Certificates" says:

A Certificate issued to a Subordinate CA that is not an Affiliate of the Issuing CA:

  1. MUST include one or more explicit policy identifiers that indicates the Subordinate CA’s adherence to and compliance with these Requirements (i.e. either the CA/Browser Forum reserved identifiers or identifiers documented by the CA in its Certificate Policy and/or Certification Practice Statement) and
  2. MUST NOT contain the “anyPolicy” identifier (2.5.29.32.0).

Issues:

  • Since Cross certificates are not explicitly called out as their own type of certificate (vs, Root, Subordinate CA, Subscriber), we must apply Subordinate CA Certificate rules. These do however not permit the use of the anyPolicy identifier.
  • It's unclear which CA is referenced in "documented by the CA in its Certificate Policy". The provision could refer to either the issuing CA or the subject CA. Certificate profile related requirements are typically directed towards the issuing CA. However, since the Policy OIDs in this cross certificate need to map to those in all issued by the subject CA, the requirement has to relate to the subject CA for technical reasons.

#3 RFC 5280 4.2.1.4:

In an end entity certificate, these policy information terms indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used. In a CA certificate, these policy information terms limit the set of policies for certification paths that include this certificate. When a CA does not wish to limit the set of policies for certification paths that include this certificate, it MAY assert the special policy anyPolicy. Conclusion is that at least one Certificate Policy OID in the end entity certificate must be present in the entire chain, or the chain validation will fail.

Issues:

  • Since AnyPolicy is not allowed by (#2) for non-affiliated CAs, the set of Policy OIDs in this cross certificate needs to map to those in all issued by the subject CA.
  • The combination of DV and OV OID is prohibited by (#1).

#4 BR Section 7.1.4.3.1 "Subject Distinguished Name Fields" says:

Certificate Field: subject:organizationName (OID 2.5.4.10), Contents: This field MUST be present and the contents MUST contain either the Subject CA’s name or DBA as verified under Section 3.2.2.2.

Issues:

  • This requires subjectOrganizationName to be present and conflicts with (#1), which prohibits organizationName when asserting the policy identifier of 2.23.140.1.2.1.

A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

  • May 11, 2020: Discovered a potential issue with section 7.1.6.1 of combining DV and OV policy identifiers. Started investigation of alternative approaches for specifying policy identifiers.
  • May 20, 2020: Completed investigation and confirmed interpretation of certificate chain validation requirements. Decided that DV, OV and 2 Google specific policy identifiers are required for successful validation of leaf certificates.
  • June 4th, 2020: Reached out to Root programs to indicate intentions and explain (to our interpretation) discrepancies in BRs.
  • June 17th, 2020: Issuance of certificate.
  • June 30th, 2020: Analysis of impacted Subordinate CAs.

Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.

The certificates of this topic are issuing CA certificates and such certificates are only created and issued through human intervention and after review and approval. Certificate issuance has implicitly been stopped for certificates with this profile.

In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g. OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.

1 Cross certificate with DV and OV policy: https://crt.sh/?q=3EE0278DF71FA3C125C4CD487F01D774694E6FC57E0CD94C24EFD769133918E5

4 previously issued certificates between 2016 and 2019 with DV policy and organizationName in subject:

In a case involving certificates, the complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.

Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

The issue at hand was addressed and acted upon immediately and did not avoid detection.

List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.

We believe that the exclusion of section 7.1.6.1 was intended only for Subscriber certificates and that this should not be applicable to CA certificates. We facilitated this discussion here: https://github.com/cabforum/documents/issues/179.

Regarding section 7.1.6.1, we would like to propose to clarify the BRs on the statement of subject CA or issuing CA.

Assignee: bwilson → arvid.vermote
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance]
Type: defect → task

I believe that the focus of BR section 7.1.6.1 is on the inclusion of certificate policy OIDs in end entity certificates (to identify the applicable issuance process and map it to certificate contents) and that the correct interpretation of BR Section 7.1.6.1 allows the use of both policy identifiers (OV and DV) in the same subordinate CA. According to the RFC text quoted, “In a CA certificate, these policy information terms limit the set of policies for certification paths that include this certificate”. I interpret this to mean that the focus of including policy OIDs in CA certificates is not the same (the policy for issuance of the end entity certificate), but rather to limit the set of policies for certification paths under the root. Additionally, there are other problems with the current language (e.g. organizational identification of a DV-issuing CA, etc.), and efforts should be made with the CA/Browser Forum to clarify this provision as soon as possible.

There is currently a CABForum draft ballot named "Cleanups and Clarifications" that does include updates to the Baseline Requirements to clarify section 7.1.6.1 (https://github.com/cabforum/documents/commit/644daec12f732ca54c6d5da634d05677d1b08015). GlobalSign endorsed the draft ballot and will further support the process of these changes being applied to the Baseline Requirements.

I intend to close this matter on or about 14-Sept-2020 unless there are other issues to be raised.

Flags: needinfo?(bwilson)
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [ca-misissuance]
You need to log in before you can comment on or make changes to this bug.