Dear Mr. Wilson,
Could you please share the risk assessment that you have received from
Mr. Sleevi?
I believe it would be very useful for the CAs to understand the gravity
of the issue.
Sincerely yours,
T.K. (No hat)
On 7/4/2020 12:23 PM, Ryan Sleevi via dev-security-policy wrote:
On Fri,
On Fri, Jul 3, 2020 at 10:49 PM Corey Bonnell via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > I don’t understand why you’re making a distinction as to CA certificates,
> which are irrelevant with respect to the Delegated Responder profile. That
> is, you’re trying to
> 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
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
>> 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
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
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 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
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
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
>> 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 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
> 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 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
(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
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 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
> 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
"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
+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 Tuesday, September 10, 2019 at 6:53:47 AM UTC-7, Robin Alden wrote:
> > The aforementioned comments, however, indicate CAs have reported that
> > Microsoft does [require the EKU chaining].
> I agree that statement is true, but I think it inadvertently misleads.
>
> We cannot speak for
> The aforementioned comments, however, indicate CAs have reported that
> Microsoft does [require the EKU chaining].
I agree that statement is true, but I think it inadvertently misleads.
We cannot speak for Microsoft about what their requirements for
id-kp-OCSPSigning are, and we are not aware
On 04/09/2019 17:14, Ryan Sleevi wrote:
> On Wed, Sep 4, 2019 at 11:06 AM Ben Wilson wrote:
>
>> I thought that the EKU "id-kp-OCSPSigning" was for the OCSP responder
>> certificate itself (not the CA that issues the OCSP responder certificate).
>> I don't think I've encountered a problem
On Wed, Sep 4, 2019 at 11:06 AM Ben Wilson wrote:
> I thought that the EKU "id-kp-OCSPSigning" was for the OCSP responder
> certificate itself (not the CA that issues the OCSP responder certificate).
> I don't think I've encountered a problem before, but I guess it would
> depend
> on the
I thought that the EKU "id-kp-OCSPSigning" was for the OCSP responder
certificate itself (not the CA that issues the OCSP responder certificate).
I don't think I've encountered a problem before, but I guess it would depend
on the implementation?
-Original Message-
From:
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
Dear list,
I have a question about the issuance of the OCSP responder certificates in case
of technically constrained CAs. I apologize for the long introduction, but this
may be an important audit question in the (near) future.
--- BEGIN INTRO ---
I would like to cite five points from the
30 matches
Mail list logo
