Closed Bug 1686524 Opened 3 years ago Closed 3 years ago

Camerfirma: Certificate issued with 3-year lifespan, unknown policy

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: matthias, Assigned: eusebio.herrera)

Details

(Whiteboard: [ca-compliance] [uncategorized])

In the process of reviewing Bug 1623384, I found that the included certificate with sn 46f7344e81f9623307 (https://crt.sh/?id=2365268319), which is a now-revoked leaf pre-certificate, contains the "1.3.6.1.4.1.17326.10.11.3.1.2" oid as a policy identifier, and I cannot find this oid in the published CPS [0] for that root.

Additionally, due to the inclusion of the 'id-kp-clientAuth' extkeyUsage, I believe it is also in scope for BR validation, which it fails for various reasons, including having a 3-year lifespan.

I believe this certificate is in scope to the Mozilla Root Store, as it contains the 'id-kp-emailProtection' extended key usage identifier, and is signed by the "Camerfirma Corporate Server II - 2015" (https://crt.sh/?caid=1778).

Although I do aknowlegde that the certificate is already revoked, the revocation of this precert was 1.) likely due to Bug 1623384, and 2.) the problems of this specific certificate were not mentioned in any other issue, so I do believe this is still an incident that needs reporting.

[0] https://www.camerfirma.com/publico/DocumentosWeb/politicas/CPS_eidas_ES_1.2.12.pdf

Hi Matthias,

this is an Electronic Seal certificate (S/MIME), not an SSL certificate. Due to an error, we sent it to CT logs. That's the reason of appearance in crt.sh.

Kind regards.

(In reply to Eusebio Herrera from comment #1)

this is an Electronic Seal certificate (S/MIME), not an SSL certificate. Due to an error, we sent it to CT logs. That's the reason of appearance in crt.sh.

This is a joke, right? "By accident, we sent evidence of unreported, in-scope misissuance to CT logs"?

(In reply to Eusebio Herrera from comment #1)

Hi Matthias,

this is an Electronic Seal certificate (S/MIME), not an SSL certificate. Due to an error, we sent it to CT logs. That's the reason of appearance in crt.sh.

If my knowledge of the definition of "id-kp-clientAuth" in RFC5280, and the BR section 7.1.2.3 (f) is accurate, this is a (client) SSL certificate. And according to MRSP 2.3 (1): "Mozilla thus requires CA operations relating to issuance of all SSL certificates in the scope of this policy to conform to the Baseline Requirements."

As such, I believe that this certificate too is required to conform to the Baseline Requirements.

Additionally, the published CPS mentions in section 1.3.5.7.3 ("CHAMBERS OF COMMERCE hierarchy") a set of oids that it uses in its published certificates; but that does not include the aforementioned oid. Additionally, your CPS section 1.3.5.7.3.2.2 ("Digital Seal Certificate –LCP") explicitly states "It can also be used as a client machine identification element in secure TLS communication protocols", aknowledging that it is indeed an SSL Certificate.

Due to an error, we sent it to CT logs. That's the reason of appearance in crt.sh.

I fail to see how logging to a Certificate Transparency log is 'an error'.

You seem to suggest that certificates that are issued with this profile are 1.) not an exception, but 2.) are not being sent to CT logs, and 3.) you do not think the existence of this certificate is problematic (other than potentially for the issues documented in Bug 1623384).

I think that is a very dangerous suggestion, and especially 1. is problematic due to the lack of documentation and audits that attest to the usage of this policy identifier and the fact that the certificate was issued with a CA that is included in the Mozilla Root Store, and thus considered publicly trusted.

Please re-evaluate your statement.

Flags: needinfo?(eusebio.herrera)

If my knowledge of the definition of "id-kp-clientAuth" in RFC5280, and the BR section 7.1.2.3 (f) is accurate, this is a (client) SSL certificate. And according to MRSP 2.3 (1): "Mozilla thus requires CA operations relating to issuance of all SSL certificates in the scope of this policy to conform to the Baseline Requirements."
As such, I believe that this certificate too is required to conform to the Baseline Requirements.

Mozilla is mainly concerned about server certificates and email certificates. The scope of the Baseline Requirements does not include SSL client certificates.

Mozilla is mainly concerned about server certificates and email certificates

Understood.

The scope of the Baseline Requirements does not include SSL client certificates.

Thats different from what I understand from section 7.1.2.3 on Subscriber Certificates:

f. extKeyUsage (required)
Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or
both values MUST be present. id-kp-emailProtection [RFC5280] MAY be present.
Other values SHOULD NOT be present. The value anyExtendedKeyUsage MUST NOT be
present.

(emphasis added)

To me this implies that the BR's Subscriber Certificates include those issued with only extKeyUsage=id-kp-clientAuth. Other than this section explicitly including client certificates, I could not find documentation that the BR's scope for leaf certificates is limited to only certificates making use of the id-kp-serverAuth extKeyUsage.

