(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
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)
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
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
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"
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
+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
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
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
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
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
> 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
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
"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
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
> 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
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
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
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
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.
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
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
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
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
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
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
>> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
>> 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
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
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
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
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,
> 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
46 matches
Mail list logo
