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

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

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

[Ryan Sleevi via dev-security-policy]

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

[Peter Gutmann via dev-security-policy]

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.

Peter.
___
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 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 does not know of the cert and the CA did not
disclose it via CCADB. I only filed incidents for CAs where the issuer is
not already revoked via OneCRL.

https://bugzilla.mozilla.org/show_bug.cgi?id=1649961 - Actalis
https://bugzilla.mozilla.org/show_bug.cgi?id=1649963 - ATOS
https://bugzilla.mozilla.org/show_bug.cgi?id=1649944 - Camerfirma
https://bugzilla.mozilla.org/show_bug.cgi?id=1649951 - DigiCert
https://bugzilla.mozilla.org/show_bug.cgi?id=1649943 - Firmaprofesional
https://bugzilla.mozilla.org/show_bug.cgi?id=1649937 - GlobalSign
https://bugzilla.mozilla.org/show_bug.cgi?id=1649945 - HARICA
https://bugzilla.mozilla.org/show_bug.cgi?id=1649947 - Microsec
https://bugzilla.mozilla.org/show_bug.cgi?id=1649938 - QuoVadis
https://bugzilla.mozilla.org/show_bug.cgi?id=1649964 - PKIoverheid
https://bugzilla.mozilla.org/show_bug.cgi?id=1649962 - SECOM
https://bugzilla.mozilla.org/show_bug.cgi?id=1649942 - SK ID
https://bugzilla.mozilla.org/show_bug.cgi?id=1649941 - T-Systems
https://bugzilla.mozilla.org/show_bug.cgi?id=1649939 - WISeKey
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy