Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Filippo Valsorda via dev-security-policy]

2020-07-02 10:40 GMT-04:00 Ryan Sleevi via dev-security-policy 
:
> On Thu, Jul 2, 2020 at 10:34 AM Paul van Brouwershaven via
> dev-security-policy  wrote:
> 
> > I did do some testing on EKU chaining in Go, but from my understand this
> > works the same for Microsoft:
> >
> 
> Go has a bug https://twitter.com/FiloSottile/status/1278501854306095104

Yep. In fact, Go simply doesn't have an OCSP verifier. We should fix that! I 
filed an issue: https://golang.org/issues/40017 


The pieces are there (OCSP request serialization and response parsing, 
signature verification, a chain builder) but the logic stringing them together 
is not. That includes building the chain without requesting the EKU up the 
path, and then checking the EKU only on the Responder itself.

It's unfortunate that the Mozilla requirement (that the Responder must be an 
EE) is not standard, because that would have allowed the OCSP EKU to work like 
any other, nested up the chain, but that's just not how it works and it's too 
late to change, so it has to be special-cased out of the chain nesting 
requirement, or it wouldn't be possible to mint an Intermediate that can in 
turn mint Responders, without making the Intermediate a Responder itself.
___
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: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Ryan Sleevi via dev-security-policy]

Thanks Tim.

It’s deeply reassuring to see DigiCert tackling this problem responsibly
and head-on.

And thank you for particularly calling attention to the fact that blindly
adding id-pkix-ocsp-nocheck to these ICAs introduces worse security
problems. This is why RFC 6960 warns so specifically on this.

What does a robust design look like?
- Omit the EKU for ICAs. You can work around the ADCS issue using Sectigo’s
guidance.
- For your actual delegated responders, omitting OCSP URLs can help “some”
clients, but not all. A sensible minimum profile is:
  - basicConstraints:CA=FALSE
  - extKeyUsage=id-kp-OCSPSigning (and ONLY that)
  - validity period of 90 days or less (30?)
  - id-pkix-ocsp-nocheck

basicConstraints is to guarantee it works with Firefox. EKU so it’s a
delegated responder (and only that). Short lived because nocheck means it’s
high risk.

Invariably, any profile (e.g. in the CABForum) would also need to ensure
that these keys are protected to the same assurance level as CA keys,
because of the similar function they pose. I had previously proposed both
the lifetime and protection requirements in CABF, but met significant
opposition. This still lives in
https://github.com/sleevi/cabforum-docs/pull/2/files , although several of
these changes have found their way in through other ballots, such as SC31
in the SCWG if the CABF.

On Thu, Jul 2, 2020 at 6:37 PM Tim Hollebeek 
wrote:

> So, from our perspective, the security implications are the most important
> here.
> We understand them, and even in the absence of any compliance obligations
> they
> would constitute an unacceptable risk to trustworthiness of our OCSP
> responses,
> so we have already begun the process of replacing the ICAs we are
> responsible for.
> There are already several key ceremonies scheduled and they will continue
> through
> the holiday weekend.  We're prioritizing the ICAs that are under the
> control of third
> parties and/or outside our primary data centers, as they pose the most
> risk.  We are
> actively working to mitigate internal ICAs as well.  Expect to see
> revocations start
> happening within the next day or two.
>
> I understand the attraction of using a BR compliance issue to attract
> attention to
> this issue, but honestly, that shouldn't be necessary.  The BRs don't
> really adequately
> address the risks of the OCSPSigning EKU, and there's certainly lots of
> room for
> improvement there.  I think, especially in the short term, it is more
> important to
> focus on how to mitigate the security risks and remove the inappropriate
> EKU from
> the affected ICAs.  We can fix the BRs later.
>
> It's also important to note that, much like SHA-1, this issue doesn't
> respect the
> normal assumptions about certificate hierarchies.  Non-TLS ICAs can have a
> significant
> impact on their TLS-enabled siblings.  This means that CA review needs to
> extend
> beyond the certificates that would traditionally be in scope for the BRs.
>
> I would also caution CAs to carefully analyze the implications before
> blindly adding the
> pkix-ocsp-nocheck extension to their ICAs.  That might fix the compliance
> issue,
> but in the grand scheme of things probably makes the problem worse, as ICAs
> have fairly long lifetimes, and doing so effectively makes the inadvertent
> delegated
> responder certificate unrevokable.  So while the compliance problems might
> be
> fixed, it makes resolving the security issues much more challenging.
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy  >
> > On Behalf Of Ryan Sleevi via dev-security-policy
> > Sent: Thursday, July 2, 2020 12:31 AM
> > To: Peter Gutmann 
> > Cc: r...@sleevi.com; Mozilla  > pol...@lists.mozilla.org>
> > Subject: Re: SECURITY RELEVANT FOR CAs: The curious case of the
> > Dangerous Delegated Responder Cert
> >
> > On Wed, Jul 1, 2020 at 11:48 PM Peter Gutmann
> > 
> > wrote:
> >
> > > Ryan Sleevi via dev-security-policy
> > > 
> > > writes:
> > >
> > > >Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
> > > include
> > > >an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP Delegated
> > > >Responder within Section 4.2.2.2 as indicated by the presence of the
> > > id-kp-
> > > >OCSPSigning as an EKU.
> > >
> > > Unless I've misread your message, the problem isn't the presence or
> > > not of a nocheck extension but the invalid presence of an OCSP EKU:
> > >
> > > >I've flagged this as a SECURITY matter [...] the Issuing CA has
> > > >delegated
> > > the
> > > >ability to mint arbitrary OCSP responses to this third-party
> > >
> > > So the problem would be the presence of the OCSP EKU when it shouldn't
> > > be there, not the absence of the nocheck extension.
> >
> >
> > Not quite. It’s both.
> >
> > The BR violation is caused by the lack of the extension.
> >
> > The security issue is caused by the presence of the EKU.
> >
> > However, since some CAs only view things through the lens of BR/program
> > violations, 

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 2, 2020 at 7:13 PM Ben Wilson  wrote:

> We are concerned that revoking these impacted intermediate certificates
> within 7 days could cause more damage to the ecosystem than is warranted
> for this particular problem. Therefore, Mozilla does not plan to hold CAs
> to the BR requirement to revoke these certificates within 7 days. However,
> an additional Incident Report for delayed revocation will still be
> required, as per our documented process[2].  We want to work with CAs to
> identify a path forward, which includes determining a reasonable timeline
> and approach to replacing the certificates that incorrectly have the
> id-kp-OCSPSigning EKU (and performing key destruction for them).
>

I'm not sure I understand this. The measurement is "damage to the
ecosystem", but the justification is "Firefox is protected, even though
many others are not" (e.g. OpenSSL-derived systems, AFAICT), because
AFAICT, Firefox does a non-standard (but quite reasonable) thing.

I can totally appreciate the answer "The risk to Mozilla is low", but this
response seems... different? It also seems to place CAs that adhere to
4.9.1.2, because they designed their systems robustly, at greater
disadvantage from those that did not, and seems like it only encourages the
problem to get worse over time, not better. Regardless, I do hope that any
delay for revocation is not treated as a "mitigate the EKU incident", but
rather more specifically, "what is your plan to ensure every Sub-CA able to
be revoked as required by 4.9.1.2", which almost invariably means
automating certificate issuance and regularly rotating intermediates. If we
continue to allow CAs to place Mozilla, or broadly, browsers, as somehow
responsible for the consequences of the CA's design decisions, things will
only get worse.

Setting aside the security risk factors, which understandably for Mozilla
are seen as low, at its core, this is a design issue for any CA that can't
or doesn't meet the obligations they warranted Mozilla, and the broader
community, that they would meet. Getting to a path where this design issue,
this lack of agility, is remediated is essential, not just in the "oh no,
what if the key is compromised" risk, but within the broader "how do we
have an agile ecosystem?" Weak entropy with serial numbers "should" have
been the wake-up call on investing in this.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Ben Wilson via dev-security-policy]

All,


Thank you to Ryan for identifying this problem, and to all of you who are
earnestly investigating what this problem means and the impact to your CA
hierarchies. Mozilla::pkix requires that an OCSP responder certificate be
an end entity certificate, so we believe that Firefox and Thunderbird are
not impacted by this problem. Historically, as per
https://bugzilla.mozilla.org/show_bug.cgi?id=991209#c10, Mozilla has
allowed CA certificates to have the OCSP signing EKU because some CAs
reported that some Microsoft server software required CA certificates to
have the id-kp-OCSPSigning EKU.

The comments in the code[1] say

