1495507 - FNMT: OU exceeds 64 characters

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

FNMT has misissued a number of certificates with an OU field that exceeds the mximum length of 64 characters:

https://crt.sh/?cablint=539&iCAID=1488&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01

Please provide an incident report for this problem, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
The incident report should be posted to the mozilla.dev.security.policy forum and added to this bug.

Comment 1

[Rafa Medina]

Hello Wayne, I´ll try to answer the questions of incident report.

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.
On 01/10/2018 20:30 (CEST) a message from Wayne Thayer was received at incidents report email account ([e-mail])

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.

On 02/10/2018 an analysis of the subject was started. It was confirmed that there were some certificates with an ou field that exceeds the length of 64 bytes.
Investigation efforts were continued to deepen on this subject. We have discovered another affected certificates by this issue. All of them are certificates of Spanish Public Bodies whose official (organization/organizational unit) names exceeds the length of 64 bytes.
On 03/10/2018 13:00 (CEST) the Management Committee of TSP met. The Committee examined the available information and decided:
- To replace affected certificates
- To develop automatic validations to ensure such issuance will not be repeated in the future.
- To include this rule in automatic and periodic controls over issued certificates

On 04/10/2018 we have started to contact with affected entities in order to coordinate certificate substitution

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.

We have stopped issuing certificates with this problem.

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.
Issue o/ou > 64 characters:
- Number of certs: 103 affected certificates (2 sub CAS)
- Date of first certificate: December 2014
- Date of last certificate: 27/09/2018
All of them are certificates of Spanish Public Bodies whose official (organization/organizational unit) names exceeds the length of 64 characters.

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.

****Pending of update to show all certificates. It must be taken into account that “older” certificates are not logged to CT
https://crt.sh/?cablint=539&iCAID=1488&opt=cablint,zlint,x509lint&minNotBefore=2014-01-01

https://crt.sh/?cablint=539&iCAID=401&opt=cablint,zlint,x509lint&minNotBefore=2014-01-01

6.	Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Length of o/ou fields were not controlled till now.
Because of an unfortunate misunderstanding in comprehension and interpretation of information of rfcs 5280/6818, X.500/520, some public mail threads (CABForum, ietf, etc) and practices of another CAS, we believed that this was a “de facto” authorized practice by the community. Therefore, we did not develop any automatic validation.

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.

- Contact with involved entities has started. We are working with each of them to replace every affected certificate by a new one.
- We are developing an automated validation control (software) to ensure it will not be repeated. In the meanwhile, registration officers have been ordered to perform a manual check before the approval of the issuing of the certificate.
- In addition, we will include a new rule in automatic and periodic controls over issued certificates to ensure that new measures are working (maybe based on certlint/cablint utils)


We will update the information of this incident periodically

Comment 2

[Wayne Thayer]

Thank you for the incident report, and the intent to provide more information periodically. I will expect updates on:
- the full list of misissued certificates, preferably by adding them to CT logs
- confirmation that they have all been revoked
- implementation of the automated validation control
- implementation of linting to ensure that the new measures are working

Does "new rule in automatic and periodic controls over issued certificates" mean that you will use linting utils to verify certificates prior to issuance, or after issuance?

Comment 3

[Rafa Medina]

(In reply to Wayne Thayer [:wayne] from comment #2)
> Thank you for the incident report, and the intent to provide more
> information periodically. I will expect updates on:
> - the full list of misissued certificates, preferably by adding them to CT
> logs
> - confirmation that they have all been revoked
> - implementation of the automated validation control
> - implementation of linting to ensure that the new measures are working

We keep working on this subjects.

The automated validation control will be ready by the end of the week.


> Does "new rule in automatic and periodic controls over issued certificates"
> mean that you will use linting utils to verify certificates prior to
> issuance, or after issuance?

Currently, we are developing an automatic control over issued certificates, that is to say, we will verify certificates after issuance. We estimate it will be ready next week.

Obviously, it would be better to make linting before issuing (before CT Login). We are discussing about it with our PKI software provider.

Regards,

Comment 4

[Rafa Medina]

We update information.

> We keep working on this subjects.
Misissued certs have been already added to CT logs

> The automated validation control will be ready by the end of the week.
Automated validation control was enabled on 26th October. Incoming requests with o/ou > 64 characters are not allowed.

> Currently, we are developing an automatic control over issued certificates,
> that is to say, we will verify certificates after issuance. We estimate it
> will be ready next week.
Daily linting performed since 29th October

Comment 5

[Wayne Thayer]

Thank you for the update. Has a decision been made on pre-issuance linting?

Comment 6

[Rafa Medina]

(In reply to Wayne Thayer [:wayne] from comment #5)
> Thank you for the update. Has a decision been made on pre-issuance linting?

We are activating a embedded component from our PKI software provider. It will be enabled by end of this week. Thus, pre-issueance validations are performed:

- Subject and SubjectAltNames are rfc5280 compliant (checking of o and ou fields are included in next version of this component -available by end of november-)
- Subject and SubjectAltNames are CAB Forum BRs compliant.
- TLD register at IANA root zone database
- Weak keys
- ...

Nevertheless, we would like to make additional pre-issuance linting with the "official" cablint software. We will discuss this with our PKI software provider.

Comment 7

[Wayne Thayer]

Rafa: please provide an update on your plans for additional pre-issuance linting.

Comment 8

[Rafa Medina]

Hello Wayne.

We are testing in our QA environment a new version of PKI Software that implements pre-issuance validations. Validation rules are based, among others, on the tools used by crt.sh (certlint, x509lint, zlint). If everything goes as expected, we will upgrade our production environment by end of January.

Comment 9

[Rafa Medina]

Yesterday we upgraded our production environment with the new version of PKI software validation component.

Comment 10

[Wayne Thayer]

It appears that all remediation is complete.