1391095 - Add AC FNMT Usuarios certificate to OneCRL

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Kathleen Wilson]

Please add the following intermediate certificate to OneCRL.

https://crt.sh/?id=8989111
Certificate Issuer Organization: FNMT-RCM
Certificate Issuer Organizational Unit: AC RAIZ FNMT-RCM
Certificate Serial Number: 455f3ae15c21cdba544f82aa4751ebdb
SHA-256 Fingerprint:
60:12:93:CA:20:B0:9A:03:29:5D:19:62:56:C6:95:3F:F9:EB:A8:11:DB:8E:3C:E1:40:41:3C:1B:FF:E9:A8:69

Background:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Qo1ZNwlYKnY/UrAodnoQBwAJ

Comment 1

[José Manuel Torres]

Attachment: Audit_Attestation_FNMT_2017.pdf

Comment 2

[José Manuel Torres]

Hi all, 

In response to the questions raised in m.d.s.p https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/Qo1ZNwlYKnY/UrAodnoQBwAJ ,

AC FNMT Usuarios do not issue TLS / SSL certificates, as evidenced by the 
attached document: Audit Attestation - ETSI Assestment 2017, FNMT CA's and 
TSU's. 

Regarding anyExtendedKeyUsage EKU, since January 2017 it is no longer 
incorporated into the certificates issued by AC FNMT Usuarios so it should 
not be possible to use it for TLS server authentication. 

In this sense the certificate indicated in the incident related in m.d.s.p was issued prior 
to the change indicated. 

Taking these considerations into account, FNMT considers that a revocation 
of the intermediate CA by OneCRL is not necessary. 

Regards

Comment 3

[Kathleen Wilson]

(In reply to jmtcarballo from comment #2)
> Taking these considerations into account, FNMT considers that a revocation 
> of the intermediate CA by OneCRL is not necessary. 


Please explain why you think we should not add this intermediate certificate to OneCRL. What impact do you think it will have on your PKI/customers?

OneCRL is only used by Firefox, so is only used when doing path validation for TLS/SSL certificates. Therefore, if this certificate does not sign certs for TLS/SSL usage, then adding this certificate to OneCRL will have *zero* impact on your PKI.

Comment 4

[Víctor]

I may suggest, although there has not being any known incident until this time, to include in this request the "AC Representacion" subCA.

If I remember it well, both "AC FNMT Usuarios" and "AC Representacion" were two subCAs that weren't intended to sign any SSL/TLS but weren't restricted by EKU extension. Although I don't see "AC Representacion" in the summary of the inclusion here: https://bugzilla.mozilla.org/show_bug.cgi?id=435736#c166 I see, in the audits, statements that the audit covers both. 

As far that the email trust bit is not active, I don't see any inconvenience that both subCAs could be revoked on OneCRL. No user impact is expected. 

Ok, no NEW certificates are issued with these subCAs that could be used as TLS/SSL certificates that chain up to a root in NSS. BUT what do we do with all certs ALREADY issued that are TLS/SSL enabled by that EKU and are active? I know that many of them still have many years until they expire. And, because of the number of certificates issued, I don't think that revoking the affected certs would be viable. 

I think that if these subCAs are added to OneCRL, FNMT-Ceres could be freed of the obligation of auditing the non-presence of TLS/SSL certs issued by these subCAs. 

Kind regards

Comment 5

[Víctor]

For better reference, the subCA cert I was referring is: 

https://crt.sh/?id=12729173
Certificate Issuer Organization: FNMT-RCM 
Certificate Issuer Organizational Unit: AC RAIZ FNMT-RCM 
Certificate Serial Number:
            61:c2:d4:d4:f6:a9:ae:77:55:92:66:b9:8d:af:d6:21
SHA-256 Fingerprint: 8FD16A179944D5D1D420AF09405EDA7ABF2A9C742883E8C2F89E0D90AFAF754B


------ 

Not sure how to verify that a subCA cert is, or is not, restricted from issuing SSL/TLS certificates.

As X509v3 Basic Constraints and X509v3 Key Usage doesn't mention anything about that, just that that is a CA that can sign certs (without specifying) and the CRL, can we confirm that? (Still learning 

Comment 6

[Kathleen Wilson]

Víctor, those are good points. I will need to file another Bugzilla Bug for that cert, since our current batch of changes to OneCRL is already in progress.

Before I create that bug, José, are there any other intermediate certs like this that chain up to the "FNMT-RCM-SHA256" root that are not technically constrained (via EKU and Name Constraints) to prevent issuance of SSL certs that will not be audited according to the Baseline Requirements?

Comment 7

[José Manuel Torres]

Hi,
 
Victor, you are right when you indicate that the "AC FNMT Usuarios" and "AC Representation" subCAs are not technically constrained for issuing TLS / SSL certificates. Internal controls are performed to avoid such issuance.

Katheleen, FNMT's concern to revoke the "AC FNMT Usuarios" subCA via OneCRL comes from the lack of in-depth knowledge of OneCRL mechanism. We thought it might have some impact on the end users of the certificates issued by this subCA in the client authentication process with Firefox. If it is confirmed that there will be no problems in this sense, FNMT has no objection to include "AC FNMT Usuarios"  subCA in OneCRL.
But FNMT need to be completely sure on that point. Could you confirm that?

Finally, there is no other subCA other than those mentioned ("AC FNMT Usuarios", "AC Representation") not technically constrained  and not audited  according to BRs.


Regards

Comment 8

[Víctor]

Hi,

The certs issued under "AC FNMT Usuarios" before Jan 2017 (as FNMT's representative has stated, I can verify that ones issued in 2016 had the anyExtendedKeyUsage EKU and others issued recently, not) are not (APPARENT) SSL/TLS certificates.

They are certificates that a) encrypt the email (email trust bit was not requested while the root was being accepted to be in the NSS??), b) act as SSL/TLS client validation on a website and c) *whatever*, as the anyExtendedKeyUsage EKU is in it.

