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

[Tofu Kobe via dev-security-policy]

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-security-policy@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). 

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

[Ryan Sleevi via dev-security-policy]

On Fri, Jul 3, 2020 at 10:49 PM Corey Bonnell via dev-security-policy <
dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Corey Bonnell via dev-security-policy]

> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 2, 2020 at 9:32 PM Corey Bonnell via dev-security-policy <
dev-security-policy@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 

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

[Corey Bonnell via dev-security-policy]

>> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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 
Sent: Thursday, July 2, 2020 11:51 AM
To: Jeremy Rowley 
Cc: Mozilla 
Subject: Re: Question about the issuance of OCSP Responder Certificates by 
technically constrained CAs

On Thu, Jul 2, 2020 at 1:33 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 2, 2020 at 1:33 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, July 2, 2020 11:05 AM
To: Rob Stradling 
Cc: Mozilla 
Subject: Re: Question about the issuance of OCSP Responder Certificates by 
technically constrained CAs

On Thu, Jul 2, 2020 at 12:51 PM Rob Stradling via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> 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:
> 
> >> 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-OCSPSigningOBJECT 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!)
>

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 2, 2020 at 12:51 PM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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:
> 
> >> 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-OCSPSigningOBJECT 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!)
>

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Rob Stradling via dev-security-policy]

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:



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-OCSPSigningOBJECT 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

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

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

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 2, 2020 at 11:36 AM Corey Bonnell 
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Corey Bonnell via dev-security-policy]

>> 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  
Sent: Thursday, July 2, 2020 10:59 AM
To: Corey Bonnell 
Cc: r...@sleevi.com; Neil Dunbar ; 
mozilla-dev-security-pol...@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 mailto:cbonn...@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-OCSPSigningOBJECT 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 

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

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 2, 2020 at 10:47 AM Corey Bonnell 
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-OCSPSigningOBJECT 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Corey Bonnell via dev-security-policy]

> 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-OCSPSigningOBJECT 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  
Sent: Thursday, July 2, 2020 9:57 AM
To: Corey Bonnell 
Cc: r...@sleevi.com; Neil Dunbar ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Question about the issuance of OCSP Responder Certificates by 
technically constrained CAs

 

 

 

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

(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?

 

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”. 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 2, 2020 at 9:36 AM Corey Bonnell 
wrote:

> (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?
>

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”.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Corey Bonnell via dev-security-policy]

(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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 2, 2020 at 8:44 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> 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!


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.

>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Neil Dunbar via dev-security-policy]

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

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

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

[Corey Bonnell via dev-security-policy]

> 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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Peter Mate Erdosi via dev-security-policy]

"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 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.
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> 

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

[Rob Stradling via dev-security-policy]

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 

Sent: 02 July 2020 12:38
To: 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 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.

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

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

[Pedro Fuentes via dev-security-policy]

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

El jueves, 2 de julio de 2020, 13:38:48 (UTC+2), douglas...@gmail.com  escribió:
> 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
> 
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[douglas.beattie--- via dev-security-policy]

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 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.

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

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

[Santhan via dev-security-policy]

On Tuesday, September 10, 2019 at 6:53:47 AM UTC-7, Robin Alden wrote:
> > 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

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Robin Alden via dev-security-policy]

> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

On 04/09/2019 17:14, Ryan Sleevi wrote:
> On Wed, Sep 4, 2019 at 11:06 AM Ben Wilson  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.
> 

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 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

On Wed, Sep 4, 2019 at 11:06 AM Ben Wilson  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ben Wilson via dev-security-policy]

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?

-Original Message-
From: dev-security-policy  On
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Wednesday, September 4, 2019 9:01 AM
To: perd...@gmail.com
Cc: mozilla-dev-security-policy

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

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/fd891e83a7cd54038b0bcebb3ab85b68
18e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#819-888
,
with the most salient logic at
https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b68
18e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#873-884
,
although the explanation in
https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b68
18e2550e/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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

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 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Peter Mate, Erdosi via dev-security-policy]

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