(In reply to Matthias from comment #5)

To me this implies that the BR's Subscriber Certificates include those issued with only extKeyUsage=id-kp-clientAuth. Other than this section explicitly including client certificates, I could not find documentation that the BR's scope for leaf certificates is limited to only certificates making use of the id-kp-serverAuth extKeyUsage.

Good point. This is something that needs to be made more clear in Mozilla Policy and in the Baseline Requirements. I focus on the fourth paragraph of section 1.1 of the Baseline Requirements: "These Requirements only address Certificates intended to be used for authenticating servers accessible through the Internet."

"Mozilla is mainly concerned about server certificates and email certificates. The scope of the Baseline Requirements does not include SSL client certificates."

Ben,

I have always believed that, and it's definitely the intent, but I've tried in the past to document based on the BRs exactly what their scope is and why, but I'm not sure it can be done (if you have citations to the BRs that you believe make it clear, I'd love to see them). So, unfortunately, I believe the Baseline Requirements are at best unclear on their scope. The only argument I can really come up with is that the document is now maintained by the Server Certificate WG, and there is precedent for claiming that issues relating to non-serverauth use cases are out of scope for that Forum / Working Group [e.g. the pre-governance reform Code Signing BRs].

This is why it is very important that organizations that mandate compliance with the BRs be very explicit about which certificates are expected to comply. It has been very helpful that Mozilla has historically taken a pretty active role in clarifying some of the edge cases with respect to scope. I would encourage Mozilla to continue making clear statements like these about what their expectations are around the scope of the BRs, as it is very helpful.

That said, it probably would be helpful to improve the BRs to be more clear on their own scope. I realize there have been previous efforts to do so, but I think it's worth trying again. It would be good to get some of those issues clarified, especially now that we have three working groups at the CA/Browser Forum independently writing profiles and validation requirements that interact in potentially complex ways.

-Tim

Matthias: with respect to the language you emphasized, the language you noted about client-only certificates has been discussed by the validation subcommittee, and is considered a bug we will probably fix in the upcoming profile rewrite. It was not intended to, and in my opinion does not, opine upon or expand the intended scope of the Baseline Requirements.

Assignee: bwilson → eusebio.herrera
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance]

If there are no issues with this certificate as an SMIME certificate under Mozilla Policy, then shouldn't this bug be closed?

Thanks for the clarifications, I will change my expectations accordingly.

Other than the requirements for BR-certificates, the certificate still contains a policy identifier that I cannot find mentioned in their CPS and audit statements, which I would have expected based on the auditing requirements by Mozilla. Is that too a false expectation?

Tim!

I have always believed that, and it's definitely the intent, but I've tried in the past to document based on the BRs exactly what their scope is and why, but I'm not sure it can be done

Especially in the course of the discussion about the Delegated OCSP Responder Certificates I thought about this question a lot. This applicability question was the main reason, why the OCSP EKU Check PR had 125 comments and was closed without being merged directly. There are also (at a minimum) two open issues for zlint that are focusing on this topic: https://github.com/zmap/zlint/issues/517 & https://github.com/zmap/zlint/issues/475 . The outcome of all these discussions is -to my current understanding-, that it would be an oxymoron if the BRGs themselves define for which type of certificates they are applicable or not. Trying to define within the BRGs their scope would be ultimately a (self-coronation)[https://en.wikipedia.org/wiki/Self-proclaimed_monarchy]. Based on these discussions now I read the BRGs as a set of rules that have to be implemented if the BRGs are defined as being applicable by the owner of the root store (or in the CP / CPS of the CA operator or in a public regulatory requirement (e.g. the eidas-regulations in the EU for (Q)WACS)).

So regarding this bug the question is, if the Mozilla Root Store Policy (MRSP) is defining the BRGs as applicable for the certificate https://crt.sh/?id=2365268319 . Besides the (answer by Ben above)[https://bugzilla.mozilla.org/show_bug.cgi?id=1686524#c6], the MRSP include two paragraphs about this issue:

2.3 Baseline Requirements Conformance

CA operations relating to issuance of certificates capable of being used for
SSL-enabled servers MUST also conform to the latest version of the [CA/Browser
Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted
Certificates][BRs] ("Baseline Requirements").

and

3.1.2 Required Audits

3.1.2.1 WebTrust

If being audited to the WebTrust criteria, the following audit requirements
apply (see section 3.1.1 for specific version numbers):

  • For the SSL trust bit, a CA and all subordinate CAs technically capable
    of issuing server certificates must have all of the following audits:

    • [WebTrust for CAs][WebTrust-2.0]
    • [WebTrust for CAs - SSL Baseline with Network Security][WebTrust-BRs]
    • [WebTrust for CAs - EV SSL][WebTrust-EV] (if issuing EV certificates)

  • For the email trust bit, a CA and all subordinate CAs technically capable
    of issuing email certificates must have all of the following audits:

    • [WebTrust for CAs][WebTrust-2.0]