// When validating anything other than an delegated OCSP signing cert,

// reject any cert that also claims to be an OCSP responder, because such

// a cert does not make sense. For example, if an SSL certificate were to

// assert id-kp-OCSPSigning then it could sign OCSP responses for itself,

// if not for this check.

// That said, we accept CA certificates with id-kp-OCSPSigning because

// some CAs in Mozilla's CA program have issued such intermediate

// certificates, and because some CAs have reported some Microsoft server

// software wrongly requires CA certificates to have id-kp-OCSPSigning.

// Allowing this exception does not cause any security issues because we

// require delegated OCSP response signing certificates to be end-entity

// certificates.

Additionally, as you all know, Firefox uses OneCRL for checking the
revocation status of intermediate certificates, so as long as the revoked
intermediate certificate is in OneCRL, the third-party would not be able to
“unrevoke” their certificate (for Firefox). Therefore, Mozilla does not
need the certificates that incorrectly have the id-kp-OCSPSigning EKU to be
revoked within the next 7 days, as per section 4.9.1.2 of the BRs.

However, as Ryan has pointed out in this thread, others may still have risk
because they may not have a OneCRL equivalent, or they may have certificate
verification implementations that behave differently than mozilla::pkix in
regards to processing OCSP responder certificates. Therefore, it is
important to identify a path forward to resolve the security risk that this
problem causes to the ecosystem.

We are concerned that revoking these impacted intermediate certificates
within 7 days could cause more damage to the ecosystem than is warranted
for this particular problem. Therefore, Mozilla does not plan to hold CAs
to the BR requirement to revoke these certificates within 7 days. However,
an additional Incident Report for delayed revocation will still be
required, as per our documented process[2].  We want to work with CAs to
identify a path forward, which includes determining a reasonable timeline
and approach to replacing the certificates that incorrectly have the
id-kp-OCSPSigning EKU (and performing key destruction for them).

Therefore, we are looking forward to your continued input in this
discussion about the proper response for CAs to take to resolve the
security risks caused by this problem, and ensure that this problem is not
repeated in future certificates.  We also look forward to your suggestions
on how we can improve OCSP responder requirements in Mozilla’s Root Store
Policy, and to your continued involvement in the CA/Browser Forum to
improve the BRs.

Thanks,


Ben

[1]
https://dxr.mozilla.org/mozilla-central/rev/c68fe15a81fc2dc9fc5765f3be2573519c09b6c1/security/nss/lib/mozpkix/lib/pkixcheck.cpp#858-869

[2] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation


On Wed, Jul 1, 2020 at 3:06 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I've created a new batch of certificates that violate 4.9.9 of the BRs,
> which was introduced with the first version of the Baseline Requirements as
> a MUST. This is https://misissued.com/batch/138/
>
> A quick inspection among the affected CAs include O fields of: QuoVadis,
> GlobalSign, Digicert, HARICA, Certinomis, AS Sertifitseeimiskeskus,
> Actalis, Atos, AC Camerfirma, SECOM, T-Systems, WISeKey, SCEE, and CNNIC.
>
> Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
> include an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP
> Delegated Responder within Section 4.2.2.2 as indicated by the presence of
> the id-kp-OCSPSigning as an EKU.
>
> These certificates lack the necessary extension, and as such, violate the
> BRs. As the vast majority of these were issued on-or-after 2013-02-01, the
> Effective Date of Mozilla Root CA Policy v2.1, these are misissued. You
> could also consider the effective date as 2013-05-15, described later in
> [1] , without changing the results.
>
> This batch is NOT comprehensive. According to crt.sh, there are
> approximately 293 certificates that meet the criteria of "issued by a
> Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without
> pkix-nocheck". misissued.com had some issues with parsing some of these
> 

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Pedro Fuentes via dev-security-policy]

Hello Ryan,
I’m fully understanding your argumentative line, but I’d still have a question 
for you:

Does the operator of a root and it’s hierarchy have the right to delegate OCSP 
responses to its own responders?

If your answer is “No”, then I don’t have anything else to say, but if your 
answer is “Yes”, then I’ll be having still a hard time to see the security risk 
derived of this issue. 

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

RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Tim Hollebeek via dev-security-policy]

So, from our perspective, the security implications are the most important here.
We understand them, and even in the absence of any compliance obligations they
would constitute an unacceptable risk to trustworthiness of our OCSP responses,
so we have already begun the process of replacing the ICAs we are responsible 
for.
There are already several key ceremonies scheduled and they will continue 
through
the holiday weekend.  We're prioritizing the ICAs that are under the control of 
third 
parties and/or outside our primary data centers, as they pose the most risk.  
We are
actively working to mitigate internal ICAs as well.  Expect to see revocations 
start
happening within the next day or two.

I understand the attraction of using a BR compliance issue to attract attention 
to
this issue, but honestly, that shouldn't be necessary.  The BRs don't really 
adequately
address the risks of the OCSPSigning EKU, and there's certainly lots of room for
improvement there.  I think, especially in the short term, it is more important 
to
focus on how to mitigate the security risks and remove the inappropriate EKU 
from
the affected ICAs.  We can fix the BRs later.

It's also important to note that, much like SHA-1, this issue doesn't respect 
the 
normal assumptions about certificate hierarchies.  Non-TLS ICAs can have a 
significant
impact on their TLS-enabled siblings.  This means that CA review needs to extend
beyond the certificates that would traditionally be in scope for the BRs.

I would also caution CAs to carefully analyze the implications before blindly 
adding the
pkix-ocsp-nocheck extension to their ICAs.  That might fix the compliance issue,
but in the grand scheme of things probably makes the problem worse, as ICAs
have fairly long lifetimes, and doing so effectively makes the inadvertent 
delegated
responder certificate unrevokable.  So while the compliance problems might be
fixed, it makes resolving the security issues much more challenging.

-Tim

> -Original Message-
> From: dev-security-policy 
> On Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Thursday, July 2, 2020 12:31 AM
> To: Peter Gutmann 
> Cc: r...@sleevi.com; Mozilla  pol...@lists.mozilla.org>
> Subject: Re: SECURITY RELEVANT FOR CAs: The curious case of the
> Dangerous Delegated Responder Cert
> 
> On Wed, Jul 1, 2020 at 11:48 PM Peter Gutmann
> 
> wrote:
> 
> > Ryan Sleevi via dev-security-policy
> > 
> > writes:
> >
> > >Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
> > include
> > >an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP Delegated
> > >Responder within Section 4.2.2.2 as indicated by the presence of the
> > id-kp-
> > >OCSPSigning as an EKU.
> >
> > Unless I've misread your message, the problem isn't the presence or
> > not of a nocheck extension but the invalid presence of an OCSP EKU:
> >
> > >I've flagged this as a SECURITY matter [...] the Issuing CA has
> > >delegated
> > the
> > >ability to mint arbitrary OCSP responses to this third-party
> >
> > So the problem would be the presence of the OCSP EKU when it shouldn't
> > be there, not the absence of the nocheck extension.
> 
> 
> Not quite. It’s both.
> 
> The BR violation is caused by the lack of the extension.
> 
> The security issue is caused by the presence of the EKU.
> 
> However, since some CAs only view things through the lens of BR/program
> violations, despite the sizable security risk they pose, the compliance 
> incident
> is what is tracked. The fact that it’s security relevant is provided so that 
> CAs
> understand that revocation is necessary, and that it’s also not sufficient,
> because of how dangerous the issue is.
> ___
> 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: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 2, 2020 at 6:05 PM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I understand your rational, but my point is that this is happening in the
> same infrastructure where the whole PKI is operated, and under the
> responsibility of the same operator of the Root. In my understanding the
> operator of the Root has full rights to do delegated OCSP responses if
> those responses are produced by its own OCSP responders.
>
> I'm failing to see what is the main problem you don't consider solved. As
> per your own dissertations in the related posts, there are two issues:
>
> 1. The certificate contains incorrect extensions, so it's a misissuance.
> This is solved by revoking the certificate, and this is done not only
> internally in the PKI, but also in OneCRL.
>

This solves *nothing* for anyone not using OneCRL. It doesn't meet the
obligations the CA warranted within its CP/CPS. It doesn't meet the BRs. It
simply "shifts" risk onto everyone else in the ecosystem, and that's a
grossly negligent and irresponsible thing to do.

"Revoking the certificate" is the minimum bar, which is already a promise
the CA made, to everyone who decides to trust that CA, that they will do
within 7 days. But it doesn't mitigate the risk.


