Question about the issuance of OCSP Responder Certificates by technically constrained CAs

[per...@gmail.com]

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 Designated Responder as its OCSP responder. I am sorry if I missed something.

I am grateful for any opinion, thank you in advance!

Peter

[Ryan Sleevi]

On Wed, Sep 4, 2019 at 9:47 AM Peter Mate, Erdosi via dev-security-policy <
dev-secur...@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 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.
>

Correct, if the id-kp-OCSPSigning EKU is missing from the technically
constrained intermediate, direct signing still works.

[Ben Wilson]

I thought that the EKU "id-kp-OCSPSigning" was for the OCSP responder
certificate itself (not the CA that issues the OCSP responder certificate).
I don't think I've encountered a problem before, but I guess it would depend
on the implementation?

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Ryan Sleevi]

On Wed, Sep 4, 2019 at 11:06 AM Ben Wilson <ben.w...@digicert.com> wrote:

> I thought that the EKU "id-kp-OCSPSigning" was for the OCSP responder
> certificate itself (not the CA that issues the OCSP responder certificate).
> I don't think I've encountered a problem before, but I guess it would
> depend
> on the implementation?

Correct. Mozilla does not require the EKU chaining, in technical
implementation or in policy. The aforementioned comments, however, indicate
CAs have reported that Microsoft does. That is, the assertion is that
Microsoft requires that issuing CAs bear an overlapping set of EKUs that
align with their issued certificates, whether subordinate CAs, end-entity,
or OCSP responders. Mozilla requires the same thing with respect to
id-kp-serverAuth, but the Mozilla code has a special carve-out for
id-kp-OCSPSigning that both doesn't require it on intermediate CAs, but
also allows it to be present, precisely because of the presumed Microsoft
requirement.

[Jakob Bohm]

This Microsoft requirement is highly unfortunate, because unless there
is an explicit RFC permission that allows OCSP clients to reject OCSP
certificates from delegated OCSP responder certificates with CA:TRUE,
yet accept them from issuing CA certificates with CA:TRUE; clients will
be required by RFCs to accept bogus OCSP responses signed by SubCA
certificates that contain the EKU for Microsoft compatibility.

This is especially bad if the SubCA is controlled by an entity other
than its direct parent CA.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Robin Alden]

> The aforementioned comments, however, indicate CAs have reported that Microsoft does [require the EKU chaining].
I agree that statement is true, but I think it inadvertently misleads.

We cannot speak for Microsoft about what their requirements for id-kp-OCSPSigning are, and we are not aware of documentation from Microsoft that sets out the answer, but we do have experience that sheds some light on the matter.

The Scenario
===========
We are a root CA.
In compliance with Mozilla CA policy we signed a constrained intermediate CA certificate whose public key corresponded to a private key held by a customer organization.
The constrained intermediate CA was to sign end entity certificates.
The constrained intermediate CA was not directly to sign OCSP responses, but instead was to sign an OCSP responder certificate that would be used to sign OCSP responses.

The intermediate CA certificate included an EKU, but the EKU did not include id-kp-OCSPSigning.

The first certificate that the intermediate CA was to sign was the OCSP responder certificate, and the OCSP responder certificate was to include an EKU with id-kp-OCSPSigning.

The Problem
===========
The customer was using Microsoft's Certificate Authority platform to issue end entity certificates using the Intermediate CA.

The customer found they were unable to issue the OCSP responder certificate (including id-kp-OCSPSigning) because the Microsoft CA software would not issue such a certificate since the signing CA (i.e. the intermediate CA) had an EKU but did not include id-kp-OCSPSigning. I.e. Microsoft's Certificate Authority requires EKU chaining.

An 'obvious' solution would have been to re-issue the Intermediate CA certificate and include id-kp-OCSPSigning in its EKU. Obviously wrong in this case since had we done so the Intermediate CA (i.e. our customer) would then have been able to sign OCSP responses for any certificate issued by our Root CA.

Another solution would have been to re-issue the Intermediate CA certificate and omit the EKU extension altogether but this would have been against policy since the BRs require the EKU to be present for a CA to be considered technically constrained.

The fix
=====
The work around was for us to create for our customer a second CA certificate that had an EKU including id-kp-OCSPSigning and used the same public key and subjectDN as the Intermediate CA certificate, but this time for us to sign it with an untrusted CA.

We anticipate that the customer could also have created a self-signed CA for themselves using the Intermediate CA key, but did not test that.

The Microsoft CA Platform was then happy to sign an OCSP responder certificate including id-kp-OCSPSigning from this second untrusted CA.
Since the key and subjectDN for the untrusted CA are the same as the key and subjectDN of the Intermediate CA certificate, this OCSP responder certificate also chains up through the Issuing CA to our trusted root.

The OCSP responder could now be provisioned and the Intermediate CA could then begin to issue end entity certificates whose OCSP responses were signed by the OCSP responder certificate's key.

The take-away
============
The OCSP responses for the end entity certificates worked fine with browsers on the web.
As far as the relying parties were concerned, the only certificate that included id-kp-OCSPSigning was the OCSP responder certificate. No other certificate in the chain included id-kp-OCSPSigning.

So, while it is true to say that "Microsoft does require the EKU chaining", for id-kp-OCSPSigning the only place we have observed them to require it is in the Microsoft Certificate Authority software.

We have no reason to believe that their operating systems or browsers require EKU chaining for id-kp-OCSPSigning in the web PKI.

Does anyone have any evidence to the contrary?

Regards
Robin Alden
Sectigo Limited

[Santhan]

This sounds right to me and I definitely remember ADCS behaving this way. Also the CRLF_IGNORE_INVALID_POLICIES flag will let you override and issue regardless, but obviously not recommended because it overrides all policy errors.

Thanks,
Santhan

[douglas...@gmail.com]

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

[Pedro Fuentes]

+1
I got the same understanding when I read this last year.

[Rob Stradling]

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 <dev-security-...@lists.mozilla.org> on behalf of douglas.beattie--- via dev-security-policy <dev-secur...@lists.mozilla.org>
Sent: 02 July 2020 12:38
To: mozilla-dev-s...@lists.mozilla.org <mozilla-dev-s...@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:

[Peter Mate Erdosi]

"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

[Corey Bonnell]

> 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(*).

Wouldn't adding the nocheck extension make the subCA certificate irrevocable,
thus in the case of a subCA certificate with serverAuth and ocspSigning EKUs,
violate the spirit (and maybe the wording?) of sections 4.9.7 and 4.9.10 of
the BRs, which mandate the availability of revocation services for the subCA
certificate?

Thanks,
Corey

[Neil Dunbar]

On 02/07/2020 13:31, Corey Bonnell via dev-security-policy wrote:
> Wouldn't adding the nocheck extension make the subCA certificate irrevocable,
> thus in the case of a subCA certificate with serverAuth and ocspSigning EKUs,
> violate the spirit (and maybe the wording?) of sections 4.9.7 and 4.9.10 of
> the BRs, which mandate the availability of revocation services for the subCA
> certificate?

I guess that you could still revoke via a CRL based mechanism.
id-pkix-ocsp-nocheck relevance seems limited to RFC 6960 Section
4.2.2.2.1. - I don't think it touches CRL interpretation.

However, I'm struggling to come up with a reason why one would want an
issuing CA which is also a delegated OCSP Responder for its issuing CA,
even if such a thing is RFC and BR compliant!

Regards,

Neil

[Ryan Sleevi]

You wouldn’t!

This was originally part of SC31 (forbidding this), but moved to “cleanups
and clarifications” because of the logical intersection of the many
requirements is, as was pointed out to me as well, that such a thing is not
permitted, and not desired.

I focused on nocheck because that’s a *clear and unambiguous* violation of
policy, and doesn’t rely on any interpretation of EKU chaining. As others
have rightfully pointed out, if the EKU is present, it is a delegated
responder, full stop.

>

[Corey Bonnell]

(Sorry Ryan and Neil for the double-email, I accidentally omitted the list on
the first email)

> As others have rightfully pointed out, if the EKU is present, it is a
> delegated responder, full stop.

For the certificate to be used as a delegated responder (as opposed to an
issuer of OCSP responder certificates), wouldn't they also need a keyUsage
value of digitalSignature?

Thanks,
Corey

[Ryan Sleevi]

On Thu, Jul 2, 2020 at 9:36 AM Corey Bonnell <CBon...@securetrust.com>
wrote:

No, this isn’t specified/required for Delegated Reaponders (at least, by
6960), and the client implementations I looked at did not check.

I suspect you’re thinking about RFC 5280, Section 4.2.1.3’s normative
requirement on the issuer of such certificates needing to include the KU?
If so, that just seems to be arguing yet another way these certificates
violate the requirements/profile. RFC 6960 is clear that the EKU indicates
a designated responder, and you can’t “take back” that by suggesting the
lack of the KU, as required by 5280, or the lack of nocheck, as required by
the BRs, makes it “not a Responder”. It just makes it “not a correctly
issued responder”.

[Corey Bonnell]

> No, this isn’t specified/required for Delegated Reaponders (at least, by 6960), and the client implementations I looked at did not check.

>From RFC 5280, section 4.2.1.12:

If a certificate contains both a key usage extension and an extended

key usage extension, then both extensions MUST be processed

independently and the certificate MUST only be used for a purpose

consistent with both extensions.

…

id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }

-- Signing OCSP responses

-- Key usage bits that may be consistent: digitalSignature

-- and/or nonrepudiation



If clients aren’t checking for digitalSignature keyUsage when verifying OCSP responses signed by a delegated responder, that seems like a client implementation bug.

> RFC 6960 is clear that the EKU indicates a designated responder, and you can’t “take back” that by suggesting the lack of the KU, as required by 5280, or the lack of nocheck, as required by the BRs, makes it “not a Responder”. It just makes it “not a correctly issued responder”.

I don’t think it’s that clear-cut, as there’s an impedance mismatch between the use of EKU in CA certificates to enforce policy and IETF work products. In other words, several Root Programs/the BRs have used EKU in CA certificates to denote policy scope, whereas the IETF in its various standards have the assumption that EKU is generally only expressed in end-entity certificates. I think that this interplay needs to be kept in mind when reading RFC 6960 and asserting whether or not the sole determiner on whether a CA certificate is an OCSP responder certificate is the presence of the ocspSigning EKU.



Thanks,

Corey

From: Ryan Sleevi <ry...@sleevi.com>
Sent: Thursday, July 2, 2020 9:57 AM
To: Corey Bonnell <CBon...@securetrust.com>
Cc: ry...@sleevi.com; Neil Dunbar <ndu...@trustcorsystems.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

[Ryan Sleevi]

On Thu, Jul 2, 2020 at 10:47 AM Corey Bonnell <CBon...@securetrust.com>
wrote:

> > No, this isn’t specified/required for Delegated Reaponders (at least,
> by 6960), and the client implementations I looked at did not check.
>
>
>
> From RFC 5280, section 4.2.1.12:
>
> If a certificate contains both a key usage extension and an extended
>
> key usage extension, then both extensions MUST be processed
>
> independently and the certificate MUST only be used for a purpose
>
> consistent with both extensions.
>
> …
>
> id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
>
> -- Signing OCSP responses
>
> -- Key usage bits that may be consistent: digitalSignature
>
> -- and/or nonrepudiation
>
>
>
> If clients aren’t checking for digitalSignature keyUsage when verifying
> OCSP responses signed by a delegated responder, that seems like a client
> implementation bug.
>

You're reading an obligation on the CA, not an obligation on the client.

I think it might be useful, if you'd like to talk about client mitigation
strategies, to start a separate thread. I agree, there's definitely useful
opportunities here, but there is no reasonable defense that the CA has not
introduced a meaningful security issue here by violating the BRs.

> > RFC 6960 is clear that the EKU indicates a designated responder, and
> you can’t “take back” that by suggesting the lack of the KU, as required by
> 5280, or the lack of nocheck, as required by the BRs, makes it “not a
> Responder”. It just makes it “not a correctly issued responder”.
>
>
>
> I don’t think it’s that clear-cut, as there’s an impedance mismatch
> between the use of EKU in CA certificates to enforce policy and IETF work
> products. In other words, several Root Programs/the BRs have used EKU in CA
> certificates to denote policy scope, whereas the IETF in its various
> standards have the assumption that EKU is generally only expressed in
> end-entity certificates. I think that this interplay needs to be kept in
> mind when reading RFC 6960 and asserting whether or not the sole determiner
> on whether a CA certificate is an OCSP responder certificate is the
> presence of the ocspSigning EKU.
>

I directly acknowledged that interplay, but it does not justify the
violation, nor ameliorate the security risk.

I wanted to nip this argument in the bud, because I have zero tolerance for
it, as it is fundamentally the question of intent. This is the same
argument regarding "We didn't intend for this to be able to issue TLS
certs, it just could", or the "We didn't intend for this sub-CA to be
unconstrained, it just was" or "We didn't intend to give a
basicConstraints:CA=TRUE certificate to a subscriber, it just happened". As
consumers of client certs, we sadly like insight into the ever complex and
tortured minds of those operating CAs, and cannot discern intent. We have
the certificate in front of us. And the certificate in front of us is,
unambiguously, a Delegated Responder. And lacks the requisite extension.

A wholly irresponsible argument would be "We clearly didn't intend for it.
Look, you can see that: we didn't comply with the certificate profile
specified! We omitted pkix-nocheck and the KU". I don't think that's the
argument you're making, or at least, I hope not, because that's a CA asking
to be judged based on how they feel, rather than what they do and how well
they do it. And I don't think anyone wants feelings to be introduced as the
primary factor when deciding whether to continue trusting a CA or not.

[Corey Bonnell]

>> If a certificate contains both a key usage extension and an extended

key usage extension, then both extensions MUST be processed

independently and the certificate MUST only be used for a purpose

consistent with both extensions.

> You're reading an obligation on the CA, not an obligation on the client.

It’s an obligation on the client, because the verb “processed” makes no sense if the intent were to restrict only CAs.

