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