On Sun, Jul 5, 2020 at 4:35 PM Corey Bonnell wrote:
>
> > Nothing in the RFCs specifies the profile you describe for commonName.
> That's something the BRs do, and they explicitly do it contingent upon the
> CA bit (Subordinate CA vs Subscriber Cert)
>
> I mean, that’s exactly how SSL/TLS hostnam
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, J
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 fi
> 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 cer
>> 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
: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
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
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 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 certi
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 clien
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 ex
s,
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, Ju
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 an
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> &
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 us
(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 respo
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 sub
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
> 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 ex
closures 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: m
rom 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:
+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 discussio
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
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 Microsof
> 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 before,
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 impleme
-
From: dev-security-policy On
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Wednesday, September 4, 2019 9:01 AM
To: perd...@gmail.com
Cc: mozilla-dev-security-policy
Subject: Re: Question about the issuance of OCSP Responder Certificates by
technically constrained CAs
On Wed, Sep 4, 2019 a
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-OCSPSignin
30 matches
Mail list logo
