Open Bug 1586860 Opened 2 months ago Updated 21 days ago

Camerfirma: Invalid authorityKeyIdentifier, violating Mozilla Policy and RFC 5280

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: ryan.sleevi, Assigned: martin_ja)

Details

(Whiteboard: [ca-compliance] - Next Update - 20-November 2019)

During an evaluation of improved linting tools, it was discovered that Camerfirma has, and continued to issues, certificates that violate the requirements of RFC 5280, as clarified by Mozilla Policy.

RFC 5280, Section 4.2.1.1, which defines the Authority Key Identifier, states (emphasis added):

The identification MAY be based on either the
key identifier (the subject key identifier in the issuer's
certificate) or the issuer name and serial number.

Mozilla PKI Policy, Version 2.6.1, includes language that has been present since Version 1.0, dated November 2005, specifically, that:

CAs MUST NOT issue certificates that have:
...

  • incorrect extensions (e.g., SSL certificates that exclude SSL usage, or authority key IDs that include both the key ID and the issuer’s issuer name and serial number); or

Camerfirma has violated this approximately 3233 times among its CAs. An example certificate, issued 2019-09-24, is https://crt.sh/?q=7c7f372837764fe6ddd5a6943430f399cc49125df592247b8e42a8dede9bc3ec

This certificate contains both a keyid and a DirName+serial tuple, in violation of both RFC 5280 and Mozilla Policy.

Please file an incident report, as described at https://wiki.mozilla.org/CA/Responding_To_An_Incident

Flags: needinfo?(martin_ja)

First of all, we want to highlight that we detected our misinterpretation concerning the Authority Key Identifier and we sent an e-mail to Mozilla to clarify the situation as soon as we were conscious about the problem with the new version of zlint’s update.

RFC 5280, Section 4.2.1.1, which defines the Authority Key Identifier, states (emphasis added):

The identification MAY be based on either the
key identifier (the subject key identifier in the issuer's
certificate) or the issuer name and serial number.

That is why we understood that there was no problem with the BR, however, this is categorized in Mozilla Root Store Policy in point 5.2 as an incorrect extension, which makes that we do not comply with the Mozilla requirements.

​We have developed an action plan to solve this question which consists in including only the ‘keyidentifier’ in all the new certificates.

Further details will be provided in a detailed incident report no later than 2019-10-19 00:00 UTC.

Flags: needinfo?(martin_ja)
  1. 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.

We detected our misinterpretation concerning the Authority Key Identifier and we sent an e-mail to Mozilla on October 7th to clarify the situation as soon as we were conscious about the problem with the new version of zlint’s update.

  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.

We sent an e-mail to Mozilla on October 7th to clarify the situation and the bug was opened by Ryan Sleevi on October 7th and from then we have been developed our action plan.

  1. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

The CA has not decided to stop issuing certificates because it still considers that the extension does not violate RFC 5280 so as not to harm our
customers.

Every certificate issued under Camerfirma’s roots, intermediate certificates wich are disclosed in CCADB too, included into Mozilla Root Program since 2.003 has an Authority Key Identifier composed by the keyIdentifier + authorityCertIssuer + authorityCertSerialNumber.

Indicate that the work to resolve this issue will be completed next week and that in a new CA issued on 2019-10-17 and which will be made public shortly we have already included the only in the Authority Key Identifier the keyIdentifier.

  1. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

See #3

  1. 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.

See #3

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

We didn’t consider an Authority Key Identifier composed by the keyIdentifier + authorityCertIssuer + authorityCertSerialNumber as an incorrect extension cause it complies with the RFC 5280 and BRGs.

The section 4.2.1.1 of the About RFC 5280, which defines the Authority Key Identifier, states:

The identification MAY be based on either the key identifier (the subject key identifier in the issuer's certificate) or the issuer name and serial number.

We’ve obtained audits for our CAs under WebTrust or ETSI requirements since 2.003. Emphasize that we didn't understand that it was an incorrect extension.

We understood that there was no problem with BRGs. However, this is categorized in Mozilla Root Store Policy in point 5.2 as an incorrect extension, which makes that we do not comply with it.

  1. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

As we’ve indicated in #3, nowadays we have solved this issue for new intermediate certificates.

The same solution, only the keyidentifier into AKI, was accepted to be added to our final certificate issuance system on 2019-10-07 and started its development on 2019-10-08.

On 2019-10-25 the modification will be deployed if the results of the quality tests are satisfactory. From that moment all new certificates issued by AC Camerfirma will only include keyIdentifier

On 2019-10-25 the modification will be deployed if the results of the quality tests are satisfactory. From that moment all new certificates issued by AC Camerfirma will only include keyIdentifier

The internal quality test was finalized today. Website certificates' change will be in production no later than tuesday.

Some of our large institutional costumers ask for time to perform checks about S/MIME certificates. I'll update with a plan no later than tuesday.

We have already made the required modifications and all the website certificates are issued with AuthorityKeyIdentifier = keyId.

Every new S/MIME certificate will include it by November 20th

Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 20-November 2019

Every new S/MIME certificate issued by Camerfirma includes an Authority Key Identifier based in the key identifier (the subject key identifier in the issuer's certificate) since 2019-11-18 16:11 CET.

You need to log in before you can comment on or make changes to this bug.