>> I think it might be useful, if you'd like to talk about client mitigation strategies, to start a separate thread. I agree, there's definitely useful opportunities here, but there is no reasonable defense that the CA has not introduced a meaningful security issue here by violating the BRs.

If there’s no digitalSignature KU, then the certificate is not a OCSP responder certificate due to the technical inability to sign OCSP responses that would be accepted by clients conforming to RFC 5280, section 4.2.1.12. Therefore, section 4.9.9 is not applicable for those certificates that not express the digitalSignature KU. This is directly relevant to the topic at hand.

Thanks,

Corey



From: Ryan Sleevi <ry...@sleevi.com>
Sent: Thursday, July 2, 2020 10:59 AM
To: Corey Bonnell <CBon...@securetrust.com>
Cc: ry...@sleevi.com; Neil Dunbar <ndu...@trustcorsystems.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

On Thu, Jul 2, 2020 at 10:47 AM Corey Bonnell <CBon...@securetrust.com <mailto:CBon...@securetrust.com> > wrote:

> No, this isn’t specified/required for Delegated Reaponders (at least, by 6960), and the client implementations I looked at did not check.

>From RFC 5280, section 4.2.1.12 <http://scanmail.trustwave.com/?c=4062&d=5Pb93gULBMmYYjWfo2KCGEGxPtFEeeo_pjimEvYGzQ&s=5&u=http%3a%2f%2f4%2e2%2e1%2e12> :

[Ryan Sleevi]

On Thu, Jul 2, 2020 at 11:36 AM Corey Bonnell <CBon...@securetrust.com>
wrote:

> >> If a certificate contains both a key usage extension and an extended
>
> key usage extension, then both extensions MUST be processed
>
> independently and the certificate MUST only be used for a purpose
>
> consistent with both extensions.
>
>
>
> > You're reading an obligation on the CA, not an obligation on the client.
>
>
>
> It’s an obligation on the client, because the verb “processed” makes no
> sense if the intent were to restrict only CAs.
>

They're processed independently. The usage requirement is on the CA.

>
>
> >> I think it might be useful, if you'd like to talk about client
> mitigation strategies, to start a separate thread. I agree, there's
> definitely useful opportunities here, but there is no reasonable defense
> that the CA has not introduced a meaningful security issue here by
> violating the BRs.
>
>
>
> If there’s no digitalSignature KU, then the certificate is not a OCSP
> responder certificate due to the technical inability to sign OCSP responses
> that would be accepted by clients conforming to RFC 5280, section 4.2.1.12.
> Therefore, section 4.9.9 is not applicable for those certificates that not
> express the digitalSignature KU. This is directly relevant to the topic at
> hand.
>

Alternatively: If the OCSPSigning EKU is present, and it lacks
DigitalSignature, it's misissued by containing an invalidEKU.

I'll put it bluntly: Your argument is deeply troubling and I would have
little hesitation arguing for the full and immediate distrust of a CA that
made it, that's how extremely problematic I see it. I appreciate that we're
discussing in the abstract, but I want to emphasize how ardently I reject
this argument when it comes to CAs filing their incident reports, to make
sure they don't point to this thread as if somehow you've made the argument
for them.

The same logic being applied here would say that a Subscriber certificate,
which had a TLS serverAuth EKU, was not actually a "server" certificate if
the KU is wrong. Worse, however, you'd similarly argue that if the KU *is*
wrong, nothing else about the certificate could be considered misissued,
because it's clearly "not a TLS server certificate". After all, 7.1.2.3(e)
of the BRs only has KU as optional, and 1.1 of the BRs only applies to
certificates "intended" for TLS, and your argument would say KU shows
intent.

That's a fundamentally flawed argument, and deeply troubling.

At the heart of our disagreement is that you'd like to read something like
4.2.2.2 of RFC 6960, which says "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",
and add a clause "if and only if the KU is consistent". And I can
understand why that'd be appealing, and certainly when we talk about client
usage, why that would be desirable. But much like we talk about scoping
issues, the mere act of including the EKU designates it as a Responder
certificate. If the KUs are wrong, and if clients checked KUs, that would
mitigate some of the harm, but doesn't change the fundamental fact that
it's still been designated, by the CA, as an OCSP Responder. It may not be
useful as one, but it still *is* a responder certificate, and 4.9.9 applies.

If you're wondering why clients aren't checking the KUs, it's because of
how widespread the failures to properly encode KUs were, even for CA
certificates. Consider Golang's verifier, which skips over KU checks
because of wonky CAs, and shares why. Consider that Chromium was not able
to enforce id-kp-serverAuth consistency with the KU until **2019** because
of how bad the ecosystem was [2]. None of this dismisses the fact that the
CA was, and is, wrong for having issued invalid OCSP Delegated Responder
certificates, but highlights why this idealistic appeal to KU purity
disregards the security landscape that CAs are operating in, and should be
aware of.

[1] https://golang.org/src/crypto/x509/verify.go#L684
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=795089

[Rob Stradling]

On 02/07/2020 17:13, Ryan Sleevi via dev-security-policy wrote:
> On Thu, Jul 2, 2020 at 11:36 AM Corey Bonnell wrote:
<snip>

>> If there’s no digitalSignature KU, then the certificate is not a OCSP
>> responder certificate due to the technical inability to sign OCSP responses
>> that would be accepted by clients conforming to RFC 5280, section 4.2.1.12.
>> Therefore, section 4.9.9 is not applicable for those certificates that not
>> express the digitalSignature KU. This is directly relevant to the topic at
>> hand.
>
> Alternatively: If the OCSPSigning EKU is present, and it lacks
> DigitalSignature, it's misissued by containing an invalidEKU.

As Ryan already mentioned, RFC6960 very clearly says:
"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."

The presence or absence of the DigitalSignature Key Usage bit does not
alter this fact.

RFC6960 doesn't mention the Key Usage extension at all, AFAICT.

https://tools.ietf.org/html/rfc5280#section-4.2.1.12 doesn't use any

RFC2119 keywords when it says:
"id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
-- Signing OCSP responses
-- Key usage bits that may be consistent: digitalSignature

-- and/or nonRepudiation"

The BRs say...
"If the Root CA Private Key is used for signing OCSP responses, then
the digitalSignature bit MUST be set."
and
"If the Subordinate CA Private Key is used for signing OCSP responses,
then the digitalSignature bit MUST be set"
...but this is obviously intended to refer to OCSP responses signed
directly by the CA (rather than OCSP responses signed by a CA that also
masquerades as a delegated OCSP response signer!)

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

[Ryan Sleevi]

Even if a CA wanted to argue that there's no 4.9.9 BR violation (which, as
I suggested, I would strongly advocate for their distrust, due to the
logical consequences of such an argument), the KU violation itself can be
argued a Mozilla violation, using the exact language Corey highlighted.

Recall Section 5.2 of Mozilla Root Policy 2.7:
https://github.com/mozilla/pkipolicy/blob/66ac6b888965aefc88a8015b37d2ee6b5b095fba/rootstore/policy.md#52-forbidden-and-required-practices

"""
CAs MUST NOT issue certificates that have:
...
* incorrect extensions
"""

