1586860 - Camerfirma: Invalid authorityKeyIdentifier, violating Mozilla Policy and RFC 5280

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Ryan Sleevi]

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

Comment 1

[Juan Angel Martin]

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.

Comment 2

[Juan Angel Martin]

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.

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

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

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

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

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

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

Comment 3

[Juan Angel Martin]

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.

Comment 4

[Juan Angel Martin]

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

Comment 5

[Juan Angel Martin]

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.

Comment 6

[Wayne Thayer]

It appears to me that this is not a clear 5280 violation and thus the situation does not clearly require revocation.

Ryan: any further comments here?

Comment 7

[Ryan Sleevi]

Wayne: Comment #0 establishes it's been a Mozilla Requirement since version 1.0, and that was the interpretation applied. The MAY being referenced applies to using either A or B (you MAY use either).

The question of whether a MAY coupled with a normative statement implies a MUST NOT other than the MAY is similar to the discussion about EC usages, but I hope we're in agreement with the assessment in CComment #0 about being a past-and-present policy violation.

This is also one of the areas where ITU-T has diverged, in that X.509v3/2016 is clearer you can use (A, B, A AND B). This is similar as several other divergences from the IETF that leads to incompatibilities, such as restrictions on certain subject field lengths, and I suspect may have contributed to why this issue was not detected until now, as ETSI appears to give priority to ITU-T over IETF.

Comment 8

[Wayne Thayer]

With respect to revocation: this is clearly a violation of Mozilla policy but not clearly an RFC 5280, and hence a BR violation.

Mozilla policy was just updated to clarify our expectations for revocation, both for TLS (section 6.1) and S/MIME (section 6.2) certificates. Camerfirma has failed to meet these revocation requirements.

Juan: please submit a new incident bug for the failure to meet Mozilla's revocation requirements as described at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

CAs should submit a separate incident report when:

• Mozilla policy requires that the CA revoke one or more certificates by a certain deadline, such as those in BR section 4.9, but that deadline is not met by the CA.

Comment 9

[Ramiro Muñoz Muñoz]

Hi Wayne,

I’d like to ask you a question about the last comment that you included in the bug 1586860 (Comment 8).

As we told you in the past, all the SSL and S/MIME certificates issued by Camerfirma since Oct 29th and Nov 18th 2019 respectively include an Authority Key Identifier based in the key identifier, so we can assure that we have not issued any more certificates with that problem since the new version of Mozilla Policy entered into effect on Jan 1st, 2020.

Due to the fact that, according to your Comment 6, the problem was not clearly a violation of the RFC 5280 or a BR violation and the new Mozilla Policy that requires a revocation took into effect when we had already solve the problem and we did not issue certificates with the problem any more, we think that maybe it is not necessary to open a new bug either revoke the certificates issued before that date.

Could you help us clarify it, since we are talking about a big impact for our users?

Thank you so much for your help.

Comment 10

[Wayne Thayer]

Ramiro: I agree that Mozilla policy may not technically require revocation of any of these certificates because they were issued prior to the 2.7 version of our policy which now requires their revocation, and we normally require compliance with the policy at the time of issuance. On the other hand, we have clearly in the past required revocations for certs that did meet our policy at the time of issuance (e.g. SHA-1 deadlines), so I do not believe that it is entirely clear that our policy does not require revocation either.

Rather than deciding what the policy does and does not require, what I am interested in is creating a separate record that shows what happened with these certificates. I understand that you do not plan to revoke any of them, so I would like to create a separate bug indicating that these certificates will not be revoked, along with the explanation of why not. Does that make sense to you? If so, I will go ahead and create that bug. It would be great for Camerfirma to take one further step and explain how you will improve your capacity to revoke certificates should a similar situation happen in the future, when revocation will be clearly required.

Comment 11

[Ramiro Muñoz Muñoz]

Thank you Wayne

We will create separated bug as you suggested. The revocation of great quantity of certificates is part of our contingency plan. We will describe this procedure in the separated bug

Thanks again for your support.
KR
Ramiro

Comment 12

[Ryan Sleevi]

Wayne created Bug 1609828 for this

Comment 13

[Juan Angel Martin]

This bug derived in the creation of this other one [1].

Since the second bug was resolved, is there any reason to keep this first bug open?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1609828

Comment 14

[Wayne Thayer]

(In reply to Juan Angel Martin from comment #13)

Since the second bug was resolved, is there any reason to keep this first bug open?

No - I believe that this incident has been remediated and all questions have been answered, so this bug can be resolved.

Comment 15

[Michel Le Bihan]

Hello,

I found these two certificates issued yesterday that seem to be affected by the same issue:
https://crt.sh/?id=2561222936&opt=zlint
https://crt.sh/?id=2560522503&opt=zlint

Comment 16

[Juan Angel Martin]

Hello MIchel,

Both are pre-certificates.

I'm looking for the certificates now.

Thank you very much
Juan Angel

Comment 17

[Juan Angel Martin]

We've got the certificates and we've revoked them.

We're investigating this issue.

We'll update tomorrow.

Comment 18

[Juan Angel Martin]

Our system uses a configuration file of the certificate for each profile that we issue. Due to the fact that we have a very big number of profiles, we have been addapting the configurations as we needed them.

The profiles associated to the new affected certificates had not been changed, thus they were issued with an incorrect profile (under investigation).

We have also to take into account that the versión of Zlint configured in our platform for the preissuance control did not detect the problem and we had not discovered 2.0.0 version that includes the 'e_mp_authority_key_identifier_correct' detection until now.

We will open a new bug to explain the problems in more depth and detect other possible affected certificates within the next days.

Comment 19

[Wayne Thayer]

Juan: please submit a new incident report in a new bug describing the recurrence of this problem. Mozilla's incident reporting guidance requires this:

CAs should submit a separate incident report when:

Mozilla policy requires that the CA revoke one or more certificates by a certain deadline, such as those in BR section 4.9, but that deadline is not met by the CA.
In the process of researching one incident, another incident with a distinct root cause and/or remediation is discovered.
After an incident bug is marked resolved, the incident reoccurs.

Comment 20

[Juan Angel Martin]

Incident report: https://bugzilla.mozilla.org/show_bug.cgi?id=1623384