> 2. The operator of the SubCA could produce improper revocation responses,
> so this is a security risk. This risk is already difficult to find if the
> operator of the subCA is the same operator of the Root... If such entity
> wants to do a wrongdoing, there are far easier ways to do it, than
> overcomplicated things like unrevoking its own subCA...
>
> Sorry, but I don't see the likeliness of the risks you evoke... I see the
> potential risk in externally operated CAs, but not here.


The risk is just the same! As a CA, I can understand you would say "Surely,
we would never do anything nefarious", but as a member of the community,
why should we trust what you say? Why would the risk be any different with
externally operated CAs? After all, they're audited to, like roots,
shouldn't the risk be the same? Of course you'd realize that no, they're
not the same, because the CA has no way of truly knowing the sub-CA is
being nefarious. The same is true for the Browser trusting the root: it has
no way of knowing you're not being nefarious.

Look, we've had Root CAs that have actively lied in this Forum,
misrepresenting things to the community they later admitted they knew were
false, and had previously been an otherwise CA in good standing (or at
least, no worse standing than other CAs). A CA is a CA, and the risk is
treated the same.

The line of argument being pursued here is a bit like saying "If no one
abuses this, what's the harm?" I've already shown how any attempt to
actually verify it's not abused ends up just shifting whatever cost onto
Relying Parties, when it's the CA and the Subscribers that should bear the
cost, because it's the CA that screwed up. I simply can't see how "just
trust us" is better than objective verification, especially when "just
trust us" got us into this mess in the first place. How would you provide
assurances to the community that this won't be abused? And how is the cost
for the community, in risk, better?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Pedro Fuentes via dev-security-policy]

I understand your rational, but my point is that this is happening in the same 
infrastructure where the whole PKI is operated, and under the responsibility of 
the same operator of the Root. In my understanding the operator of the Root has 
full rights to do delegated OCSP responses if those responses are produced by 
its own OCSP responders.

I'm failing to see what is the main problem you don't consider solved. As per 
your own dissertations in the related posts, there are two issues:

1. The certificate contains incorrect extensions, so it's a misissuance. This 
is solved by revoking the certificate, and this is done not only internally in 
the PKI, but also in OneCRL.

2. The operator of the SubCA could produce improper revocation responses, so 
this is a security risk. This risk is already difficult to find if the operator 
of the subCA is the same operator of the Root... If such entity wants to do a 
wrongdoing, there are far easier ways to do it, than overcomplicated things 
like unrevoking its own subCA...

Sorry, but I don't see the likeliness of the risks you evoke... I see the 
potential risk in externally operated CAs, but not here.


El jueves, 2 de julio de 2020, 23:33:05 (UTC+2), Ryan Sleevi  escribió:
> On Thu, Jul 2, 2020 at 5:30 PM Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > Hello Ryan,
> > Thanks for your detailed response.
> >
> > Just to be sure that we are in the same page. My question was about
> > reissuing a new CA using the same key pair, but this implies also the
> > revocation of the previous version of the certificate.
> >
> 
> Right, but this doesn't do anything, because the previous key pair can be
> used to sign an OCSP response that unrevokes itself.
> 
> This is the problem and why "key destruction" is the best of the
> alternatives (that I discussed) for ensuring that this doesn't happen,
> because it doesn't shift the cost to other participants.

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

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 2, 2020 at 5:30 PM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello Ryan,
> Thanks for your detailed response.
>
> Just to be sure that we are in the same page. My question was about
> reissuing a new CA using the same key pair, but this implies also the
> revocation of the previous version of the certificate.
>

Right, but this doesn't do anything, because the previous key pair can be
used to sign an OCSP response that unrevokes itself.

This is the problem and why "key destruction" is the best of the
alternatives (that I discussed) for ensuring that this doesn't happen,
because it doesn't shift the cost to other participants.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Pedro Fuentes via dev-security-policy]

Hello Ryan,
Thanks for your detailed response.

Just to be sure that we are in the same page. My question was about reissuing a 
new CA using the same key pair, but this implies also the revocation of the 
previous version of the certificate.

You elaborate the need to revoke, but this would be still done anyway.

Thanks,
Pedro

El jueves, 2 de julio de 2020, 22:11:52 (UTC+2), Ryan Sleevi  escribió:
> On Thu, Jul 2, 2020 at 2:34 PM Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > Hello.
> > Sorry if this question is incorrect, but I’d like to know if it would
> > acceptable that, for CAs that are owned and operated by the same entity
> > that the Root, the CA certificate is reissued with the same key pair
> > without the offending EKU, instead of doing a full issuance with new keys.
> > I consider this particular case as less risky than externally operated
> > CAs, so I wonder if this could make possible an smoother solution.
> > Your comments and guidance are appreciated.
> > Thanks,
> > Pedro
> >
> 
> This is definitely a hard question, but I don't see how we can easily
> resolve that. That's why the comments about Key Destruction were made.
> 
> So, first, let me say it definitely mitigates *some* of the security
> concerns, particularly the most major one: a third-party being able to
> arbitrarily "unrevoke" a certificate, particularly "their" certificate. In
> the cases of 3P Sub-CAs, this is just so fundamentally terrifying. Even if
> the Sub-CA "hasn't" abused such a capability, the mere knowledge that they
> could gives them greater flexibility to "live dangerously" - or to make
> them a ripe target for compromise.
> 
> Now assuming the keys are all part of the same (audited) CA infrastructure,
> what does the risk perspective there look like? In effect, for every
> Issuing CA that has issued one of these, Browsers/Relying Parties have no
> assurance that any revocations are "correct". This is important, because
> when a CA revokes a Sub-CA, even their own, we often stop worrying about
> audits, for example, or stop looking for misissued certificates, because
> "of course" these certificates can't be used for that purpose. The mere
> existence of these certificates undermines that whole design: we have to
> treat every revoked Sub-CA as if it was unrevoked, /especially/ if that
> Sub-CA was the one that had the EKU.
> 
> Now, it might be tempting to say "Well, can't we audit the key usage to
> make sure it never signs a delegated OCSP response"? But that shifts the
> burden and the risk now onto the client software, for what was actually a
> CA mistake. A new form of audit would have to be designed to account for
> that, and browsers would have to think *very* carefully about what controls
> were suitable, whether the auditor was qualified to examine those controls
> and had the necessary knowledge. In short, it requires Browsers/the client
> to work through every possible thing that could go wrong with this key
> existing, and then think about how to defend against it. While the CA might
> see this as "saving" a costly revocation, it doesn't really "save" anything
> - it just shifts all the cost onto browsers.
> 
> It might be tempting to ask how many had the digitalSignature KU, and can
> we check the KU on OCSP responses to make sure it matches? In theory,
> clients wouldn't accept it, so they wouldn't be unrevocable and able to
> cause shenanigans, and we're saved! But again, this is a cost transfer:
> every client and relying party now needs to be updated to enforce this, and
> work out the compatibility issues, and test and engineer. And even then, it
> might be months or years for users to be protected, when the BRs are
> supposed to provide protection "within 7 days". Even "clever" alternatives,
> like "Don't allow a delegated responder to provide a response for itself"
> don't fully address the issue, because it can still provide responses for
> others, and that would further require mutating the revocation checking
> process described in RFC 5280 to "skip" OCSP (or fall back) to CRLs. All of
> this is more complexity, more testing, and contributes to the body of "dark
> knowledge" needed for a secure implementation, which makes it harder to
> write new browsers / new libraries to verify certificates.
> 
> This is the risk analysis we expect CAs to work through, and think about.
> What is the cost of this decision on others? Often, CAs focus
> (understandably) on the cost to those they've issued certificates to, but
> ignore the externalized ecosystem that they're simply shifting those costs
> to. The BRs try to force the CA to account for this up front, because they
> *know* that if *anything* goes wrong, they have 7 days to revoke, but then
> they don't design their PKIs to be resilient for that.
> 
> You can imagine a CA that was rotating issuing intermediates every year
> would be in a better position, for example, if this was a "previous"

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 2, 2020 at 2:34 PM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello.
> Sorry if this question is incorrect, but I’d like to know if it would
> acceptable that, for CAs that are owned and operated by the same entity
> that the Root, the CA certificate is reissued with the same key pair
> without the offending EKU, instead of doing a full issuance with new keys.
> I consider this particular case as less risky than externally operated
> CAs, so I wonder if this could make possible an smoother solution.
> Your comments and guidance are appreciated.
> Thanks,
> Pedro
>

This is definitely a hard question, but I don't see how we can easily
resolve that. That's why the comments about Key Destruction were made.

