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 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
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 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
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 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
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
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
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"
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
> 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
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
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
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,
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
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.
On Wed, Jul 1, 2020 at 5:05 PM Ryan Sleevi wrote:
> While I'll be looking to create Compliance Incidents for the affected CAs,
>
This is now done, I believe. However, as mentioned, just because a
compliance bug was not filed does not mean that a CA may not be affected;
it may just be that CT
101 - 117 of 117 matches
Mail list logo
