1609828 - Camerfirma: Decision not to revoke certificates with authorityKeyIdentifier that violates Mozilla Policy

Status: RESOLVED FIXED

(NSS :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

In bug 1586860, it was determined that every SSL and S/MIME certificates issued by Camerfirma prior to Oct 29th and Nov 18th 2019 respectively contain an authorityKeyIdentifier that violates Mozilla policy section 5.2. They may also violate RFC 5280 but that is not clear (see bug 1586860 for specifics). These were issued prior to version 2.7 of the Mozilla policy, which was updated to require revocation of certificates that violate Mozilla policy. This bug is intended to record the fact that these certificates were not revoked.

Juan: since this isn't strictly a policy violation, no incident report is required. I would, however, like to give Camerfirma the opportunity to explain what, if anything, is being done to ensure that revocation can be carried out if a similar problem were to occur under the new version of Mozilla's policy?

Comment 1

[Ana Lopes]

Hi Wayne:

AC Camerfirma has developed a revocation plan to give response to the CA/B Forum and Root Programs policies’ requirements.
These requirements establish that after the detection of a problem related to the issue of any certificate, the CA has a period of 24 hours or 5 days depending on the case to the effective revocation.

We have divided the process on the following steps:

1- Location of the affected certificates
2- Communication to the affected clients and subscribers
3- Effective revocation

Camerfirma counts with a tool which let us revoke the affected certificates through their serial number, effective revocation date and the reason to revoke.

This tool feeds the CRL generation process and OCSP service and is available for all kind of certificates (SSL, S/MIME, Codesign, Timestamping, ...).

This application is in upgrading phase and we will incorporate a link to the information about the incident, the certificate substitution process and the communication template.

The application would send that information to the clients and manage the revocation deadlines established automatically and revoke the active affected certificates.

This plan develops the technical processes of the revocation, but we have to take into account the high impact that can be generated in the client systems if the certificates cannot be substituted before the revocation.

We carry out two main actions to control this part:

1. Client certificate distribution process awareness. The clients can be implicated in a revocation process which is not negotiable with 24 hour or 5 day-deadlines, which requires the establishment of substitution mechanisms to allow them to make the change within the time.
2. Development of specific utilities to let the substitution certificate issued from the part of the client in a quick and transparent way.

The described plan applies to all our CAs internally managed .

For the delegated CAs, we apply the process described in the Bug 1556806.

Comment 2

[Wayne Thayer]

It appears that all questions have been answered and remediation is complete.