So, first, let me say it definitely mitigates *some* of the security
concerns, particularly the most major one: a third-party being able to
arbitrarily "unrevoke" a certificate, particularly "their" certificate. In
the cases of 3P Sub-CAs, this is just so fundamentally terrifying. Even if
the Sub-CA "hasn't" abused such a capability, the mere knowledge that they
could gives them greater flexibility to "live dangerously" - or to make
them a ripe target for compromise.

Now assuming the keys are all part of the same (audited) CA infrastructure,
what does the risk perspective there look like? In effect, for every
Issuing CA that has issued one of these, Browsers/Relying Parties have no
assurance that any revocations are "correct". This is important, because
when a CA revokes a Sub-CA, even their own, we often stop worrying about
audits, for example, or stop looking for misissued certificates, because
"of course" these certificates can't be used for that purpose. The mere
existence of these certificates undermines that whole design: we have to
treat every revoked Sub-CA as if it was unrevoked, /especially/ if that
Sub-CA was the one that had the EKU.

Now, it might be tempting to say "Well, can't we audit the key usage to
make sure it never signs a delegated OCSP response"? But that shifts the
burden and the risk now onto the client software, for what was actually a
CA mistake. A new form of audit would have to be designed to account for
that, and browsers would have to think *very* carefully about what controls
were suitable, whether the auditor was qualified to examine those controls
and had the necessary knowledge. In short, it requires Browsers/the client
to work through every possible thing that could go wrong with this key
existing, and then think about how to defend against it. While the CA might
see this as "saving" a costly revocation, it doesn't really "save" anything
- it just shifts all the cost onto browsers.

It might be tempting to ask how many had the digitalSignature KU, and can
we check the KU on OCSP responses to make sure it matches? In theory,
clients wouldn't accept it, so they wouldn't be unrevocable and able to
cause shenanigans, and we're saved! But again, this is a cost transfer:
every client and relying party now needs to be updated to enforce this, and
work out the compatibility issues, and test and engineer. And even then, it
might be months or years for users to be protected, when the BRs are
supposed to provide protection "within 7 days". Even "clever" alternatives,
like "Don't allow a delegated responder to provide a response for itself"
don't fully address the issue, because it can still provide responses for
others, and that would further require mutating the revocation checking
process described in RFC 5280 to "skip" OCSP (or fall back) to CRLs. All of
this is more complexity, more testing, and contributes to the body of "dark
knowledge" needed for a secure implementation, which makes it harder to
write new browsers / new libraries to verify certificates.

This is the risk analysis we expect CAs to work through, and think about.
What is the cost of this decision on others? Often, CAs focus
(understandably) on the cost to those they've issued certificates to, but
ignore the externalized ecosystem that they're simply shifting those costs
to. The BRs try to force the CA to account for this up front, because they
*know* that if *anything* goes wrong, they have 7 days to revoke, but then
they don't design their PKIs to be resilient for that.

You can imagine a CA that was rotating issuing intermediates every year
would be in a better position, for example, if this was a "previous"
mistake, since fixed. The impact/blast radius of revoking an intermediate
is a linear decay tied to how many unexpired certificates from that
intermediate there are, which is precisely why you should rotate often.
It's a point I've made often, especially with respect to certificate
lifetimes, but it still doesn't seem to have been taken to heart yet by
many. I'm encouraged GlobalSign's new infrastructure appears to be doing
so, and although it was also affected by this issue, it's hopefully
"easier" for them to clean up versus others.

But this 

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Paul van Brouwershaven via dev-security-policy]

When validating the EKU using `Test-Certificate` Windows states it's
invalid, but when using `certutil` it's accepted or not explicitly checked.
https://gist.github.com/vanbroup/64760f1dba5894aa001b7222847f7eef

When/if I have time I will try to do some further tests with a custom setup
to see if the EKU is validated at all.

On Thu, 2 Jul 2020 at 19:26, Ryan Sleevi  wrote:

>
>
> On Thu, Jul 2, 2020 at 1:15 PM Paul van Brouwershaven <
> p...@vanbrouwershaven.com> wrote:
>
>> That's not correct, and is similar to the mistake I originally/previously
>>> made, and was thankfully corrected on, which also highlighted the
>>> security-relevant nature of it. I encourage you to give another pass at
>>> Robin's excellent write-up, at
>>> https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/XQd3rNF4yOo/bXYjt1mZAwAJ
>>>
>>
>> Thanks, it's an interesting thread, but as shown above, Windows does
>> validate the EKU chain, but doesn't look to validate it for delegated OCSP
>> signing certificates?
>>
>
> The problem is providing the EKU as you're doing, which forces chain
> validation of the EKU, as opposed to validating the OCSP response, which
> does not.
>
> A more appropriate test is to install the test root R as a locally trusted
> CA, issue an intermediate I (without the EKU/only id-kp-serverAuth), issue
> an OCSP responder O (with the EKU), and issue a leaf cert L. You can then
> validate the OCSP response from the responder cert (that is, an OCSP
> response signed by the chain O-I-R) for the certificate L-I-R.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Pedro Fuentes via dev-security-policy]

Hello. 
Sorry if this question is incorrect, but I’d like to know if it would 
acceptable that, for CAs that are owned and operated by the same entity that 
the Root, the CA certificate is reissued with the same key pair without the 
offending EKU, instead of doing a full issuance with new keys. 
I consider this particular case as less risky than externally operated CAs, so 
I wonder if this could make possible an smoother solution. 
Your comments and guidance are appreciated. 
Thanks,
Pedro
___
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: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 2, 2020 at 1:15 PM Paul van Brouwershaven <
p...@vanbrouwershaven.com> wrote:

> That's not correct, and is similar to the mistake I originally/previously
>> made, and was thankfully corrected on, which also highlighted the
>> security-relevant nature of it. I encourage you to give another pass at
>> Robin's excellent write-up, at
>> https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/XQd3rNF4yOo/bXYjt1mZAwAJ
>>
>
> Thanks, it's an interesting thread, but as shown above, Windows does
> validate the EKU chain, but doesn't look to validate it for delegated OCSP
> signing certificates?
>

The problem is providing the EKU as you're doing, which forces chain
validation of the EKU, as opposed to validating the OCSP response, which
does not.

A more appropriate test is to install the test root R as a locally trusted
CA, issue an intermediate I (without the EKU/only id-kp-serverAuth), issue
an OCSP responder O (with the EKU), and issue a leaf cert L. You can then
validate the OCSP response from the responder cert (that is, an OCSP
response signed by the chain O-I-R) for the certificate L-I-R.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Paul van Brouwershaven via dev-security-policy]

On Thu, 2 Jul 2020 at 16:41, Ryan Sleevi  wrote:

>
> On Thu, Jul 2, 2020 at 10:34 AM Paul van Brouwershaven via
> dev-security-policy  wrote:
>
>> I did do some testing on EKU chaining in Go, but from my understand this
>> works the same for Microsoft:
>>
>
> Go has a bug https://twitter.com/FiloSottile/status/1278501854306095104
>
> The understanding for Microsoft isn't correct, as linked earlier in the
> reference materials.
>

I wasn't aware that this would be for ADCS only.
The Windows certificate viewer doesn't validate the purpose but after a
quick test with the powershell command Test-Certificate, it does look to
validate the EKU path on Windows 10:

Get-ChildItem -Path
Cert:\currentUser\addressbook\63D6AEAD044E9D720930D7F814B7C74DBB541572 |
Test-Certificate -User -AllowUntrustedRoot -EKU "1.3.6.1.5.5.7.3.9"
WARNING: Chain status:
CERT_TRUST_IS_NOT_VALID_FOR_USAGE
Test-Certificate : The certificate is not valid for the requested usage.
0x800b0110 (-2146762480 CERT_E_WRONG_USAGE)
At line:1 char:94
+ ... DBB541572 | Test-Certificate -User -AllowUntrustedRoot -EKU "1.3.6.1.
...
+ ~
+ CategoryInfo  : NotSpecified: (:Certificate) [Test-Certificate],
Exception
+ FullyQualifiedErrorId :
CryptographicError,Microsoft.CertificateServices.Commands.TestCertificate


(the certificates in the test above are from the chain generated by my
previous example)


>
>> Microsoft requires the EKU to be present in issuing CA certificates:
>
>
>> *Issuing CA certificates that chain to a participating Root CA must be
>> constrained to a single EKU (e.g., separate Server Authentication, S/MIME,
>> Code Signing, and Time Stamping uses. This means that a single Issuing CA
>> must not combine server authentication with S/MIME, code signing or time
>> stamping EKU. A separate intermediate must be used for each use case.
>>
>> https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#a-root-requirements
>> <
>> https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#a-root-requirements
>> >
>> (8)*
>>
>
> Did you paste the wrong section? This doesn't seem to be consistent with
> what you're saying, and perhaps it was just a bad copy/paste? Even if
> quoting Microsoft policy, how do you square this with: "A CA must
> technically constrain an OCSP responder such that the only EKU allowed is
> OCSP Signing."  (from that same section)
>

No, it does state that the EKU for other purposes must be set in the ussing
CA, my point here is that when you set these it does exclude OCSP signing.

The other item of the policy you refer to is confusing as it doesn't seem
to make a difference between CA signed and CA delegated responses, it might
even prohibit CA signed responses?


> Did you read the related thread where this was previously discussed on
> m.d.s.p.?
>
> Technically constraining issuing CA’s based on the EKU as Microsoft
>> requires feels like a good thing to do. But if we leave out the
>> OCSPSigning
>> EKU we must leave out all EKU constraints (and talk to Microsoft) or move
>> away from delegated OCSP signing certificates and all move to CA signed
>> responses.
>
>
> That's not correct, and is similar to the mistake I originally/previously
> made, and was thankfully corrected on, which also highlighted the
> security-relevant nature of it. I encourage you to give another pass at
> Robin's excellent write-up, at
> https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/XQd3rNF4yOo/bXYjt1mZAwAJ
>

Thanks, it's an interesting thread, but as shown above, Windows does
validate the EKU chain, but doesn't look to validate it for delegated OCSP
signing certificates?
___
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: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 2, 2020 at 10:34 AM Paul van Brouwershaven via
dev-security-policy  wrote:

> I did do some testing on EKU chaining in Go, but from my understand this
> works the same for Microsoft:
>

Go has a bug https://twitter.com/FiloSottile/status/1278501854306095104

The understanding for Microsoft isn't correct, as linked earlier in the
reference materials.


> Microsoft requires the EKU to be present in issuing CA certificates:


> *Issuing CA certificates that chain to a participating Root CA must be
> constrained to a single EKU (e.g., separate Server Authentication, S/MIME,
> Code Signing, and Time Stamping uses. This means that a single Issuing CA
> must not combine server authentication with S/MIME, code signing or time
> stamping EKU. A separate intermediate must be used for each use case.
>
> https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#a-root-requirements
> <
> https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#a-root-requirements
> >
> (8)*
>

Did you paste the wrong section? This doesn't seem to be consistent with
what you're saying, and perhaps it was just a bad copy/paste? Even if
quoting Microsoft policy, how do you square this with: "A CA must
technically constrain an OCSP responder such that the only EKU allowed is
OCSP Signing."  (from that same section)

Did you read the related thread where this was previously discussed on
m.d.s.p.?

Technically constraining issuing CA’s based on the EKU as Microsoft
> requires feels like a good thing to do. But if we leave out the OCSPSigning
> EKU we must leave out all EKU constraints (and talk to Microsoft) or move
> away from delegated OCSP signing certificates and all move to CA signed
> responses.


That's not correct, and is similar to the mistake I originally/previously
made, and was thankfully corrected on, which also highlighted the
security-relevant nature of it. I encourage you to give another pass at
Robin's excellent write-up, at
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/XQd3rNF4yOo/bXYjt1mZAwAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Paul van Brouwershaven via dev-security-policy]

I did do some testing on EKU chaining in Go, but from my understand this
works the same for Microsoft:


An OCSP responder certificate with Extended Key Usage OCSPSigning, but an
issuing CA without the EKU (result: certificate specifies an incompatible
key usage)

https://play.golang.org/p/XSsKfxytx3O


The same chain but now the ICA includes the Extended Key Usage OCSPSigning
(result: ok)

https://play.golang.org/p/XL7364nSCe8


Microsoft requires the EKU to be present in issuing CA certificates:



*Issuing CA certificates that chain to a participating Root CA must be
constrained to a single EKU (e.g., separate Server Authentication, S/MIME,
Code Signing, and Time Stamping uses. This means that a single Issuing CA
must not combine server authentication with S/MIME, code signing or time
stamping EKU. A separate intermediate must be used for each use case.
https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#a-root-requirements

(8)*


Technically constraining issuing CA’s based on the EKU as Microsoft
requires feels like a good thing to do. But if we leave out the OCSPSigning
EKU we must leave out all EKU constraints (and talk to Microsoft) or move
away from delegated OCSP signing certificates and all move to CA signed
responses.

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

>
> On 02/07/2020 12:52, Pedro Fuentes via dev-security-policy wrote:
> > If we look at the BR, it says:
> > "[^**]: Generally Extended Key Usage will only appear within end entity
> certificates (as highlighted in RFC 5280 (4.2.1.12)), however, Subordinate
> CAs MAY include the extension to further protect relying parties until the
> use of the extension is consistent between Application Software Suppliers
> whose software is used by a substantial portion of Relying Parties
> worldwide."
> >
> > Therefore, in my humble opinion it's fully logical to understand this
> requirement "as it's written", which is to restrict the CA and protect
> relying parties... In other words, the BR is clearly saying that the
> meaning of the EKU in SubCAs MUST be understood as a constraint and NOT to
> express the EKU of the certificate itself.
>
> Pedro,
>
> I think that the problem here isn't what the BRs indicate the reading of
> EKUs in a CA certificate should be.
>
> It's that RFC 6960 (Section 4.2.2.2) states that
>
> > 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.
>
>
> In other words, if a certificate X (CA or otherwise) contains that EKU
> value, by definition, it becomes a valid delegated OCSP responder
> certificate, regardless of the intentions surrounding EKU interpretation
> in CA certificates. Thus, OCSP responses signed by that X, on behalf of
> X's issuing CA, _would_ be properly validated by compliant RP software.
> If a hostile party grabs hold of the private key for the CA certificate,
> their harm is not limited to the PKI described by the original CA
> certificate, but extends to all of the sibling certificates of X
>
> Now, it's true that the BRs also require the id-pkix-ocsp-nocheck
> extension too, but RFC 6960 does not require it (it's just the way to
> say "trust this delegated cert for as long as it is valid", and don't
> consult OCSP/CRLs).
>
> Regards,
>
> Neil
>
> ___
> 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 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: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Neil Dunbar via dev-security-policy]

On 02/07/2020 12:52, Pedro Fuentes via dev-security-policy wrote:
> If we look at the BR, it says:
> "[^**]: Generally Extended Key Usage will only appear within end entity 
> certificates (as highlighted in RFC 5280 (4.2.1.12)), however, Subordinate 
> CAs MAY include the extension to further protect relying parties until the 
> use of the extension is consistent between Application Software Suppliers 
> whose software is used by a substantial portion of Relying Parties worldwide."
>
> Therefore, in my humble opinion it's fully logical to understand this 
> requirement "as it's written", which is to restrict the CA and protect 
> relying parties... In other words, the BR is clearly saying that the meaning 
> of the EKU in SubCAs MUST be understood as a constraint and NOT to express 
> the EKU of the certificate itself.

Pedro,

I think that the problem here isn't what the BRs indicate the reading of
EKUs in a CA certificate should be.

It's that RFC 6960 (Section 4.2.2.2) states that 

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


In other words, if a certificate X (CA or otherwise) contains that EKU
value, by definition, it becomes a valid delegated OCSP responder
certificate, regardless of the intentions surrounding EKU interpretation
in CA certificates. Thus, OCSP responses signed by that X, on behalf of
X's issuing CA, _would_ be properly validated by compliant RP software.
If a hostile party grabs hold of the private key for the CA certificate,
their harm is not limited to the PKI described by the original CA
certificate, but extends to all of the sibling certificates of X

Now, it's true that the BRs also require the id-pkix-ocsp-nocheck
extension too, but RFC 6960 does not require it (it's just the way to
say "trust this delegated cert for as long as it is valid", and don't
consult OCSP/CRLs).

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

[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: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Peter Mate Erdosi via dev-security-policy]

 Hi Rob, thanks for the clarification.

What will be the situation if the issuer is a Root CA instead of the "TLS
capable (intermediate or subordinate) CA"?
As far as I understood till now, it is not misissued, if the root CA cannot
be considered as an "Mozilla-trusted, TLS-capable CA".

And considering chapter 7.1.2.1 b) of CAB Forum BRG, extendedKeyUsage MUST
NOT be present in root CA certificates, but "If the Root CA Private Key is
used for signing OCSP responses, then the digitalSignature bit MUST be
set", which is the same in the 7.1.2.2 e) : ".  If the Subordinate CA
Private Key is used for signing OCSP responses, then the digitalSignature
bit MUST be set."

