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%2B1gtaZYEqyc-53rYwaykZx2xWb-HPjoootxStPR7cvdnV3_yw%40mail.gmail.com.
