Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs
"To repeat: the policy violation here is the omission of the id-pkix-ocsp-nocheck extension in certificates that contain the id-kp-OCSPSigning EKU"... + I understood finally: + ... regardless to the fact, that the affected CA cannot issue OCSP responses in BRG-compliant manner. Thanks! Peter On Thu, Jul 2, 2020 at 2:10 PM Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Doug, > > BR 4.9.9 says: > "...the OCSP signing Certificate MUST contain an extension of type > id-pkix-ocsp-nocheck, as defined by RFC6960." > > The certificates that Ryan has identified are OCSP signing Certificates, > because they contain the id-kp-OCSPSigning EKU. However, they have been > misissued because they don't "contain an extension of type > id-pkix-ocsp-nocheck". > > The fact that these certificates are also CA certificates is unfortunate, > because revoking a CA certificate tends to have more impact to users than > revoking a leaf certificate. > > Policy-wise, apparently it's OK for a certificate to be both a CA > certificate and a (correctly issued!) delegated OCSP signing certificate, > which is I think what Ryan's earlier post was talking about. So if the > affected CAs could go back in time and add the id-pkix-ocsp-nocheck > extension to these certificates then those certificates arguably wouldn't > have been misissued(*). > > To repeat: the policy violation here is the omission of the > id-pkix-ocsp-nocheck extension in certificates that contain the > id-kp-OCSPSigning EKU. > > (*) They might still have been "Dangerous" though, even if they hadn't > been misissued. Quoting Ryan... > "For example, > consider this certificate https://crt.sh/?id=21606064 . It was issued by > DigiCert to Microsoft, granting Microsoft the ability to provide OCSP > responses for any certificate issued by Digicert's Baltimore CyberTrust > Root. We know from DigiCert's disclosures that this is independently > operated by Microsoft." > > > From: dev-security-policy > on behalf of douglas.beattie--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> > Sent: 02 July 2020 12:38 > To: mozilla-dev-security-pol...@lists.mozilla.org < > mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Question about the issuance of OCSP Responder Certificates by > technically constrained CAs > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > > Ryan, > > Given the recent announcement "SECURITY RELEVANT FOR CAs: The curious case > of the Dangerous Delegated Responded Cert", how does you discussion in this > thread relate to this? Are your responses here to a different question, > because it appears (likely my misinterpretation) from this thread it's OK > to include OCSP-signing into a CA certificate? > > > https://groups.google.com/d/msg/mozilla.dev.security.policy/EzjIkNGfVEE/XSfw4tZPBwAJ > > > > On Wednesday, September 4, 2019 at 11:01:36 AM UTC-4, Ryan Sleevi wrote: > > On Wed, Sep 4, 2019 at 9:47 AM Peter Mate, Erdosi via > dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > My question is the following: is it allowed to issue an OCSP Responder > > > certificate with "id-kp-OCSPSigning" EKU from a technically > constrained CA > > > if the "id-kp-OCSPSigning" EKU is not listed in the CA certificate, > > > > > > This will fail, not because of policy reasons, but because of technical > > reasons (not Firefox). > > > > The code (for Firefox) is > > > https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#819-888 > > , > > with the most salient logic at > > > https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#873-884 > > , > > although the explanation in > > > https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#863-869 > > explains > > the technical reasons. > > > > > > > in other words, is the inclusion of the "id-kp-OCSPSigning" EKU a > > > possible, mandatory or forbidden option for such CAs? > > > > > > > This is not forbidden by policy. That is, a technically constrained > > subordinate CA certificate can have id-kp-OCSPSigning and > id-kp-serverAuth. > > > > As I
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
Hi Rob, thanks for the clarification. What will be the situation if the issuer is a Root CA instead of the "TLS capable (intermediate or subordinate) CA"? As far as I understood till now, it is not misissued, if the root CA cannot be considered as an "Mozilla-trusted, TLS-capable CA". And considering chapter 7.1.2.1 b) of CAB Forum BRG, extendedKeyUsage MUST NOT be present in root CA certificates, but "If the Root CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set", which is the same in the 7.1.2.2 e) : ". If the Subordinate CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set." I have not seen that the SQL query considered with digitalSignature bit, but as I interpreted until now, the CA cannot sign OCSP responses without setting the digitalSignature bit even the OCSPSigning EKU is used. And Mozilla requires the BRG-conformant CAs also, isn't it? So, I am a bit confused. Thanks again, Peter On Thu, Jul 2, 2020 at 1:21 PM Rob Stradling wrote: > Hi Peter. The "following CA certificate" (which I'll call Certificate X) > is not capable of issuing id-kp-serverAuth leaf certificates that will be > trusted by Mozilla, but that fact is entirely irrelevant to this > discussion. Notice that Ryan wrote "*issued by* a Mozilla-trusted, > TLS-capable CA" rather than "*is* a Mozilla-trusted, TLS-capable CA". > > Certificate X contains the id-kp-OCSPSigning EKU. This means that it can > be used as a delegated OCSP signer, to sign OCSP responses on behalf of its > issuer. If its issuer is "a Mozilla-trusted, TLS-capable CA", then all of > its issuer's delegated OCSP signer certificates are in scope for the BRs > and for the Mozilla Root Store Policy. > > Certificate X is an intermediate CA certificate, which is capable of > issuing id-kp-timeStamping leaf certificates. That's all very nice, but it > doesn't alter the fact that Certificate X is also a (misissued) delegated > OCSP signing certificate that is in scope for the BRs and the Mozilla Root > Store Policy. > > -- > *From:* dev-security-policy > on behalf of Peter Mate Erdosi via dev-security-policy < > dev-security-policy@lists.mozilla.org> > *Sent:* 02 July 2020 12:04 > *To:* mozilla-dev-security-policy < > mozilla-dev-security-pol...@lists.mozilla.org> > *Subject:* Re: SECURITY RELEVANT FOR CAs: The curious case of the > Dangerous Delegated Responder Cert > > Just for my better understanding, is the following CA certificate > "TLS-capable"? > > X509v3 Basic Constraints critical: > CA:TRUE > X509v3 Key Usage critical: > Certificate Sign, CRL Sign > X509v3 Extended Key Usage: > Time Stamping, OCSP Signing > > > Peter > > > > On Thu, Jul 2, 2020 at 12:14 PM Rob Stradling via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > This batch is NOT comprehensive. According to crt.sh, there are > > approximately 293 certificates that meet the criteria of "issued by a > > Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without > > pkix-nocheck". misissued.com had some issues with parsing some of these > > certificates, due to other non-conformities, so I only included a sample. > > > > I just reproduced this result. I've posted my SQL query and (thanks to > > GitHub) a searchable TSV report of all 293 certificates here: > > https://gist.github.com/robstradling/6c737c97a7a3ab843b6f24747fc9ad1f > > > > > > From: dev-security-policy > > > on behalf of Ryan Sleevi via dev-security-policy < > > dev-security-policy@lists.mozilla.org> > > Sent: 01 July 2020 22:05 > > To: mozilla-dev-security-policy < > > mozilla-dev-security-pol...@lists.mozilla.org> > > Subject: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous > > Delegated Responder Cert > > > > CAUTION: This email originated from outside of the organization. Do not > > click links or open attachments unless you recognize the sender and know > > the content is safe. > > > > > > I've created a new batch of certificates that violate 4.9.9 of the BRs, > > which was introduced with the first version of the Baseline Requirements > as > > a MUST. This is https://misissued.com/batch/138/ > > > > A quick inspection among the affected CAs include O fields of: QuoVadis, > > GlobalSign, Digicert, HARICA, Certinomis, AS Sertifitseeimiskeskus, > > Actalis, Atos, AC Camerfirma, SECOM, T-Systems, WISeKey, SCEE, and CNNIC. > > > > Section 4.9.9 of the BRs re
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
Just for my better understanding, is the following CA certificate "TLS-capable"? X509v3 Basic Constraints critical: CA:TRUE X509v3 Key Usage critical: Certificate Sign, CRL Sign X509v3 Extended Key Usage: Time Stamping, OCSP Signing Peter On Thu, Jul 2, 2020 at 12:14 PM Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > This batch is NOT comprehensive. According to crt.sh, there are > approximately 293 certificates that meet the criteria of "issued by a > Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without > pkix-nocheck". misissued.com had some issues with parsing some of these > certificates, due to other non-conformities, so I only included a sample. > > I just reproduced this result. I've posted my SQL query and (thanks to > GitHub) a searchable TSV report of all 293 certificates here: > https://gist.github.com/robstradling/6c737c97a7a3ab843b6f24747fc9ad1f > > > From: dev-security-policy > on behalf of Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> > Sent: 01 July 2020 22:05 > To: mozilla-dev-security-policy < > mozilla-dev-security-pol...@lists.mozilla.org> > Subject: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous > Delegated Responder Cert > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > > I've created a new batch of certificates that violate 4.9.9 of the BRs, > which was introduced with the first version of the Baseline Requirements as > a MUST. This is https://misissued.com/batch/138/ > > A quick inspection among the affected CAs include O fields of: QuoVadis, > GlobalSign, Digicert, HARICA, Certinomis, AS Sertifitseeimiskeskus, > Actalis, Atos, AC Camerfirma, SECOM, T-Systems, WISeKey, SCEE, and CNNIC. > > Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST > include an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP > Delegated Responder within Section 4.2.2.2 as indicated by the presence of > the id-kp-OCSPSigning as an EKU. > > These certificates lack the necessary extension, and as such, violate the > BRs. As the vast majority of these were issued on-or-after 2013-02-01, the > Effective Date of Mozilla Root CA Policy v2.1, these are misissued. You > could also consider the effective date as 2013-05-15, described later in > [1] , without changing the results. > > This batch is NOT comprehensive. According to crt.sh, there are > approximately 293 certificates that meet the criteria of "issued by a > Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without > pkix-nocheck". misissued.com had some issues with parsing some of these > certificates, due to other non-conformities, so I only included a sample. > > Censys.io is aware of approximately 276 certificates that meet this > criteria, as you can see at [2]. The differences in perspectives > underscores the importance of CAs needing to carefully examine the > certificates they've issued to understand. > > It's important for CAs to understand this is Security Relevant. While they > should proceed with revoking these CAs within seven (7) days, as defined > under the Baseline Requirements Section 4.9.1.2, the degree of this issue > likely also justifies requiring witnessed Key Destruction Reports, in order > to preserve the integrity of the issuer of these certificates (which may > include the CA's root). > > The reason for this is simple: In every case I examined, these are > certificates that appear to nominally be intended as Issuing CAs, not as > OCSP Responder Certificates. It would appear that many CAs were unfamiliar > with RFC 6960 when constructing their certificate profiles, and similarly > ignored discussion of this issue in the past [3], which highlighted the > security impact of this. I've flagged this as a SECURITY matter for CAs to > carefully review, because in the cases where a third-party, other than the > Issuing CA, operates such a certificate, the Issuing CA has delegated the > ability to mint arbitrary OCSP responses to this third-party! > > For example, consider a certificate like https://crt.sh/?id=2657658699 . > This certificate, from HARICA, meets Mozilla's definition of "Technically > Constrained" for TLS, in that it lacks the id-kp-serverAuth EKU. However, > because it includes the OCSP Signing EKU, this certificate can be used to > sign arbitrary OCSP messages for HARICA's Root! > > This also applies to non-technically-constrained sub-CAs. For example, > consider this certificate https://crt.sh/?id=21606064 . It was issued by > DigiCert to Microsoft, granting Microsoft the ability to provide OCSP > responses for any certificate issued by Digicert's Baltimore CyberTrust > Root. We know from DigiCert's disclosures that this is independently > operated by Microsoft. > > Unfortunately, revocation of this
Question about the issuance of OCSP Responder Certificates by technically constrained CAs
Dear list, I have a question about the issuance of the OCSP responder certificates in case of technically constrained CAs. I apologize for the long introduction, but this may be an important audit question in the (near) future. --- BEGIN INTRO --- I would like to cite five points from the relevant requirements. 1. Section 5.3.1 of Mozilla Policy declares that "We encourage CAs to technically constrain all intermediate certificates." and in 5.3 we can read: "Intermediate certificates created after January 1, 2019, with the exception of cross-certificates that share a private key with a corresponding root certificate: MUST contain an EKU extension; and, MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and, * MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate." 2. If an issuer CA is technically constrained, the CA certificate will contain one or more of Extended Key Usage (EKU) extensions as specified in 4.2.1.12 of RFC 5280. (e.g. id-kp-serverAuth, id-kp-clientAuth, id-kp-emailProtection, id-kp-OCSPSigning ...) with the corresponding Key Usage (KU) bits (e.g. digitalSignature, keyCertSign, cRLSign). 3. CAB Forum Baseline requires the support of the OCSP service in 4.9.9 and 4.9.10, moreover ETSI EN 319 411-1 requires it also: "CSS-6.3.10-07 [PTC]: OCSP shall be supported." Microsoft Root Program requires in Section 4.A.5. that "All end-entity server authentication certificates must contain an AIA extension with a valid OCSP URL." So, OCSP service is mandatory for the issuers of the publicly trusted certificates. 4. RFC 6960 details the signature of OCSP responses in 2.2: "All definitive response messages SHALL be digitally signed. The key used to sign the response MUST belong to one of the following: - the CA who issued the certificate in question - a Trusted Responder whose public key is trusted by the requestor - a CA Designated Responder (Authorized Responder, defined in Section 4.2.2.2) who holds a specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA". 5. Section 4.2.2.2. of RFC 6960 explains that "The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary, however, to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MUST do one of the following: - sign the OCSP responses itself, or - explicitly designate this authority to another entity OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extended key usage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA that is identified in the request. The CA SHOULD use the same issuing key to issue a delegation certificate as that used to sign the certificate being checked for revocation. Systems relying on OCSP responses MUST recognize a delegation certificate as being issued by the CA that issued the certificate in question only if the delegation certificate and the certificate being checked for revocation were signed by the same key." --- END INTRO --- My question is the following: is it allowed to issue an OCSP Responder certificate with "id-kp-OCSPSigning" EKU from a technically constrained CA if the "id-kp-OCSPSigning" EKU is not listed in the CA certificate, in other words, is the inclusion of the "id-kp-OCSPSigning" EKU a possible, mandatory or forbidden option for such CAs? As I see in the practice, if a technically constrained CA signs the OCSP response itself, it can be done without the "id-kp-OCSPSigning" EKU but with the "digitalSignature" KU bit in the CA certificate. I followed the relating discussion in the archive (Feb 1, 2013) and found this: "Inclusion of EKU in CA certificates is generally allowed. (...) The use of the EKU extension in intermediate certificates was discussed at length in the mozilla.dev.security.policy forum. We considered other options, such as standardizing a set of Policy OIDs or un-deprecating NetscapeCertType. The discussion included the concern that one interpretation of RFC 5280 is that this use of EKU is non-standard, but it was decided that the RFCs are not clear, and perhaps conflicting, in regards to EKUs in CA certificates. In the discussion it was pointed out that other major browsers and client software already support this use of EKU but do not recognize NetscapeCertType; and we also recognized the difficulties involved in standardizing a set of Policy OIDs. The conclusion of the discussion was that EKU is the best tool for technically constraining the types of certificates that an intermediate certificate may sign." But this answer is not so clear for me in case of issuer CA certificates if the CA wants to authorize a CA