I have not seen that the SQL query considered with digitalSignature bit,
but as I interpreted until now, the CA cannot sign OCSP responses without
setting the digitalSignature bit even the OCSPSigning EKU is used. And
Mozilla requires the BRG-conformant CAs also, isn't it?

So, I am a bit confused.


Thanks again,

Peter

On Thu, Jul 2, 2020 at 1:21 PM Rob Stradling  wrote:

> Hi Peter.  The "following CA certificate" (which I'll call Certificate X)
> is not capable of issuing id-kp-serverAuth leaf certificates that will be
> trusted by Mozilla, but that fact is entirely irrelevant to this
> discussion.  Notice that Ryan wrote "*issued by* a Mozilla-trusted,
> TLS-capable CA" rather than "*is* a Mozilla-trusted, TLS-capable CA".
>
> Certificate X contains the id-kp-OCSPSigning EKU.  This means that it can
> be used as a delegated OCSP signer, to sign OCSP responses on behalf of its
> issuer.  If its issuer is "a Mozilla-trusted, TLS-capable CA", then all of
> its issuer's delegated OCSP signer certificates are in scope for the BRs
> and for the Mozilla Root Store Policy.
>
> Certificate X is an intermediate CA certificate, which is capable of
> issuing id-kp-timeStamping leaf certificates.  That's all very nice, but it
> doesn't alter the fact that Certificate X is also a (misissued) delegated
> OCSP signing certificate that is in scope for the BRs and the Mozilla Root
> Store Policy.
>
> --
> *From:* dev-security-policy 
> on behalf of Peter Mate Erdosi via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> *Sent:* 02 July 2020 12:04
> *To:* mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> *Subject:* Re: SECURITY RELEVANT FOR CAs: The curious case of the
> Dangerous Delegated Responder Cert
>
> Just for my better understanding, is the following CA certificate
> "TLS-capable"?
>
> X509v3 Basic Constraints critical:
> CA:TRUE
> X509v3 Key Usage critical:
> Certificate Sign, CRL Sign
> X509v3 Extended Key Usage:
> Time Stamping, OCSP Signing
>
>
> Peter
>
>
>
> On Thu, Jul 2, 2020 at 12:14 PM Rob Stradling via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > > This batch is NOT comprehensive. According to crt.sh, there are
> > approximately 293 certificates that meet the criteria of "issued by a
> > Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without
> > pkix-nocheck". misissued.com had some issues with parsing some of these
> > certificates, due to other non-conformities, so I only included a sample.
> >
> > I just reproduced this result.  I've posted my SQL query and (thanks to
> > GitHub) a searchable TSV report of all 293 certificates here:
> > https://gist.github.com/robstradling/6c737c97a7a3ab843b6f24747fc9ad1f
> >
> > 
> > From: dev-security-policy  >
> > on behalf of Ryan Sleevi via dev-security-policy <
> > dev-security-policy@lists.mozilla.org>
> > Sent: 01 July 2020 22:05
> > To: mozilla-dev-security-policy <
> > mozilla-dev-security-pol...@lists.mozilla.org>
> > Subject: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous
> > Delegated Responder Cert
> >
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you recognize the sender and know
> > the content is safe.
> >
> >
> > I've created a new batch of certificates that violate 4.9.9 of the BRs,
> > which was introduced with the first version of the Baseline Requirements
> as
> > a MUST. This is https://misissued.com/batch/138/
> >
> > A quick inspection among the affected CAs include O fields of: QuoVadis,
> > GlobalSign, Digicert, HARICA, Certinomis, AS Sertifitseeimiskeskus,
> > Actalis, Atos, AC Camerfirma, SECOM, T-Systems, WISeKey, SCEE, and CNNIC.
> >
> > Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
> > include an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP
> > Delegated Responder within Section 4.2.2.2 as indicated by the presence
> of
> > the id-kp-OCSPSigning as an EKU.
> >
> > These certificates lack the necessary extension, and as such, violate the
> > BRs. As the vast majority of these were issued on-or-after 2013-02-01,
> the
> > Effective Date of Mozilla Root CA Policy v2.1, these are misissued. You
> > could 

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: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Pedro Fuentes via dev-security-policy]

El jueves, 2 de julio de 2020, 9:23:19 (UTC+2), Paul van Brouwershaven  
escribió:
> But as Pedro also mentioned, the EKU extension in intermediate certificates
> acts as a constraint on the permitted EKU OIDs in end-entity certificates,
> which means you won't be able to use delegated OCSP signing certificates
> with strict EKU validation on the path? While not every client might have
> strict validation on this, it would be really confusing if it's required
> for one EKU and forbidden for the other.
> 

If we look at the BR, it says:
"[^**]: Generally Extended Key Usage will only appear within end entity 
certificates (as highlighted in RFC 5280 (4.2.1.12)), however, Subordinate CAs 
MAY include the extension to further protect relying parties until the use of 
the extension is consistent between Application Software Suppliers whose 
software is used by a substantial portion of Relying Parties worldwide."

Therefore, in my humble opinion it's fully logical to understand this 
requirement "as it's written", which is to restrict the CA and protect relying 
parties... In other words, the BR is clearly saying that the meaning of the EKU 
in SubCAs MUST be understood as a constraint and NOT to express the EKU of the 
certificate itself. The same applies to other EKUs, for example the meaning of 
serverAuth EKU is EVIDENTLY associated to a constraint, and no one understands 
that the CA certificate can be used to protect a web server, as in that case 
the rest of the certificate profile should be also consistent with the 
requirements of the leaf TLS certs... I think it's not logical to consider in 
the BR the implications of setting some EKU and not the others.

I would consider this as two derived issues that need to be considered 
separately and appropriately:

#1. There's an evident "gap" in the BR in section 7.1.2.2-g that is creating a 
potential inconsistency with the RFC, and also creates incompatibilities with 
certain software solutions.

#2. This inconsistency could provoke in certain conditions a security risk, and 
in particular this applies in case of externally-operated subCAs. This security 
risk must analysed and mitigated by, maybe, revoking these SubCAs.

But I would say that just considering this as a unique problem that needs a 
unique solution is not appropriate.

Best,
Pedro
___
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: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Rob Stradling via dev-security-policy]

Hi Peter.  The "following CA certificate" (which I'll call Certificate X) is 
not capable of issuing id-kp-serverAuth leaf certificates that will be trusted 
by Mozilla, but that fact is entirely irrelevant to this discussion.  Notice 
that Ryan wrote "issued by a Mozilla-trusted, TLS-capable CA" rather than "is a 
Mozilla-trusted, TLS-capable CA".

Certificate X contains the id-kp-OCSPSigning EKU.  This means that it can be 
used as a delegated OCSP signer, to sign OCSP responses on behalf of its 
issuer.  If its issuer is "a Mozilla-trusted, TLS-capable CA", then all of its 
issuer's delegated OCSP signer certificates are in scope for the BRs and for 
the Mozilla Root Store Policy.

Certificate X is an intermediate CA certificate, which is capable of issuing 
id-kp-timeStamping leaf certificates.  That's all very nice, but it doesn't 
alter the fact that Certificate X is also a (misissued) delegated OCSP signing 
certificate that is in scope for the BRs and the Mozilla Root Store Policy.


From: dev-security-policy  on 
behalf of Peter Mate Erdosi via dev-security-policy 

Sent: 02 July 2020 12:04
To: mozilla-dev-security-policy 
Subject: Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous 
Delegated Responder Cert

Just for my better understanding, is the following CA certificate
"TLS-capable"?

X509v3 Basic Constraints critical:
CA:TRUE
X509v3 Key Usage critical:
Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
Time Stamping, OCSP Signing


Peter



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

> > This batch is NOT comprehensive. According to crt.sh, there are
> approximately 293 certificates that meet the criteria of "issued by a
> Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without
> pkix-nocheck". misissued.com had some issues with parsing some of these
> certificates, due to other non-conformities, so I only included a sample.
>
> I just reproduced this result.  I've posted my SQL query and (thanks to
> GitHub) a searchable TSV report of all 293 certificates here:
> https://gist.github.com/robstradling/6c737c97a7a3ab843b6f24747fc9ad1f
>
> 
> From: dev-security-policy 
> on behalf of Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> Sent: 01 July 2020 22:05
> To: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous
> Delegated Responder Cert
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
> I've created a new batch of certificates that violate 4.9.9 of the BRs,
> which was introduced with the first version of the Baseline Requirements as
> a MUST. This is https://misissued.com/batch/138/
>
> A quick inspection among the affected CAs include O fields of: QuoVadis,
> GlobalSign, Digicert, HARICA, Certinomis, AS Sertifitseeimiskeskus,
> Actalis, Atos, AC Camerfirma, SECOM, T-Systems, WISeKey, SCEE, and CNNIC.
>
> Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
> include an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP
> Delegated Responder within Section 4.2.2.2 as indicated by the presence of
> the id-kp-OCSPSigning as an EKU.
>
> These certificates lack the necessary extension, and as such, violate the
> BRs. As the vast majority of these were issued on-or-after 2013-02-01, the
> Effective Date of Mozilla Root CA Policy v2.1, these are misissued. You
> could also consider the effective date as 2013-05-15, described later in
> [1] , without changing the results.
>
> This batch is NOT comprehensive. According to crt.sh, there are
> approximately 293 certificates that meet the criteria of "issued by a
> Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without
> pkix-nocheck". misissued.com had some issues with parsing some of these
> certificates, due to other non-conformities, so I only included a sample.
>
> Censys.io is aware of approximately 276 certificates that meet this
> criteria, as you can see at [2]. The differences in perspectives
> underscores the importance of CAs needing to carefully examine the
> certificates they've issued to understand.
>
> It's important for CAs to understand this is Security Relevant. While they
> should proceed with revoking these CAs within seven (7) days, as defined
> under the Baseline Requirements Section 4.9.1.2, the degree of this issue
> likely also justifies requiring witnessed Key Destruction Reports, in order
> to preserve the integrity of the issuer of these certificates (which may
> include the CA's root).
>
> The reason for this is simple: In every case I examined, these are
> certificates that appear to nominally be intended as Issuing CAs, not as
> OCSP Responder Certificates. 

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Peter Mate Erdosi via dev-security-policy]

Just for my better understanding, is the following CA certificate
"TLS-capable"?

X509v3 Basic Constraints critical:
CA:TRUE
X509v3 Key Usage critical:
Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
Time Stamping, OCSP Signing


Peter



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

> > This batch is NOT comprehensive. According to crt.sh, there are
> approximately 293 certificates that meet the criteria of "issued by a
> Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without
> pkix-nocheck". misissued.com had some issues with parsing some of these
> certificates, due to other non-conformities, so I only included a sample.
>
> I just reproduced this result.  I've posted my SQL query and (thanks to
> GitHub) a searchable TSV report of all 293 certificates here:
> https://gist.github.com/robstradling/6c737c97a7a3ab843b6f24747fc9ad1f
>
> 
> From: dev-security-policy 
> on behalf of Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> Sent: 01 July 2020 22:05
> To: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous
> Delegated Responder Cert
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
> I've created a new batch of certificates that violate 4.9.9 of the BRs,
> which was introduced with the first version of the Baseline Requirements as
> a MUST. This is https://misissued.com/batch/138/
>
> A quick inspection among the affected CAs include O fields of: QuoVadis,
> GlobalSign, Digicert, HARICA, Certinomis, AS Sertifitseeimiskeskus,
> Actalis, Atos, AC Camerfirma, SECOM, T-Systems, WISeKey, SCEE, and CNNIC.
>
> Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
> include an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP
> Delegated Responder within Section 4.2.2.2 as indicated by the presence of
> the id-kp-OCSPSigning as an EKU.
>
> These certificates lack the necessary extension, and as such, violate the
> BRs. As the vast majority of these were issued on-or-after 2013-02-01, the
> Effective Date of Mozilla Root CA Policy v2.1, these are misissued. You
> could also consider the effective date as 2013-05-15, described later in
> [1] , without changing the results.
>
> This batch is NOT comprehensive. According to crt.sh, there are
> approximately 293 certificates that meet the criteria of "issued by a
> Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without
> pkix-nocheck". misissued.com had some issues with parsing some of these
> certificates, due to other non-conformities, so I only included a sample.
>
> Censys.io is aware of approximately 276 certificates that meet this
> criteria, as you can see at [2]. The differences in perspectives
> underscores the importance of CAs needing to carefully examine the
> certificates they've issued to understand.
>
> It's important for CAs to understand this is Security Relevant. While they
> should proceed with revoking these CAs within seven (7) days, as defined
> under the Baseline Requirements Section 4.9.1.2, the degree of this issue
> likely also justifies requiring witnessed Key Destruction Reports, in order
> to preserve the integrity of the issuer of these certificates (which may
> include the CA's root).
>
> The reason for this is simple: In every case I examined, these are
> certificates that appear to nominally be intended as Issuing CAs, not as
> OCSP Responder Certificates. It would appear that many CAs were unfamiliar
> with RFC 6960 when constructing their certificate profiles, and similarly
> ignored discussion of this issue in the past [3], which highlighted the
> security impact of this. I've flagged this as a SECURITY matter for CAs to
> carefully review, because in the cases where a third-party, other than the
> Issuing CA, operates such a certificate, the Issuing CA has delegated the
> ability to mint arbitrary OCSP responses to this third-party!
>
> For example, consider a certificate like https://crt.sh/?id=2657658699 .
> This certificate, from HARICA, meets Mozilla's definition of "Technically
> Constrained" for TLS, in that it lacks the id-kp-serverAuth EKU. However,
> because it includes the OCSP Signing EKU, this certificate can be used to
> sign arbitrary OCSP messages for HARICA's Root!
>
> This also applies to non-technically-constrained sub-CAs. For example,
> consider this certificate https://crt.sh/?id=21606064 . It was issued by
> DigiCert to Microsoft, granting Microsoft the ability to provide OCSP
> responses for any certificate issued by Digicert's Baltimore CyberTrust
> Root. We know from DigiCert's disclosures that this is independently
> operated by Microsoft.
>
> Unfortunately, revocation of this 

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Rob Stradling via dev-security-policy]

> This batch is NOT comprehensive. According to crt.sh, there are approximately 
> 293 certificates that meet the criteria of "issued by a Mozilla-trusted, 
> TLS-capable CA, with the OCSPSigning EKU, and without pkix-nocheck". 
> misissued.com had some issues with parsing some of these certificates, due to 
> other non-conformities, so I only included a sample.

I just reproduced this result.  I've posted my SQL query and (thanks to GitHub) 
a searchable TSV report of all 293 certificates here:
https://gist.github.com/robstradling/6c737c97a7a3ab843b6f24747fc9ad1f


From: dev-security-policy  on 
behalf of Ryan Sleevi via dev-security-policy 

Sent: 01 July 2020 22:05
To: mozilla-dev-security-policy 
Subject: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated 
Responder Cert

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


I've created a new batch of certificates that violate 4.9.9 of the BRs,
which was introduced with the first version of the Baseline Requirements as
a MUST. This is https://misissued.com/batch/138/

A quick inspection among the affected CAs include O fields of: QuoVadis,
GlobalSign, Digicert, HARICA, Certinomis, AS Sertifitseeimiskeskus,
Actalis, Atos, AC Camerfirma, SECOM, T-Systems, WISeKey, SCEE, and CNNIC.

Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
include an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP
Delegated Responder within Section 4.2.2.2 as indicated by the presence of
the id-kp-OCSPSigning as an EKU.

These certificates lack the necessary extension, and as such, violate the
BRs. As the vast majority of these were issued on-or-after 2013-02-01, the
Effective Date of Mozilla Root CA Policy v2.1, these are misissued. You
could also consider the effective date as 2013-05-15, described later in
[1] , without changing the results.

This batch is NOT comprehensive. According to crt.sh, there are
approximately 293 certificates that meet the criteria of "issued by a
Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without
pkix-nocheck". misissued.com had some issues with parsing some of these
certificates, due to other non-conformities, so I only included a sample.

Censys.io is aware of approximately 276 certificates that meet this
criteria, as you can see at [2]. The differences in perspectives
underscores the importance of CAs needing to carefully examine the
certificates they've issued to understand.