While a list of possible incorrect extensions is included, if the argument
is that the EKU doesn't matter because the KU is incorrect for that EKU,
then it's an argument that the CA has issued a certificate with incorrect
extensions. Which is still a Mozilla Root Store Policy violation.

[Jeremy Rowley]

Threatening distrust over a discussion about applicability of requirements seems contrary to Mozilla's open discussion policy, and I don't think that should be an answer while there are still open questions about the language in 4.9.9. Separating out the security risk from the applicability of the BRs is useful because it highlights potentially poor language in the BRs. For example:

Section 4.9.9:
OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either:
1. Be signed by the CA that issued the Certificates whose revocation status is being checked, or
2. Be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose revocation status is being checked.
In the latter case, the OCSP signing Certificate MUST contain an extension of type id-pkix-ocsp-nocheck, as defined by RFC6960
The requirement for no-check only applies in the latter case, which is if the OCSP response is signed by an OCSP responder. How would the no-check requirement apply if no OCSP responses are being signed by the responder. If the ICAs aren't signing, why does it apply?

Should the OCSP issue be fixed? Definitely. The security issues are apparent. Should the BR language be modified for clarity? I think that conversation is still ongoing and shutting that down with threats of distrust is counter productive.

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Ryan Sleevi via dev-security-policy

Sent: Thursday, July 2, 2020 11:05 AM
To: Rob Stradling <r...@sectigo.com>
Cc: Mozilla <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

[Ryan Sleevi]

On Thu, Jul 2, 2020 at 1:33 PM Jeremy Rowley via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Threatening distrust over a discussion about applicability of requirements
> seems contrary to Mozilla's open discussion policy, and I don't think that
> should be an answer while there are still open questions about the language
> in 4.9.9.

That isn't what was said at all, and it doesn't do anyone any good to
misrepresent it so egregiously.

A CA using the arguments Corey made as part of their CA incident response?
Absolutely. Because it's a terrible incident response, and a CA arguing
that as part of an incident response is a CA that is arguing in bad faith,
because it's the same argument over "intent" that has been shut down over
and over.

Separating out the security risk from the applicability of the BRs is
> useful because it highlights potentially poor language in the BRs. For
> example:
>
> Section 4.9.9:
> OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST
> either:
> 1. Be signed by the CA that issued the Certificates whose revocation
> status is being checked, or
> 2. Be signed by an OCSP Responder whose Certificate is signed by the CA
> that issued the Certificate whose revocation status is being checked.
> In the latter case, the OCSP signing Certificate MUST contain an extension
> of type id-pkix-ocsp-nocheck, as defined by RFC6960
> The requirement for no-check only applies in the latter case, which is if
> the OCSP response is signed by an OCSP responder. How would the no-check
> requirement apply if no OCSP responses are being signed by the responder.
> If the ICAs aren't signing, why does it apply?
>
> Should the OCSP issue be fixed? Definitely. The security issues are
> apparent.

Good, that's the focus, and for some CAs, based on discussions had before
filing this incident report, they did not see it as apparent, even after
Robin's educational highlighting of the security issues nearly a year ago.

> Should the BR language be modified for clarity? I think that conversation
> is still ongoing and shutting that down with threats of distrust is counter
> productive.
>

And I'm not shutting down that discussion. My examination of this incident
in the first place was triggered by CAs, among others including GlobalSign
and HARICA, not realizing that this was an existing requirement when I made
an explicit proposal to clarify this in the BRs, by prohibiting
`id-kp-OCSPSigning` from being combined with other EKUs. Would that have
fixed 4.9.9? No, and so I'm making sure to also add that to the "Cleanups
and Clarifications" ballot. And I'm sure the CABF Validation WG will no
doubt, in light of this, realize that we need an "OCSP Responder" profile
to go with the other profiles being worked on.

The threat of distrust isn't over discussing how to make this *better*.
That's of course welcome to highlight where requirements aren't clear. It
would be entirely appropriate a CA would, as part of their incident
response, argue this is *not an incident*. I would hate if CAs,
particularly those in the CA Security Council, were to try and coordinate
and argue it's not an issue. I would especially hate if CAs were to point
to Corey's arguments in particular, as a means of trying to create a
parallel construction for why they did what they originally did (which is,
more likely, explained by just not reading/being aware of the
requirements), especially if trying to avoid the need to come up with a
plan to revoke these CAs.

Corey's not making this argument as part of an incident response, and so I
*do* appreciate his attempt to highlight issues to improve. However, I'm
trying to make it clear that the argument for why this is not an issue is
not valid, and if a CA were to try to argue WontFix/Invalid (or, more
aptly, "won't revoke, we don't think it's relevant"), that'd be an
absolutely awful response.

[Jeremy Rowley]

Thank you for the clarification – and I definitely agree with you that the time to talk about this is now, one the Mozilla list, and not in the incident reports. It’s not helpful to have the discussion there since it lacks the public benefit.

From: Ryan Sleevi <ry...@sleevi.com>
Sent: Thursday, July 2, 2020 11:51 AM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: Mozilla <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

[Corey Bonnell]

>> It’s an obligation on the client, because the verb “processed” makes no
sense if the intent were to restrict only CAs.

> They're processed independently. The usage requirement is on the CA.

I don't see how this is relevant. The language clearly states that clients must process both the KU and EKU extensions when both are present.

> I'll put it bluntly: Your argument is deeply troubling and I would have
little hesitation arguing for the full and immediate distrust of a CA that
made it, that's how extremely problematic I see it. I appreciate that we're
discussing in the abstract, but I want to emphasize how ardently I reject
this argument when it comes to CAs filing their incident reports, to make
sure they don't point to this thread as if somehow you've made the argument
for them.

For the avoidance of doubt, allow me to state that I'm posting this in an entirely personal capacity :)

> The same logic being applied here would say that a Subscriber certificate,
which had a TLS serverAuth EKU, was not actually a "server" certificate if
the KU is wrong. Worse, however, you'd similarly argue that if the KU *is*
wrong, nothing else about the certificate could be considered misissued,
because it's clearly "not a TLS server certificate". After all, 7.1.2.3(e)
of the BRs only has KU as optional, and 1.1 of the BRs only applies to
certificates "intended" for TLS, and your argument would say KU shows
intent.

This argument doesn't address the situation at hand, namely the interaction between CA certificates, EKU, and KU. If we were discussing OCSP EKU end-entity certificates that lack the digitalSignature KU, then I'd be in full agreement with you. But we're not; we're discussing CA certificates, which contain a set of KUs that restrict the usages of the CA Key Pair, namely the technical inability to sign OCSP responses by lack of the digitalSignature bit.

> At the heart of our disagreement is that you'd like to read something like
4.2.2.2 of RFC 6960, which says "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",
and add a clause "if and only if the KU is consistent". And I can
understand why that'd be appealing, and certainly when we talk about client
usage, why that would be desirable. But much like we talk about scoping
issues, the mere act of including the EKU designates it as a Responder
certificate. If the KUs are wrong, and if clients checked KUs, that would
mitigate some of the harm, but doesn't change the fundamental fact that
it's still been designated, by the CA, as an OCSP Responder. It may not be
useful as one, but it still *is* a responder certificate, and 4.9.9 applies.

Let's break this down:
- RFC 5280 indicates that the digitalSignature KU is required for clients to verify signatures (e.g., OCSP response signatures) using the public key in the certificate
- Mozilla Root Policy allows ocspSigning EKU in subCA certificates alongside other EKUs
- The OCSP nocheck extension directs clients to not perform revocation checking for the certificate

So if a given intermediate certificate has an EKU of serverAuth and ocspSigning:
- If the certificate has the OCSP nocheck extension, then the certificate likely runs afoul of BR 4.9.7 and 4.9.10 as it is irrevocable
- If the certificate does not have the OCSP nocheck extension, then according to your interpretation, it is a misissued OCSP delegated responder and thus runs afoul of BR 4.9.9 due to lack of the nocheck extension

Ignoring the KU, it appears that it is impossible to create a compliant CA certificate, despite it being allowed by Mozilla Policy.

However, if you consider that the digitalSignature KU is required for clients to process OCSP responses per RFC 5280, then a compliant profile that protects RFC 5280-adhering clients from errant OCSP responses would be:

- KU without digitalSignature, which is a technical control that prevents OCSP responses signed using the CA Key Pair from being trusted by compliant clients.
- EKUs of serverAuth and ocspSigning
- No nocheck extension, to allow for revocability of the intermediate

I would argue that certificates that adhere to the above profile are not mis-issued per the relevant policies and provide the proper technical protection (not just stated intent!) to RPs against OCSP responses signed by the CA key pair (assuming, of course, the client implements RFC 5280 correctly). Additionally, such a certificate is revocable.

Thanks,
Corey

[Ryan Sleevi]

On Thu, Jul 2, 2020 at 9:32 PM Corey Bonnell via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> For the avoidance of doubt, allow me to state that I'm posting this in an
> entirely personal capacity :)

:)

> The same logic being applied here would say that a Subscriber certificate,
> which had a TLS serverAuth EKU, was not actually a "server" certificate if
> the KU is wrong. Worse, however, you'd similarly argue that if the KU *is*
> wrong, nothing else about the certificate could be considered misissued,
> because it's clearly "not a TLS server certificate". After all, 7.1.2.3(e)
> of the BRs only has KU as optional, and 1.1 of the BRs only applies to
> certificates "intended" for TLS, and your argument would say KU shows
> intent.
>

> This argument doesn't address the situation at hand, namely the
> interaction between CA certificates, EKU, and KU. If we were discussing
> OCSP EKU end-entity certificates that lack the digitalSignature KU, then
> I'd be in full agreement with you. But we're not; we're discussing CA
> certificates, which contain a set of KUs that restrict the usages of the CA
> Key Pair, namely the technical inability to sign OCSP responses by lack of
> the digitalSignature bit.

I don’t understand why you’re making a distinction as to CA certificates,
which are irrelevant with respect to the Delegated Responder profile. That
is, you’re trying to find a way that it’s compliant, but this introduction
of the CA bit as somehow special doesn’t have any basis, as far as I can
tell.

When you throw that out, it seems we’re in agreement here? If it’s
problematic to have the wrong KU for the EKU with
basicConstraints:CA=FALSE, it’s problematic to have the wrong KU for the
EKU with basicConstraints:CA=TRUE. They’re both restrictions on key usage,
and it doesn’t matter that one is a CA key.

Let's break this down:
> - RFC 5280 indicates that the digitalSignature KU is required for clients
> to verify signatures (e.g., OCSP response signatures) using the public key
> in the certificate
> - Mozilla Root Policy allows ocspSigning EKU in subCA certificates
> alongside other EKUs

Where? It seems you’re reading this as inferred through omission of a
prohibition in Section 5.3, but you’re using it in the remainder of your
argument to argue why it’s proactively allowed.

- The OCSP nocheck extension directs clients to not perform revocation
> checking for the certificate
>
> So if a given intermediate certificate has an EKU of serverAuth and
> ocspSigning:
> - If the certificate has the OCSP nocheck extension, then the certificate
> likely runs afoul of BR 4.9.7 and 4.9.10 as it is irrevocable
> - If the certificate does not have the OCSP nocheck extension, then
> according to your interpretation, it is a misissued OCSP delegated
> responder and thus runs afoul of BR 4.9.9 due to lack of the nocheck
> extension
>
> Ignoring the KU, it appears that it is impossible to create a compliant CA
> certificate, despite it being allowed by Mozilla Policy.

Yes, it’s impossible to create an Issuing CA that has id-kp-OCSPSigning.
That’s not a “bug” or the “gotcha” moment you seem to suggest: it’s the
intended result!

This is ostensibly even clearer in Microsoft’s policy, but I understand
that some want to debate that as well, and I defer to Microsoft to defend
their policies and interpretation.

However, if you consider that the digitalSignature KU is required for
> clients to process OCSP responses per RFC 5280, then a compliant profile
> that protects RFC 5280-adhering clients from errant OCSP responses would be:
>
> - KU without digitalSignature, which is a technical control that prevents
> OCSP responses signed using the CA Key Pair from being trusted by compliant
> clients.
> - EKUs of serverAuth and ocspSigning
> - No nocheck extension, to allow for revocability of the intermediate
>
> I would argue that certificates that adhere to the above profile are not
> mis-issued per the relevant policies and provide the proper technical
> protection (not just stated intent!) to RPs against OCSP responses signed
> by the CA key pair (assuming, of course, the client implements RFC 5280
> correctly). Additionally, such a certificate is revocable.

I can understand why a CA wanting to permit it might argue for this, but
that’s not the status quo today, and not permitted today.

At its heart, it’s another debate about intent: which signals “intent” and
expectations more: the EKU or the KU. You’re seemingly arguing that EKU
with wrong KU nullifies RFC 6960, but that doesn’t hold water. You’re
arguing it should, because an unspecified aspect of EKU handling means that
the CA bit should matter. Yet there’s nothing to support that, because of
course it’s unspecified.

I get the view that says “well, this is how we solved these problems back
then”. We see CAs bring this out regularly with compliance incidents;
internal server names and IP addresses were both manifestations of “well,
it worked, so we assumed it was right”. Some CAs recognized the risk (good
job Sectigo), some CAs recognize the risk (good job DigiCert), and some
want to argue that this is all the clients’ fault, the CA did nothing
wrong, and Denmark smells lovely, what do you mean it there’s an overturned
Durian truck?

But I can’t get the view that says, even in 2020, that a Thing is Not a
Thing, which in this case is a Delegated Responder. Just like I can’t
understand folks who say a Sub-CA is not a Sub-CA if it’s a
Cross-Certificate.

>

[Corey Bonnell]

> I don’t understand why you’re making a distinction as to CA certificates,
which are irrelevant with respect to the Delegated Responder profile. That
is, you’re trying to find a way that it’s compliant, but this introduction
of the CA bit as somehow special doesn’t have any basis, as far as I can
tell.

The argument you're asserting is akin to someone saying that a CA certificate with serverAuth EKU is mis-issued if the subject Common Name is "Super Duper High Assurance Issuing CA", which is not a hostname in preferred DNS syntax. After all, the EKU definition for serverAuth in RFC 5280 states that certificates expressing that EKU value are used for TLS server authentication, and clearly that is a malformed hostname so the certificate can't be used for its intended purpose. In essence, the argument you're presenting applies the end-entity profile definition to the CA certificate profile for that EKU, which doesn't make sense.

> When you throw that out, it seems we’re in agreement here? If it’s
problematic to have the wrong KU for the EKU with
basicConstraints:CA=FALSE, it’s problematic to have the wrong KU for the
EKU with basicConstraints:CA=TRUE. They’re both restrictions on key usage,
and it doesn’t matter that one is a CA key.

End-entity certificates and CA certificates will naturally have different KU values to constrain the allowed usages of the key. Again, the argument being presented here tries to assert that CA certificates need to fit the profile of the end-entity certificate for the corresponding EKU.

>> Let's break this down:
>> - RFC 5280 indicates that the digitalSignature KU is required for clients
>> to verify signatures (e.g., OCSP response signatures) using the public key
>> in the certificate
>> - Mozilla Root Policy allows ocspSigning EKU in subCA certificates
>> alongside other EKUs

> Where? It seems you’re reading this as inferred through omission of a
prohibition in Section 5.3, but you’re using it in the remainder of your
argument to argue why it’s proactively allowed.

Ben's email from last evening [1] clearly stated that Mozilla has allowed ocspSigning alongside other EKUs and the concrete example given was a CA certificate that expresses the serverAuth and ocspSigning EKUs [2]. Notably, this certificate also lacks the digitalSignature KU bit.

>> Ignoring the KU, it appears that it is impossible to create a compliant CA
certificate, despite it being allowed by Mozilla Policy.

> Yes, it’s impossible to create an Issuing CA that has id-kp-OCSPSigning.
That’s not a “bug” or the “gotcha” moment you seem to suggest: it’s the
intended result!

If Mozilla Root Policy has historically allowed this as was stated last evening, then surely there is some way to do it in a compliant manner.

> But I can’t get the view that says, even in 2020, that a Thing is Not a
Thing, which in this case is a Delegated Responder. Just like I can’t
understand folks who say a Sub-CA is not a Sub-CA if it’s a
Cross-Certificate.

I think there's a world of difference between these two cases. In the former case, there are technical controls for certificates used in a RFC 5280 PKI such that a CA certificate that expresses the ocspSigning EKU but no digitalSignature KU bit will not have any OCSP responses created by the CA trusted by clients. In the latter case, I entirely agree with you: the only assurance that a "Cross-Certificate" can't be used to issue end-entity certificates is pinky swears and promises and therefore must be treated as a Sub-CA, because it technically is a Sub-CA.

Thanks,
Corey

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/EzjIkNGfVEE/2WlxGVylBwAJ
[2] https://crt.sh/?id=2472155

[Ryan Sleevi]

On Fri, Jul 3, 2020 at 10:49 PM Corey Bonnell via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> > I don’t understand why you’re making a distinction as to CA certificates,
> which are irrelevant with respect to the Delegated Responder profile. That
> is, you’re trying to find a way that it’s compliant, but this introduction
> of the CA bit as somehow special doesn’t have any basis, as far as I can
> tell.
>

> The argument you're asserting is akin to someone saying that a CA
> certificate with serverAuth EKU is mis-issued if the subject Common Name is
> "Super Duper High Assurance Issuing CA", which is not a hostname in
> preferred DNS syntax. After all, the EKU definition for serverAuth in RFC
> 5280 states that certificates expressing that EKU value are used for TLS
> server authentication, and clearly that is a malformed hostname so the
> certificate can't be used for its intended purpose. In essence, the
> argument you're presenting applies the end-entity profile definition to the
> CA certificate profile for that EKU, which doesn't make sense.
>

I appreciate the comparison, but we both know that it's a flawed one.
You're inventing a distinction - the CA bit - that doesn't exist, within
the BRs or the RFCs.

Nothing in the RFCs specifies the profile you describe for commonName.
That's something the BRs do, and they explicitly do it contingent upon the
CA bit (Subordinate CA vs Subscriber Cert)

You're inventing a fiction that, no doubt, reflected a belief of some CAs
when they did it. But no such distinction exists within the profiles, and
it was, as far as I can tell, only Mozilla, and only in one of the three
verifiers (i.e. not applying to Thunderbird/S/MIME) that took the step to
profile things further.

The distinction you make, about KU, falls apart when you realize the
distinction you're making here, about CAs, is also made up.

> > Where? It seems you’re reading this as inferred through omission of a
> prohibition in Section 5.3, but you’re using it in the remainder of your
> argument to argue why it’s proactively allowed.
>

> Ben's email from last evening [1] clearly stated that Mozilla has allowed
> ocspSigning alongside other EKUs and the concrete example given was a CA
> certificate that expresses the serverAuth and ocspSigning EKUs [2].
> Notably, this certificate also lacks the digitalSignature KU bit.
>

I think this is dangerously close to divination. Mozilla did not chase down
non-compliance. That didn't mean it wasn't non-compliant, just that Mozilla
didn't enforce it, just like Microsoft didn't enforce their policy. That
doesn't mean it was/is allowed by the BRs, and it doesn't mean that the
non-compliance doesn't pose serious security risk.

> > But I can’t get the view that says, even in 2020, that a Thing is Not a
> Thing, which in this case is a Delegated Responder. Just like I can’t
> understand folks who say a Sub-CA is not a Sub-CA if it’s a
> Cross-Certificate.
>

> I think there's a world of difference between these two cases. In the
> former case, there are technical controls for certificates used in a RFC
> 5280 PKI such that a CA certificate that expresses the ocspSigning EKU but
> no digitalSignature KU bit will not have any OCSP responses created by the
> CA trusted by clients. In the latter case, I entirely agree with you: the
> only assurance that a "Cross-Certificate" can't be used to issue end-entity
> certificates is pinky swears and promises and therefore must be treated as
> a Sub-CA, because it technically is a Sub-CA.


"will not have any OCSP responses created by the CA trusted by clients". I

can literally show you the clients that do trust this, including Major
Ones. Even Mozilla doesn't check the Key Usage -
https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/mozpkix/lib/pkixocsp.cpp#127


We've already shown, however, that your argument about the "invalid" key
usage is still a Mozilla Program Violation, in that it violates what you're
declaring a defense mechanism (RFC 5280) by including an EKU not consistent
with the extensions. This isn't a question about the BRs allowing such
violations: they make no such statements.

However, I'm more concerned by your latest message, in which you dismiss
the very real security concern. That's something I think truly is dangerous
here, especially for CAs following, because you're simply not correct to
dismiss the concern. I also don't think it's correct to come up with a
fiction that, because something not written in any spec (that responder
certs are CA:FALSE) makes it OK to include the EKU to facilitate another
behaviour not written in any spec (EKU chaining), and to do so ignoring
both the RFC's profile (requiring KU) and the BRs profile (requiring
nocheck). You're just making things up now.

