Policy 2.8: MRSP Issue #226: Update the incorrect extensions item in section 5.2

[Ben Wilson]

All,

This email introduces discussion of another issue to be resolved by the next version of the Mozilla Root Store Policy (MSRP), version 2.8. (See https://github.com/mozilla/pkipolicy/labels/2.8)

This is Github Issue #226.

Section 5.2 of the MSRP lists the following certificate-related errors:

"CAs MUST NOT issue certificates that have:

• ASN.1 DER encoding errors;
• invalid public keys (e.g., RSA certificates with public exponent equal to 1);
• duplicate issuer names and serial numbers (except that a Certificate Transparency pre-certificate is allowed to match the corresponding certificate);
• incorrect extensions (e.g., SSL certificates that exclude SSL usage, or authority key IDs that include both the key ID and the issuer’s issuer name and serial number); or
• cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists."

Specifically, this issue arose during a discussion of the fourth bullet - "incorrect extensions" and whether the example was an accurate statement.  The examples within the parentheses need to be clarified or replaced. For illustration, bullet 4 could be replaced with "incorrect extensions (e.g., a TLS certificate with the codeSigning EKU or a CA certificate without the basicConstraints extension);"

What other improvements could we make to this section?

There are other certificate problems we've seen more recently. Should those be added to the list? If so, which ones?

Should any items be removed from the list?

Thoughts?

Thanks,

Ben

 

[Aaron Gable]

A recently-relevant example could be "an OCSP Delegated Responder without the id-pkix-ocsp-nocheck extension".

I think it is important to remove/improve the "SSL certificates that exclude SSL usage", given that a cert which does not have the TLSServerAuth EKU is by definition not an SSL certificate, so it's not crystal clear what the example means.

Aaron

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZJJ4Z4QkhyX7mpuMca3JpdE-E7KhVmLQ4P7UND82oZzw%40mail.gmail.com.

[Corey Bonnell]

> A recently-relevant example could be "an OCSP Delegated Responder without the id-pkix-ocsp-nocheck extension".

 

This is a good example for a BR profile violation. However, since the Mozilla Root Program also includes SMIME certificate issuance and there is currently no requirement for ocsp-nocheck to be included in OCSP Delegated Responder certificates for SMIME, this example may cause confusion.

 

> I think it is important to remove/improve the "SSL certificates that exclude SSL usage", given that a cert which does not have the TLSServerAuth EKU is by definition not an SSL certificate, so it's not crystal clear what the example means.

 

Agreed. Perhaps “SSL certificates that exclude SSL usage” can be changed to: “TLS certificates with no subjectAltName extension”

 

Thanks,

Corey

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErcWAsbsxRa3Di-k71GaCg_Yjn35dwp07OASYDmTYbK%3DWQ%40mail.gmail.com.

[Ben Wilson]

How can we expand this list to include CRLs and OCSP responses and still have it make sense? 

See e.g., https://github.com/BenWilson-Mozilla/pkipolicy/commit/33ac2c35fd87a2bdf7528578df8bd2c6ae5f272b

CAs MUST NOT issue certificates or, where applicable, CRLs or OCSP responses, that have:

*   ASN.1 DER encoding errors;
*   invalid public keys (e.g., RSA certificates with public exponent equal to 1);
*   duplicate issuer names and serial numbers (except that a Certificate Transparency pre-certificate is allowed to match the corresponding
    certificate);
*   missing or incorrect extensions (e.g., TLS certificates with no subjectAltName extension, delegated OCSP responders without the id-pkix-ocsp-nocheck extension); *or*
*   cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists.

[Ryan Sleevi]

Why “where applicable”? It’s not clear to me, and I worry that it equally may not be clear to others, particularly CAs. We definitely saw issues with interpretations about applicability in the past.

I suspect you were trying to limit which of the following clauses, but it reads as if it is limiting the situations those clauses should be considered.

Would it achieve the same goal to remove “where applicable”? Alternatively, pulling out the third and final bullet points into a separate list only for certificates?

Finally, does it make sense to add an example of a missing/incorrect extension for CRLs, like “issuing partial/scoped CRLs that lack a distributionPoint in a critical issuingDistributionPoint extension”

I raise that as an example of something we saw several CAs do in the past, in violation of RFC 5280.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaa309rMG9921WC1iaZGG4by91jyy5zXQDXXzuQJKisMPw%40mail.gmail.com.

[Ben Wilson]

See responses inline below.

On Tue, Jan 25, 2022 at 10:57 PM Ryan Sleevi <ry...@sleevi.com> wrote:

Why “where applicable”? It’s not clear to me, and I worry that it equally may not be clear to others, particularly CAs. We definitely saw issues with interpretations about applicability in the past.

I suspect you were trying to limit which of the following clauses, but it reads as if it is limiting the situations those clauses should be considered.

Would it achieve the same goal to remove “where applicable”? Alternatively, pulling out the third and final bullet points into a separate list only for certificates?

That was my intent. So maybe we split it into separate lists?  I'll try another approach that does this.

 

Finally, does it make sense to add an example of a missing/incorrect extension for CRLs, like “issuing partial/scoped CRLs that lack a distributionPoint in a critical issuingDistributionPoint extension”

Thanks for the suggestion.  I'll work on it.

[Ben Wilson]

I've made some edits to the proposed language in Github, so I'd be interested to hear your thoughts.  Here is what I currently have:

CAs MUST NOT issue certificates, CRLs, or OCSP responses, that have:

• ASN.1 DER encoding errors;
• invalid public keys (e.g., RSA certificates with public exponent equal to 1); or
• missing or incorrect extensions (e.g., TLS certificates with no subjectAltName extension, delegated OCSP responders without the id-pkix-ocsp-nocheck extension, partial/scoped CRLs that lack a distributionPoint in a critical issuingDistributionPoint extension).

CAs MUST NOT issue certificates that have:

• duplicate issuer names and serial numbers (except that a Certificate Transparency pre-certificate is allowed to match the corresponding certificate); or

• cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists.

(It might be nice to have a third bullet to this second list - issues only found with certificates and not also in CRLs / OCSP responses.)

Thanks in advance.

Ben