It's important for CAs to understand this is Security Relevant. While they
should proceed with revoking these CAs within seven (7) days, as defined
under the Baseline Requirements Section 4.9.1.2, the degree of this issue
likely also justifies requiring witnessed Key Destruction Reports, in order
to preserve the integrity of the issuer of these certificates (which may
include the CA's root).

The reason for this is simple: In every case I examined, these are
certificates that appear to nominally be intended as Issuing CAs, not as
OCSP Responder Certificates. It would appear that many CAs were unfamiliar
with RFC 6960 when constructing their certificate profiles, and similarly
ignored discussion of this issue in the past [3], which highlighted the
security impact of this. I've flagged this as a SECURITY matter for CAs to
carefully review, because in the cases where a third-party, other than the
Issuing CA, operates such a certificate, the Issuing CA has delegated the
ability to mint arbitrary OCSP responses to this third-party!

For example, consider a certificate like https://crt.sh/?id=2657658699 .
This certificate, from HARICA, meets Mozilla's definition of "Technically
Constrained" for TLS, in that it lacks the id-kp-serverAuth EKU. However,
because it includes the OCSP Signing EKU, this certificate can be used to
sign arbitrary OCSP messages for HARICA's Root!

This also applies to non-technically-constrained sub-CAs. For example,
consider this certificate https://crt.sh/?id=21606064 . It was issued by
DigiCert to Microsoft, granting Microsoft the ability to provide OCSP
responses for any certificate issued by Digicert's Baltimore CyberTrust
Root. We know from DigiCert's disclosures that this is independently
operated by Microsoft.

Unfortunately, revocation of this certificate is simply not enough to
protect Mozilla TLS users. This is because this Sub-CA COULD provide OCSP
for itself that would successfully validate, AND provide OCSP for other
revoked sub-CAs, even if it was revoked. That is, if this Sub-CA's key was
maliciously used to sign a GOOD response for itself, it would be accepted.
These security concerns are discussed in Section 4.2.2.2.1 of RFC 6960, and
is tied to a reliance on the CRL. Mozilla users COULD be protected through
the use of OneCRL, although this would not protect other PKI participants
or use cases that don't use OneCRL.

A 

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Paul van Brouwershaven via dev-security-policy]

Thanks for raising this issue Ryan, I'm trying to update
http://revocationcheck.com/ to cover this issue.

From my understanding:

The OCSPnocheck extension is only required for a delegated OCSP responder
certificate as it can't provide answers for itself.
For a CA certificate in (CA signed responses) the OCSPnocheck extension
MUST NOT be present as it's not authorized to create a status for itself.

A CA certificate MUST NOT include the OCSPsigning EKU, even when
using CA signed responses.
When using CA signed responses the EKU digitalSignature MUST be set.
Delegated OCSP signing certificates MUST only have the OCSPsigning EKU set
(Microsoft A12)
Delegated OCSP signing certificates MUST be issued directly by the CA that
is identified in the request as the issuer of the EE certificate (RFC6960
4.2.2.2)

But as Pedro also mentioned, the EKU extension in intermediate certificates
acts as a constraint on the permitted EKU OIDs in end-entity certificates,
which means you won't be able to use delegated OCSP signing certificates
with strict EKU validation on the path? While not every client might have
strict validation on this, it would be really confusing if it's required
for one EKU and forbidden for the other.

On Thu, 2 Jul 2020 at 08:19, Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello,
> Our understanding when creating this SubCA was that the CA certificate
> should include the EKUs that would be allowed to issue, and therefore, as
> it would generate certificates for the OCSP responders, it should include
> such EKU, the same it would include the EKU for clientAuthentication, for
> example.
> Can you please clarify why this is not correct and what is the security
> problem it creates?
> Thanks,
> Pedro
>
> El jueves, 2 de julio de 2020, 6:31:16 (UTC+2), Ryan Sleevi  escribió:
> > On Wed, Jul 1, 2020 at 11:48 PM Peter Gutmann  >
> > wrote:
> >
> > > Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> > > writes:
> > >
> > > >Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
> > > include
> > > >an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP Delegated
> > > >Responder within Section 4.2.2.2 as indicated by the presence of the
> > > id-kp-
> > > >OCSPSigning as an EKU.
> > >
> > > Unless I've misread your message, the problem isn't the presence or
> not of
> > > a
> > > nocheck extension but the invalid presence of an OCSP EKU:
> > >
> > > >I've flagged this as a SECURITY matter [...] the Issuing CA has
> delegated
> > > the
> > > >ability to mint arbitrary OCSP responses to this third-party
> > >
> > > So the problem would be the presence of the OCSP EKU when it shouldn't
> be
> > > there, not the absence of the nocheck extension.
> >
> >
> > Not quite. It’s both.
> >
> > The BR violation is caused by the lack of the extension.
> >
> > The security issue is caused by the presence of the EKU.
> >
> > However, since some CAs only view things through the lens of BR/program
> > violations, despite the sizable security risk they pose, the compliance
> > incident is what is tracked. The fact that it’s security relevant is
> > provided so that CAs understand that revocation is necessary, and that
> it’s
> > also not sufficient, because of how dangerous the issue is.
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


-- 
Regards,

Paul van Brouwershaven

http://linkedin.com/in/pvanbrouwershaven
http://facebook.com/p.vanbrouwershaven
http://twitter.com/vanbroup
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Pedro Fuentes via dev-security-policy]

Sorry, my message was incomplete... please read the las part as:

 Can you please clarify why this is not correct and what is the security 
problem it creates if the CA is not operated externally?

El jueves, 2 de julio de 2020, 8:19:34 (UTC+2), Pedro Fuentes  escribió:
> Hello,
> Our understanding when creating this SubCA was that the CA certificate should 
> include the EKUs that would be allowed to issue, and therefore, as it would 
> generate certificates for the OCSP responders, it should include such EKU, 
> the same it would include the EKU for clientAuthentication, for example.
> Can you please clarify why this is not correct and what is the security 
> problem it creates?
> Thanks,
> Pedro
> 
> El jueves, 2 de julio de 2020, 6:31:16 (UTC+2), Ryan Sleevi  escribió:
> > On Wed, Jul 1, 2020 at 11:48 PM Peter Gutmann 
> > wrote:
> > 
> > > Ryan Sleevi via dev-security-policy 
> > > 
> > > writes:
> > >
> > > >Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
> > > include
> > > >an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP Delegated
> > > >Responder within Section 4.2.2.2 as indicated by the presence of the
> > > id-kp-
> > > >OCSPSigning as an EKU.
> > >
> > > Unless I've misread your message, the problem isn't the presence or not of
> > > a
> > > nocheck extension but the invalid presence of an OCSP EKU:
> > >
> > > >I've flagged this as a SECURITY matter [...] the Issuing CA has delegated
> > > the
> > > >ability to mint arbitrary OCSP responses to this third-party
> > >
> > > So the problem would be the presence of the OCSP EKU when it shouldn't be
> > > there, not the absence of the nocheck extension.
> > 
> > 
> > Not quite. It’s both.
> > 
> > The BR violation is caused by the lack of the extension.
> > 
> > The security issue is caused by the presence of the EKU.
> > 
> > However, since some CAs only view things through the lens of BR/program
> > violations, despite the sizable security risk they pose, the compliance
> > incident is what is tracked. The fact that it’s security relevant is
> > provided so that CAs understand that revocation is necessary, and that it’s
> > also not sufficient, because of how dangerous the issue is.

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

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

[Pedro Fuentes via dev-security-policy]

Hello,
Our understanding when creating this SubCA was that the CA certificate should 
include the EKUs that would be allowed to issue, and therefore, as it would 
generate certificates for the OCSP responders, it should include such EKU, the 
same it would include the EKU for clientAuthentication, for example.
Can you please clarify why this is not correct and what is the security problem 
it creates?
Thanks,
Pedro

El jueves, 2 de julio de 2020, 6:31:16 (UTC+2), Ryan Sleevi  escribió:
> On Wed, Jul 1, 2020 at 11:48 PM Peter Gutmann 
> wrote:
> 
> > Ryan Sleevi via dev-security-policy 
> > writes:
> >
> > >Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
> > include
> > >an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP Delegated
> > >Responder within Section 4.2.2.2 as indicated by the presence of the
> > id-kp-
> > >OCSPSigning as an EKU.
> >
> > Unless I've misread your message, the problem isn't the presence or not of
> > a
> > nocheck extension but the invalid presence of an OCSP EKU:
> >
> > >I've flagged this as a SECURITY matter [...] the Issuing CA has delegated
> > the
> > >ability to mint arbitrary OCSP responses to this third-party
> >
> > So the problem would be the presence of the OCSP EKU when it shouldn't be
> > there, not the absence of the nocheck extension.
> 
> 
> Not quite. It’s both.
> 
> The BR violation is caused by the lack of the extension.
> 
> The security issue is caused by the presence of the EKU.
> 
> However, since some CAs only view things through the lens of BR/program
> violations, despite the sizable security risk they pose, the compliance
> incident is what is tracked. The fact that it’s security relevant is
> provided so that CAs understand that revocation is necessary, and that it’s
> also not sufficient, because of how dangerous the issue is.

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