[Tofu Kobe]

Dear Mr. Wilson,

Could you please share the risk assessment that you have received from
Mr. Sleevi?
I believe it would be very useful for the CAs to understand the gravity
of the issue.

Sincerely yours,
T.K. (No hat)

On 7/4/2020 12:23 PM, Ryan Sleevi via dev-security-policy wrote:

> On Fri, Jul 3, 2020 at 10:49 PM Corey Bonnell via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>>> I don’t understand why you’re making a distinction as to CA certificates,
>> which are irrelevant with respect to the Delegated Responder profile. That
>> is, you’re trying to find a way that it’s compliant, but this introduction
>> of the CA bit as somehow special doesn’t have any basis, as far as I can
>> tell.
>>

>> The argument you're asserting is akin to someone saying that a CA
>> certificate with serverAuth EKU is mis-issued if the subject Common Name is
>> "Super Duper High Assurance Issuing CA", which is not a hostname in
>> preferred DNS syntax. After all, the EKU definition for serverAuth in RFC
>> 5280 states that certificates expressing that EKU value are used for TLS
>> server authentication, and clearly that is a malformed hostname so the
>> certificate can't be used for its intended purpose. In essence, the
>> argument you're presenting applies the end-entity profile definition to the
>> CA certificate profile for that EKU, which doesn't make sense.
>>
> I appreciate the comparison, but we both know that it's a flawed one.
> You're inventing a distinction - the CA bit - that doesn't exist, within
> the BRs or the RFCs.
>
> Nothing in the RFCs specifies the profile you describe for commonName.
> That's something the BRs do, and they explicitly do it contingent upon the
> CA bit (Subordinate CA vs Subscriber Cert)
>
> You're inventing a fiction that, no doubt, reflected a belief of some CAs
> when they did it. But no such distinction exists within the profiles, and
> it was, as far as I can tell, only Mozilla, and only in one of the three
> verifiers (i.e. not applying to Thunderbird/S/MIME) that took the step to
> profile things further.
>
> The distinction you make, about KU, falls apart when you realize the
> distinction you're making here, about CAs, is also made up.
>
>

>>> Where? It seems you’re reading this as inferred through omission of a
>> prohibition in Section 5.3, but you’re using it in the remainder of your
>> argument to argue why it’s proactively allowed.
>>

>> Ben's email from last evening [1] clearly stated that Mozilla has allowed
>> ocspSigning alongside other EKUs and the concrete example given was a CA
>> certificate that expresses the serverAuth and ocspSigning EKUs [2].
>> Notably, this certificate also lacks the digitalSignature KU bit.
>>
> I think this is dangerously close to divination. Mozilla did not chase down
> non-compliance. That didn't mean it wasn't non-compliant, just that Mozilla
> didn't enforce it, just like Microsoft didn't enforce their policy. That
> doesn't mean it was/is allowed by the BRs, and it doesn't mean that the
> non-compliance doesn't pose serious security risk.
>
>

>>> But I can’t get the view that says, even in 2020, that a Thing is Not a
>> Thing, which in this case is a Delegated Responder. Just like I can’t
>> understand folks who say a Sub-CA is not a Sub-CA if it’s a
>> Cross-Certificate.
>>

[Corey Bonnell]

> Nothing in the RFCs specifies the profile you describe for commonName. That's something the BRs do, and they explicitly do it contingent upon the CA bit (Subordinate CA vs Subscriber Cert)

I mean, that’s exactly how SSL/TLS hostname verification is done. This profile of serverAuth certificates regarding subject CN is explicitly specified in RFC 6125 and other application-specific protocol specifications (such as RFC 2818), not just in the BRs.

> The distinction you make, about KU, falls apart when you realize the distinction you're making here, about CAs, is also made up.

A CA certificate expressing solely the certSign and crlSign KU bits is expressing through technical constraints it’s only an issuer of certificates and CRLs for issued certificates that share the same EKU value and cannot be used for any other purpose, such as OCSP response generation. I don’t see how this concept is made up.

> However, I'm more concerned by your latest message, in which you dismiss the very real security concern. That's something I think truly is dangerous here, especially for CAs following, because you're simply not correct to dismiss the concern.

I’m not dismissing the security concern at all and I’m not sure how you arrived to the conclusion that I was. My understanding was that we are discussing the relevant standards and policies; the security issue is obvious. As Jeremy said above, discussion of the relevant policies and potential improvements are also important. The intention of this and previous messages is to point out is that the security issue has not been precipitated by policy violations/mis-issuance in at least a subset of the CA certificates involved and that clarifications and policy improvements are sorely needed to provide clarify to better prevent a recurrence of the security issue.

Thanks,
Corey
________________________________
From: Ryan Sleevi <ry...@sleevi.com>
Sent: Friday, July 3, 2020 11:23:53 PM
To: Corey Bonnell <cbon...@outlook.com>
Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>

Subject: Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

On Fri, Jul 3, 2020 at 10:49 PM Corey Bonnell via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:
> I don’t understand why you’re making a distinction as to CA certificates,
which are irrelevant with respect to the Delegated Responder profile. That
is, you’re trying to find a way that it’s compliant, but this introduction
of the CA bit as somehow special doesn’t have any basis, as far as I can
tell.

The argument you're asserting is akin to someone saying that a CA certificate with serverAuth EKU is mis-issued if the subject Common Name is "Super Duper High Assurance Issuing CA", which is not a hostname in preferred DNS syntax. After all, the EKU definition for serverAuth in RFC 5280 states that certificates expressing that EKU value are used for TLS server authentication, and clearly that is a malformed hostname so the certificate can't be used for its intended purpose. In essence, the argument you're presenting applies the end-entity profile definition to the CA certificate profile for that EKU, which doesn't make sense.

I appreciate the comparison, but we both know that it's a flawed one. You're inventing a distinction - the CA bit - that doesn't exist, within the BRs or the RFCs.

Nothing in the RFCs specifies the profile you describe for commonName. That's something the BRs do, and they explicitly do it contingent upon the CA bit (Subordinate CA vs Subscriber Cert)

You're inventing a fiction that, no doubt, reflected a belief of some CAs when they did it. But no such distinction exists within the profiles, and it was, as far as I can tell, only Mozilla, and only in one of the three verifiers (i.e. not applying to Thunderbird/S/MIME) that took the step to profile things further.

The distinction you make, about KU, falls apart when you realize the distinction you're making here, about CAs, is also made up.

> Where? It seems you’re reading this as inferred through omission of a
prohibition in Section 5.3, but you’re using it in the remainder of your
argument to argue why it’s proactively allowed.

Ben's email from last evening [1] clearly stated that Mozilla has allowed ocspSigning alongside other EKUs and the concrete example given was a CA certificate that expresses the serverAuth and ocspSigning EKUs [2]. Notably, this certificate also lacks the digitalSignature KU bit.

I think this is dangerously close to divination. Mozilla did not chase down non-compliance. That didn't mean it wasn't non-compliant, just that Mozilla didn't enforce it, just like Microsoft didn't enforce their policy. That doesn't mean it was/is allowed by the BRs, and it doesn't mean that the non-compliance doesn't pose serious security risk.