3.1.2.2 ETSI

If being audited to the ETSI criteria, the following audit requirements apply
(see section 3.1.1 for version numbers):

  • For the SSL trust bit, a CA and all subordinate CAs technically
    capable of issuing server certificates must have one of the
    following audits, with at least one of the noted policies or sets of
    policies:

    • [ETSI EN 319 411-1][ETSI-319-411-1] (LCP and (DVCP or OVCP)) and/or (NCP
      and EVCP)
    • [ETSI EN 319 411-2][ETSI-319-411-2] (QCP-w)

    An audit showing conformance with the EVCP policy is required if issuing EV
    certificates.

  • For the email trust bit, a CA and all subordinate CAs technically
    capable of issuing email certificates must have one of the
    following audits, with at least one of the noted policies:

    • [ETSI EN 319 411-1][ETSI-319-411-1] (LCP, NCP, or NCP+)
    • [ETSI EN 319 411-2][ETSI-319-411-2] (QCP-l, QCP-l-qscd, QCP-n, or
      QCP-n-qscd)

In my opinion, these two paragraphs leave no other interpretation as that for Mozilla the BRGs are only valid for TLS Server certificates.

Update: We are performing a manual review of all the OIDs to check if there is any other missing certificates in the CPS.
We will update the information in this bug when we finish the review and we will publish a new version for the CPS that contains the changes by the end of this month.

We continue with the review and the planification to have the CPS updated by the end of January.

Flags: needinfo?(eusebio.herrera)

We continue working to have the CPS updated by the end of this week as planned.

Update: You can find the new version of our CPS with the OIDs missing in the previous one in our repository: https://rest.camerfirma.com/publico/DocumentosWeb/politicas/CPS_eidas%20EN_1.2.13.pdf

Update: We have noticed an incorrect space in the link that we provided last Friday, the correct one is: https://rest.camerfirma.com/publico/DocumentosWeb/politicas/CPS_eidas_EN_1.2.13.pdf

We do not have more updates for this bug.

We do not have more updates for this bug.

Could you explain why you didn't catch this before?

The relevant root didn't have any non-TLS certificates documented, and this profile is so distinct that I'm very suprised that this wasn't found earlier.

Flags: needinfo?(martin_ja)

Effectively, this was an error that we had not detected.
It should be noted that the complete revision of the OIDs has been done, the missing OIDs are already included in the CPS and they'll be included in the next audit.

Flags: needinfo?(martin_ja)

So, do I understand correctly that you have not had, and/or do not have, a system in place that continuously verifies that

  • all certificates that are being issued are issued using the certificate profiles that are described in your CP/CPS?
  • each new certificate profile that is enabled for issuing is also first added to the CP/CPS before the first certificate is issued?
Flags: needinfo?(martin_ja)

There is not an automatic system to verify it. We have a department in charge of the verification, and, of course, we follow a process to include all new profile every time we enable them for issuing, but in that case the problem was caused due to the following reason.

Camerfirma has two different CPS:

  • CERTIFICATION PRACTICES STATEMENT DIGITAL CERTIFICATES AC CAMERFIRMA SA EIDAS
  • CERTIFICATION PRACTICES STATEMENT DIGITAL CERTIFICATES AC CAMERFIRMA SA (Not qualified Certificates)
    and each of them includes different OIDs in scope.

We created the two different ones to separate the EU qualified and EU not qualified certificates, because we had to proceed differently in terms of EU legislation and ETSI audits.

In the last years we had to change some certificates from one CPS to the other one, because we wanted to qualify some of the not qualified ones, and it seems like in one of the change processes we skipped a few OIDs that we eliminated from the not qualified CPS and were not included in the qualified one.

We performed the last review after detecting this bug to ensure that there are not more missing OIDs and published the last version of the CPS CERTIFICATION PRACTICES STATEMENT DIGITAL CERTIFICATES AC CAMERFIRMA SA EIDAS (1.2.14)

We are involved in a plan to unify the two CPSs because, all the applied measures are the same and we audit all the certificates in a same way, and we do not have any reasons to maintain two different CPSs. We would like to finish the CPS integration in the first half of 2021, but we have the eIDAS audit next month and we do not think we can have it ready yet, so this time we will include the two CPSs with all the OIDs in scope and will be totally finished by next year’s audit.

Flags: needinfo?(martin_ja)

We do not have more updates for this bug.

Flags: needinfo?(bwilson)

We do not have more updates for this bug.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [uncategorized]
You need to log in before you can comment on or make changes to this bug.