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. 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/CAErg%3DHE7dG%2Bobi2na_5G%2Bs4md0d2pG6RhXTvK15cu%2BLqxK9iKw%40mail.gmail.com.
