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 On Wed, Jan 26, 2022 at 11:30 AM Ben Wilson <[email protected]> wrote: > See responses inline below. > > On Tue, Jan 25, 2022 at 10:57 PM Ryan Sleevi <[email protected]> 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. > > >> >> I raise that as an example of something we saw several CAs do in the >> past, in violation of RFC 5280. >> >> On Wed, Jan 26, 2022 at 12:13 AM Ben Wilson <[email protected]> wrote: >> >>> 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. >>> >>> >>> On Tue, Jan 18, 2022 at 11:48 AM Corey Bonnell < >>> [email protected]> wrote: >>> >>>> > 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 >>>> >>>> >>>> >>>> *From:* 'Aaron Gable' via [email protected] < >>>> [email protected]> >>>> *Sent:* Thursday, January 13, 2022 8:12 PM >>>> *To:* Ben Wilson <[email protected]> >>>> *Cc:* [email protected] <[email protected]> >>>> *Subject:* Re: Policy 2.8: MRSP Issue #226: Update the incorrect >>>> extensions item in section 5.2 >>>> >>>> >>>> >>>> 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 >>>> >>>> >>>> >>>> On Wed, Jan 5, 2022 at 8:02 PM Ben Wilson <[email protected]> wrote: >>>> >>>> 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 >>>> <https://github.com/mozilla/pkipolicy/issues/226>. >>>> >>>> >>>> >>>> Section 5.2 of the MSRP >>>> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices> >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "[email protected]" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> 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 >>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZJJ4Z4QkhyX7mpuMca3JpdE-E7KhVmLQ4P7UND82oZzw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "[email protected]" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> 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 >>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErcWAsbsxRa3Di-k71GaCg_Yjn35dwp07OASYDmTYbK%3DWQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "[email protected]" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> 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 >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaa309rMG9921WC1iaZGG4by91jyy5zXQDXXzuQJKisMPw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabR5-n38hCA7Pz3-k%2BjiuUVPr6J8DFsxGjwVfSO0TOk%3Dw%40mail.gmail.com.