> But I can’t get the view that says, even in 2020, that a Thing is Not a
Thing, which in this case is a Delegated Responder. Just like I can’t
understand folks who say a Sub-CA is not a Sub-CA if it’s a
Cross-Certificate.

I think there's a world of difference between these two cases. In the former case, there are technical controls for certificates used in a RFC 5280 PKI such that a CA certificate that expresses the ocspSigning EKU but no digitalSignature KU bit will not have any OCSP responses created by the CA trusted by clients. In the latter case, I entirely agree with you: the only assurance that a "Cross-Certificate" can't be used to issue end-entity certificates is pinky swears and promises and therefore must be treated as a Sub-CA, because it technically is a Sub-CA.

"will not have any OCSP responses created by the CA trusted by clients". I can literally show you the clients that do trust this, including Major Ones. Even Mozilla doesn't check the Key Usage - https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/mozpkix/lib/pkixocsp.cpp#127<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdxr.mozilla.org%2Fmozilla-central%2Fsource%2Fsecurity%2Fnss%2Flib%2Fmozpkix%2Flib%2Fpkixocsp.cpp%23127&data=02%7C01%7C%7C6dd1283f827d49a3b08508d81fc9b48d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637294298458085202&sdata=F0b%2BP%2BtGD3YFNEB4JPgJNzE90tFkFqAIyg9JmzNMU9Y%3D&reserved=0>

[Ryan Sleevi]

On Sun, Jul 5, 2020 at 4:35 PM Corey Bonnell <cbon...@outlook.com> wrote:

>
> > Nothing in the RFCs specifies the profile you describe for commonName.
> That's something the BRs do, and they explicitly do it contingent upon the
> CA bit (Subordinate CA vs Subscriber Cert)
>
> I mean, that’s exactly how SSL/TLS hostname verification is done. This
> profile of serverAuth certificates regarding subject CN is explicitly
> specified in RFC 6125 and other application-specific protocol
> specifications (such as RFC 2818), not just in the BRs.
>
> > The distinction you make, about KU, falls apart when you realize the
> distinction you're making here, about CAs, is also made up.
>
> A CA certificate expressing solely the certSign and crlSign KU bits is
> expressing through technical constraints it’s only an issuer of
> certificates and CRLs for issued certificates that share the same EKU value
> and cannot be used for any other purpose, such as OCSP response generation.
> I don’t see how this concept is made up.
>
> > However, I'm more concerned by your latest message, in which you dismiss
> the very real security concern. That's something I think truly is dangerous
> here, especially for CAs following, because you're simply not correct to
> dismiss the concern.
>
> I’m not dismissing the security concern at all and I’m not sure how you
> arrived to the conclusion that I was.
>

You've repeatedly, incorrectly, misleadingly stated certain things "cannot"
happen, on the basis of unsupported interpretations that show they can
indeed. I can understand if you believe they "should not", if clients
worked the way you envision, but simply stating they cannot, ergo there is
no issue, is at best false, and at worst, outright dismissive of the
security concerns, because as you say, they "cannot" happen.

> My understanding was that we are discussing the relevant standards and
> policies; the security issue is obvious. As Jeremy said above, discussion
> of the relevant policies and potential improvements are also important. The
> intention of this and previous messages is to point out is that the
> security issue has not been precipitated by policy violations/mis-issuance
> in at least a subset of the CA certificates involved and that
> clarifications and policy improvements are sorely needed to provide clarify
> to better prevent a recurrence of the security issue.
>

Hey Corey,

This is my last message on this, because I'm afraid we're not making any
useful progress on this. As I've said, you've continued to make things up
to support your interpretation, and I don't think there's much left I can
say that good-faith engages on this. I'm not going to debate this further,
because the plain and simple rule is that it is a violation of the BRs,
full stop. Continuing to invent requirements to try to make it sound like
you're making a compelling argument is, unfortunately, not productive.

Your most recent message continues this demonstration. When you make such
statements like "cannot be used", despite clearly being shown they can be
used, you do a great disservice to your argument, but an even greater
disservice to CAs affected by this, who might be confused as to think
you're saying the security concerns are non-existent.

The core of your current argument rests on two fictions that you've
invented, and any CA that were to rely on such fictions would, in my mind,
be so dangerously bad-faith as to warrant distrust.

Corey's Fictional/Non-Existent Specification 1) That the keyUsage bit being
incorrect makes this "something other than" an OCSP Responder, and ergo not
misissued.

As mentioned before, this is a dangerous fiction to invent. It's the same
fiction that would argue that an id-kp-serverAuth certificate, with a KU of
certSign, a basicConstraints CA:FALSE, and a SAN of "google.com" is
'clearly' not a misissuance because the keyUsage proves it's not a server
certificate and proves it can't be used for TLS. As I said, this fiction
invents a new set of requirements that are not placed within the BRs, to
suggest that keyUsage is somehow part of technically constraining a profile.

The solution for this has already been known and identified: A specific
profile of certificates in which any use of any extension outside of the
allowed semantics is misissuance. Much like was done for signature
algorithms, that appears to be the only way to avoid the problem of CAs not
reading the specifications and understanding their interplay.

Corey's Fictional/Non-Existent Specification 2) That despite no RFC saying
otherwise, and the BRs certainly not saying so, that the presence of
id-kp-OCSPSigning within a CA:TRUE certificate is somehow distinct from
within a CA:FALSE certificate

This tries to fit the concept of EKU chaining semantics as if to counteract
those of RFC 6960. At best, you're reading RFC 5280's 4.2.1.12's "In
general, this extension will appear only in end entity certificates" as a
statement that the semantics are, at best, undefined for a CA:TRUE, and
ergo all of the semantics defined within that section, or any subsequent
RFC, are relevant iff CA:FALSE. Further, in doing so, you're arguing both
that the semantics for the KU matter (as part of Corey's
Fictional/Non-Existent Specification 1) and that the clause in 4.2.1.12 "If

a certificate contains both a key usage extension and an extended key usage

extension" doesn't matter, at least with respect to Mozilla Policy, because
of this hypothetical duality based on the CA bit.

Here again, the solution is simple: an explicit profile on responder
certificates to make it clear "What is a responder" and that any other
interpretations, outside of this, are misissued.

Both of these made up interpretations are not ones that are worth any
further time debating, because we continue to go around in circles where
you won't acknowledge that you simply made them up.

I don't think our discussion has, in any meaningful sense, improved the
policy issues, especially when they rest on made-up fictions. That part
already has a clear solution, one which was already proposed as part of
SC31 and now shifting to the "Cleanups and Clarifications" ballot to
follow. You're more than welcome to engage on the precise policy language,
to see whether I have sufficiently and adequately addressed your concerns,
but these e-mails have not helped improve those proposals in any way. At
the end of the day, there will always be bad-faith attempts to reinterpret
the requirements in order to fit a narrative that a CA has not misissued.
While they are interesting attempts at creative writing new fiction, they
aren't useful in providing concrete guidance for CAs.