So, 1. the root is considered safe in the store with SSL/TLS trust bit, 2. the subCA is not revoked and has proper rights to issue a certificate of any type, and 3. the cert states that can do anything.

The certs issued under "AC FNMT Usuarios" before Jan 2017 are IN FACT SSL/TLS certificates. Although they would generate an error while trying to retrieve the alleged DNS of the server from the cert, the error can be ignored by the user. It would make a similar error message to a certificate that chains up to "AC Componentes Informáticos" (subCA certificate with a SHA-1 signature) that is still active and is currently issuing certificates.

So, in the difference of APPARENT and IN FACT is the main error: FNMT and the auditors have stated during the last years that FNMT has not issued apparent SSL/TLS under "AC FNMT Usuarios" although in fact, it has.

Issuing SSL/TLS certs by a subCA that is not audited as a subCA that issues SSL/TLS certs and issuing SSL/TLS certs without complying with the standards is a reason why a cert issuer may be put apart of the Mozilla CA Program. So, as I don't thing that such a decision is made, lets try to find a way to fix the issue that doesn't impact neither the Spaniards neither FNMT bussiness.

So, returning to the main issue:

TO BE DONE INMEDIATELY:
- All certs issued under "AC FNMT Usuarios" before Jan 2017 must stop working as SSL/TLS certs.

Let's give some BACKGROUND:

Well, FNMT has issued about 5,9M certificates according to its website (https://cert.fnmt.es). Although it's not divided by the type of cert or under what subCA is issued, we can be sure that we are talking about a huge amount of certificates. As a Spaniard, I am sure that they are very important, as the certs issued under this subCA and under "AC Representacion" have many legal effects that affect from citizens to ANY legal entity (enterprises of any size, civil societies...).

The root cert was included in NSS with the web trust bit, NOT the email trust bit.

So a cert like this in Firefox it only may work as 1. A user certificate to log in to a website, 2. (if issued before Jan 2017)A server certificate (if issued after Jan 2017: CAN NOT be a server certificate)
In Thunderbird, 3. A user can send securely a email with this cert but 4. CAN NOT verify (without importing manually the public certificate of the other) that the recipient is who is supposed to be.

From last paragraph, 1. and 3. can be done as the cert is a user cert and it has to be imported manually.
4. cannot be done because of the lack of email trust bit.
The only thing that depends on the anyExtendedKeyUsage EKU, the NSS and OneCRL is 2.

As Firefox only accepts as valid certificates that chain up to a certificate in NSS EXCEPT the certificates that chain up to a certificate in OneCRL or the CA/subCA's CRL, the effect is that adding "AC FNMT Usuarios" would be as if it was excluded from NSS. NSS would be a whitelist and OneCRL a blacklist.

Adding the cert to OneCRL shouldn't affect the usage as a user certificate to log in to a website. For example, the DNIe certificates (DNI/DNIe are the national ID cards, they have a cryptographic chip that contains two pairs of personal certificates, they are issued by the national police) chain up to a certificate that is not inside NSS and work perfectly in Firefox. Despite that, tomorrow I will proceed to do the bureaucracy of getting a personal certificate from FNMT and I will try the preview release of Firefox to verify that. I suggest that you from FNMT do the same.

TO BE DONE IN THE FUTURE:
- Decide if the addition of "AC FNMT Usuarios" to OneCRL has to be permanent or it has to be removed when the last 'misissued' certificate expires.

- Decide if "AC Representacion" has to be added to OneCRL for prevention.

- Decide that, if "AC FNMT Usuarios" and "AC Representacion" are added to OneCRL, if it is necessary to continue to require to audit the non-existance of SSL/TLS certificates. 

- Take actions to get the required statements more complete in order to get more useful and clear audits. (Changing "this subCA doesn't issue SSL/TLS certificates" to "this subCA doesn't issue any certificate that logically and/or technologically can be used to identify a server..." or something similar) Are auditors aware of this event? 

- Are other vendors aware of this event? (Google and Microsoft appear to have a similar system to OneCRL)

===
(TL;DR: My opinion because "AC FNMT Usuarios" should be added to OneCRL and the potential user impact (null) it would have. User impact to be tested manually. Please, read "TO BE DONE IN THE FUTURE".)

Please, correct any wrong information I would have inserted.

Please, does anyone has any other idea to close the event that doesn't require to insert the subCA to OneCRL?

Also please, can anyone tell me how to find a build with the OneCRL updated? (seems that the process of adding has being finished as seen in Bug 1392378)

Best Regards

Comment 9

[Kathleen Wilson]

I confirm that the AC FNMT Usuarios certificate has been added to OneCRL.

I filed Bug #1393281 to add the AC Representación certificate to OneCRL.

Comment 10

[Kathleen Wilson]

(In reply to Víctor from comment #8)
> 
> TO BE DONE IN THE FUTURE:
> - Decide if the addition of "AC FNMT Usuarios" to OneCRL has to be permanent
> or it has to be removed when the last 'misissued' certificate expires.

Permanent. It can be removed after it expires.

> 
> - Decide if "AC Representacion" has to be added to OneCRL for prevention.

Will add to OneCRL via Bug #1393281.


> 
> - Decide that, if "AC FNMT Usuarios" and "AC Representacion" are added to
> OneCRL, if it is necessary to continue to require to audit the non-existance
> of SSL/TLS certificates. 

After these certs are added to OneCRL, Mozilla does not need these audit statements.
So, no, it will not be necessary to continue getting the annual audit for the non-existence of SSL/TLS certs.


> 
> - Take actions to get the required statements more complete in order to get
> more useful and clear audits. (Changing "this subCA doesn't issue SSL/TLS
> certificates" to "this subCA doesn't issue any certificate that logically
> and/or technologically can be used to identify a server..." or something
> similar) Are auditors aware of this event? 

It is the CA's responsibility to work with their auditors on this.

> 
> - Are other vendors aware of this event? (Google and Microsoft appear to
> have a similar system to OneCRL)

They know that they have some catching up to do.
https://crt.sh/revoked-intermediates

It may take them a while, because Mozilla's OneCRL is only used during path validation of TLS/SSL certificates. But I think the other root stores' equivalent might also be used for other types of certificates.


> Also please, can anyone tell me how to find a build with the OneCRL updated?
> (seems that the process of adding has being finished as seen in Bug 1392378)

OneCRL gets pushed out to Firefox users automatically. Changes to OneCRL typically show up on my system within 24 hours of the changes getting pushed to production -- see https://bugzilla.mozilla.org/show_bug.cgi?id=1392378#c7.

Thanks!