Hello Ryan,
Thank you for the ongoing dialogue. We read your latest message and we
understand your points. We can follow your arguments that the solution we
proposed would not be viable for the overall ecosystem.
It was a pleasure to have this discussion with you and we thank you for the
On 2020-11-18 16:36, Ryan Sleevi wrote:
On Wed, Nov 18, 2020 at 8:19 AM Nils Amiet via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
We have carefully read your email, and believe we’ve identified the
following
important points:
1. Potential feasibility issue due to lack
On Wed, Nov 18, 2020 at 8:19 AM Nils Amiet via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> We have carefully read your email, and believe we’ve identified the
> following
> important points:
>
> 1. Potential feasibility issue due to lack of path building support
>
> 2.
> I realize this is almost entirely critical, and I hope it's taken as
> critical of the proposal, not of the investment or interest in this space.
Not a problem for being critical and we don’t take it personally. We
appreciate the discussion, the time you spend and the opportunity to propose
On 2020-11-16 23:17, Ryan Sleevi wrote:
On Mon, Nov 16, 2020 at 8:40 AM Nils Amiet via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Hi Nils,
This is interesting, but unfortunately, doesn’t work. The 4-certificate
hierarchy makes the very basic, but understandable,
On Mon, Nov 16, 2020 at 8:40 AM Nils Amiet via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > Hi Nils,
> >
> > This is interesting, but unfortunately, doesn’t work. The 4-certificate
> > hierarchy makes the very basic, but understandable, mistake of assuming
> the
> >
Hello all,
My colleague André and I recently became aware of this problem and we explored
a new solution to it.
Please find our analysis below.
For a formatted version of this message with images inline, please find it
available at:
> Hi Nils,
>
> This is interesting, but unfortunately, doesn’t work. The 4-certificate
> hierarchy makes the very basic, but understandable, mistake of assuming the
> Root CA revoking the SICA is sufficient, but this thread already captures
> why it isn’t.
>
> Unfortunately, as this is key
Hi Nils,
This is interesting, but unfortunately, doesn’t work. The 4-certificate
hierarchy makes the very basic, but understandable, mistake of assuming the
Root CA revoking the SICA is sufficient, but this thread already captures
why it isn’t.
Unfortunately, as this is key to the proposal, it
Hello all,
My colleague Andre and I recently became aware of this problem and we explored
a new solution to it.
Please find our analysis below.
For a formatted version of this message with images inline, please find it
available at:
> Look, we've had Root CAs that have actively lied in this Forum,
> misrepresenting things to the community they later admitted they knew were
> false, and had previously been an otherwise CA in good standing (or at
> least, no worse standing than other CAs). A CA is a CA, and the risk is
>
Hi Ryan,
Obviously it is just my personal opinion of the facts made in a public
discussion forum. Like many other participants in this forum, I only
give my professional point of view as a PKI expert. This does not mean
that my opinion and my arguments are shared by the company where I work.
On Thu, Jul 16, 2020 at 12:45 PM Oscar Conesa via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> We should reposition the debate again, because a false reality is being
> assumed.
>
> Some people are assuming that this is the real situation: "A security
> incident has
We should reposition the debate again, because a false reality is being
assumed.
Some people are assuming that this is the real situation: "A security
incident has occurred due to the negligence of certain CAs, and this
security incident has got worse by the CAs' refusal to apply the
2020-07-15 12:30 GMT-04:00 Chema López via dev-security-policy
:
> El martes, 14 de julio de 2020 a las 9:02:01 UTC+2, Filippo Valsorda escribió:
>
>
> > This whole argument seems to lose track of the difference between CAs and
> > RPs. CAs have strict responsibilities to follow all the rules
On Wed, Jul 15, 2020 at 12:30 PM Chema López via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> So, an ICA or SCA cert. without keyUsage set to digitalSignature is not an
> OCSP Responder. Full stop.
False. Full stop.
I mentioned in my reply to Corey, but I think it's
El martes, 14 de julio de 2020 a las 9:02:01 UTC+2, Filippo Valsorda escribió:
> This whole argument seems to lose track of the difference between CAs and
> RPs. CAs have strict responsibilities to follow all the rules of the policies
> they committed to in order to be trusted by RPs. Full
2020-07-13 13:39 GMT-04:00 Chema Lopez via dev-security-policy
:
> From my point of view, the arguments at
> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13642.html
> are
> as incontestable as the ones stated by Corey Bonnell here:
>
>From my point of view, the arguments at
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13642.html
are
as incontestable as the ones stated by Corey Bonnell here:
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13541.html
.
RFC5280 and RFC6960 have to
On Sun, Jul 12, 2020 at 4:19 PM Oscar Conesa via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> To obtain this confidence, CAs must comply with all the requirements
> that are imposed on them in the form of Policies, Norms, Standards and
> Audits that are decided on an
On Sun, Jul 12, 2020 at 10:13:59PM +0200, Oscar Conesa via dev-security-policy
wrote:
> Some CAs may want to assume a leadership role in the sector and unilaterally
> assume more additional strict security controls. That is totally legitimate.
> But it is also legitimate for other CAs to assume a
On 12/7/20 2:21, Ryan Sleevi wrote:
I want to be clear here: CAs are not trusted by default. The existence
of a CA, within a Root Program, is not a blanket admission of trust in
the CA.
Here we have a deep disagreement: A CA within a Root Program must be
considered as a trusted CA by
On Sat, Jul 11, 2020 at 1:18 PM Oscar Conesa via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> f) For CAs that DO have sole control of the keys: There is no reason to
> doubt the CA's ability to continue to maintain the security of these
> keys, so the CA could reuse the
2020-07-11 13:17 GMT-04:00 Oscar Conesa via dev-security-policy
:
> f) For CAs that DO have sole control of the keys: There is no reason to
> doubt the CA's ability to continue to maintain the security of these
> keys, so the CA could reuse the keys by reissuing the certificate with
> the same
As a summary of the situation, we consider that:
a) Affected certificates do not comply with the norm (EKU OCSPSigning
without OCSP-no-check extension). They are misissued and they must be
revoked
b) This non-compliance issue has potential security risks in case of key
compromise and/or
On Fri, Jul 10, 2020 at 12:01 PM ccampetto--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Wouldn't be enough to check that OCSP responses are signed with a
> certificate which presents the (mandatory, by BR) id-pkix-ocsp-nocheck?
> I've not checked, but I don't think
Mr. zxzxzx9,
The "real" risk, which is illustrated through an adversary,
vulnerability, impact probability, risk mitigation strategy and the
residual risk doesn't matter. Hence is not discussed. I've yet to see a
comprehensive risk assessment on this matter.
The primary reason there is
On Wednesday, July 8, 2020 at 6:02:56 AM UTC+3, Ryan Sleevi wrote:
> The question is simply whether or not user agents will accept the risk of
> needing to remove the root suddenly, and with significant (e.g. active)
> attack, or whether they would, as I suggest, take steps to remove the root
>
On Wednesday, 8 July 2020 05:02:56 UTC+2, Ryan Sleevi wrote:
> On Tue, Jul 7, 2020 at 10:36 PM Matt Palmer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On Mon, Jul 06, 2020 at 10:53:50AM -0700, zxzxzx9--- via
> > dev-security-policy wrote:
> > > Can't the
On Tue, Jul 7, 2020 at 10:36 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Mon, Jul 06, 2020 at 10:53:50AM -0700, zxzxzx9--- via
> dev-security-policy wrote:
> > Can't the affected CAs decide on their own whether to destroy the
> > intermediate CA
On Mon, Jul 06, 2020 at 10:53:50AM -0700, zxzxzx9--- via
dev-security-policy wrote:
> Can't the affected CAs decide on their own whether to destroy the
> intermediate CA private key now, or in case the affected intermediate CA
> private key is later compromised, revoke the root CA instead?
On Thursday, July 2, 2020 at 12:06:22 AM UTC+3, Ryan Sleevi wrote:
> 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
On 06/07/2020 12:47, Rob Stradling via dev-security-policy wrote:
On 06/07/2020 06:11, Dimitris Zacharopoulos via dev-security-policy wrote:
IETF made an attempt to set an extention for EKU constraints
(https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/)
where Rob Stradling
On 06/07/2020 06:11, Dimitris Zacharopoulos via dev-security-policy wrote:
IETF made an attempt to set an extention for EKU constraints
(https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/)
where Rob Stradling made an indirect reference in
Summary of some OCSP client tests:
- `Root` is self signed, and does not have any EKU's
- 'ICA' is signed by 'Root' with the EKU ServerAuth and ClientAuth
- 'ICA 2' is signed by 'Root' with the EKU ServerAuth, ClientAuth and
OCSPSigning
- 'Server certificate' is signed by `ICA`
On 6/7/2020 11:39 π.μ., Paul van Brouwershaven via dev-security-policy
wrote:
As follow up to Dimitris comments I tested the scenario where a
sibling issuing CA [ICA 2] with the OCSP signing EKU (but without
digitalSignature KU) under [ROOT] would sign a revoked OCSP response for
[ICA] also
On 6/7/2020 11:03 π.μ., Ryan Sleevi via dev-security-policy wrote:
Yep. You have dismissed it but others may have not. If no other voices are
raised, then your argument prevails:)
I mean, it’s not a popularity contest:)
As others have highlighted already, there are times where people get
>
> Some tests were performed by Paul van Brouwershaven
> > https://gist.github.com/vanbroup/84859cd10479ed95c64abe6fcdbdf83d.
>
> As mentioned, those tests weren’t correct. I’ve provided sample test cases
> to several other browser vendors, and heard back or demonstrated that
> they’re
On Mon, Jul 6, 2020 at 3:38 AM Dimitris Zacharopoulos
wrote:
> On 6/7/2020 9:47 π.μ., Ryan Sleevi wrote:
>
> I can understand wanting to wait to see what others do first, but that’s
> not leadership.
>
>
> This is a security community, and it is expected to see and learn from
> others, which is
On 6/7/2020 9:47 π.μ., Ryan Sleevi wrote:
I can understand wanting to wait to see what others do first, but
that’s not leadership.
This is a security community, and it is expected to see and learn from
others, which is equally good of proposing new things. I'm not sure what
you mean by
On Mon, Jul 6, 2020 at 1:12 AM Dimitris Zacharopoulos via
dev-security-policy wrote:
> Ryan's response on
> https://bugzilla.mozilla.org/show_bug.cgi?id=1649939#c8 seems
> unreasonably harsh (too much "bad faith" in affected CAs, even of these
> CA Certificates were operated by the Root
I'd like to chime-in on this particular topic because I had similar
thoughs with Pedro and Peter.
I would like to echo Pedro's, Peter's and other's argument that it is
unreasonable for Relying Parties and Browsers to say "I trust the CA
(the Root Operator) to do the right thing and manage
On Mon, Jul 06, 2020 at 03:48:06AM +, Peter Gutmann wrote:
> Matt Palmer via dev-security-policy
> writes:
> >If you're unhappy with the way which your interests are being represented by
> >your CA, I would encourage you to speak with them.
>
> It's not the CAs, it's the browsers, and many
Matt Palmer via dev-security-policy
writes:
>If you're unhappy with the way which your interests are being represented by
>your CA, I would encourage you to speak with them.
It's not the CAs, it's the browsers, and many other types of clients. Every
Internet-enabled (meaning web-enabled)
On Saturday, July 4, 2020 at 3:43:22 PM UTC-7, Ryan Sleevi wrote:
> > Thank you for explaining that. We need to hear the official position from
> > Google. Ryan Hurst are you out there?
Although Ryan Sleevi has already pointed this out, since I was named
explicitly, I wanted to respond and
On Sun, Jul 5, 2020 at 5:30 PM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > From: dev-security-policy
> On Behalf Of Matt Palmer via dev-security-policy
> > At the limits, I agree with you. However, to whatever degree that there
> is complaining to
> From: dev-security-policy On
> Behalf Of Ryan Sleevi via dev-security-policy
> On Sat, Jul 4, 2020 at 10:42 PM Peter Bowen via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > As several others have indicated, WebPKI today is effectively a subset
> > of the more
> From: dev-security-policy On
> Behalf Of Matt Palmer via dev-security-policy
> Sent: Sonntag, 5. Juli 2020 06:36
>
> On Sat, Jul 04, 2020 at 07:42:12PM -0700, Peter Bowen wrote:
> > On Sat, Jul 4, 2020 at 7:12 PM Matt Palmer via dev-security-policy
> > wrote:
> > >
> > > > On Sat, Jul 04,
On Sat, Jul 04, 2020 at 07:42:12PM -0700, Peter Bowen wrote:
> On Sat, Jul 4, 2020 at 7:12 PM Matt Palmer via dev-security-policy
> wrote:
> >
> > On Sat, Jul 04, 2020 at 08:42:03AM -0700, Mark Arnott via
> > dev-security-policy wrote:
> > > I was informed yesterday that I would have to replace
On Sat, Jul 4, 2020 at 10:42 PM Peter Bowen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> As several others have indicated, WebPKI today is effectively a subset
> of the more generic shared PKI. It is beyond time to fork the WebPKI
> from the general PKI and strongly
On Sat, Jul 4, 2020 at 7:12 PM Matt Palmer via dev-security-policy
wrote:
>
> On Sat, Jul 04, 2020 at 08:42:03AM -0700, Mark Arnott via dev-security-policy
> wrote:
> > I was informed yesterday that I would have to replace just over 300
> > certificates in 5 days because my CA is required by
On Sat, Jul 04, 2020 at 08:42:03AM -0700, Mark Arnott via dev-security-policy
wrote:
> I was informed yesterday that I would have to replace just over 300
> certificates in 5 days because my CA is required by rules from the CA/B
> forum to revoke its subCA certificate.
The possibility of such an
On Sat, Jul 04, 2020 at 12:51:32PM -0700, Mark Arnott via dev-security-policy
wrote:
> I think that the lack of fairness comes from the fact that the CA/B forum
> only represents the view points of two interests - the CAs and the Browser
> vendors. Who represents the interests of industries and
On Sat, Jul 4, 2020 at 9:41 PM Peter Gutmann
wrote:
> Ryan Sleevi writes:
>
> >And they are accomodated - by using something other than the Web PKI.
>
> That's the HTTP/2 "let them eat cake" response again. For all intents and
> purposes, PKI *is* the Web PKI. If it wasn't, people wouldn't be
Ryan Sleevi writes:
>And they are accomodated - by using something other than the Web PKI.
That's the HTTP/2 "let them eat cake" response again. For all intents and
purposes, PKI *is* the Web PKI. If it wasn't, people wouldn't be worrying
about having to reissue/replace certificates that will
On Sat, Jul 4, 2020 at 9:21 PM Peter Gutmann
wrote:
> So the problem isn't "everyone should do what the Web PKI wants, no matter
> how
> inappropriate it is in their environment", it's "CAs (and protocol
> designers)
> need to acknowledge that something other than the web exists and
>
Eric Mill via dev-security-policy
writes:
>This is a clear, straightforward statement of perhaps the single biggest core
>issue that limits the agility and security of the Web PKI
That's not the biggest issue by a long shot. The biggest issue is that the
public PKI (meaning public/commercial
From: Eric Mill
Sent: Sonntag, 5. Juli 2020 00:55
To: Buschart, Rufus (SOP IT IN COR)
Cc: mozilla-dev-security-policy
; r...@sleevi.com;
mark.arno...@gmail.com
Subject: Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous
Delegated Responder Cert
On Sat, Jul 4, 2020 at 3:15 PM
Just chiming in as another subscriber and relying party, with a view to
speaking to the other subscribers on this topic.
To the extent that your use case is not specifically the WebPKI as pertains
to modern browsers, it was clear to me quite several years ago and gets
clearer every day: the
On Sat, Jul 4, 2020 at 3:15 PM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> ...especially since many of those millions of certificates are not even
> TLS certificates and their consumers never expected the hard revocation
> deadlines of the BRGs to be
On Sat, Jul 4, 2020 at 5:32 PM Mark Arnott via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Why aren't we hearing more from the 14 CAs that this affects. Correct me
> if I am wrong, but the CA/B form has something like 23 members?? An issue
> that affects 14 CAs
Dear Mark!
> -Original Message-
> From: dev-security-policy On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Samstag, 4. Juli 2020 20:06
>
> On Sat, Jul 4, 2020 at 12:52 PM mark.arnott1--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > This
Indeed, you’re welcome to do so, but I also don’t think these are easily
adjusted for or corrected. ETSI ESI is trying to solve a different need and
use case, and it’s structure and design reflect that.
And that’s ok! There’s nothing inherently wrong with that. They are trying
to develop a set of
On Saturday, July 4, 2020 at 3:01:34 PM UTC-4, Peter Bowen wrote:
> On Sat, Jul 4, 2020 at 11:06 AM Ryan Sleevi via dev-security-policy
> wrote:
> One of the challenges is that not everyone in the WebPKI ecosystem has
> aligned around the same view of incidents as learning opportunities.
> This
On Saturday, July 4, 2020 at 2:06:53 PM UTC-4, Ryan Sleevi wrote:
> On Sat, Jul 4, 2020 at 12:52 PM mark.arnott1--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>
> As part of this, you should re-evaluate certificate pinning. As one of the
> authors of that
Thank you Ryan for spending your 4th of July weekend answering my questions!
From my purely technical understanding, without knowing too much about the
history in the discussion between the ETSI community and you nor about the
“Überbau” of the audit schemes, I would believe that most of the
On Sat, Jul 4, 2020 at 11:06 AM Ryan Sleevi via dev-security-policy
wrote:
>
> On Sat, Jul 4, 2020 at 12:52 PM mark.arnott1--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > This is insane!
> > Those 300 certificates are used to secure healthcare information
On Sat, Jul 4, 2020 at 12:52 PM mark.arnott1--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> This is insane!
> Those 300 certificates are used to secure healthcare information systems
> at a time when the global healthcare system is strained by a global
> pandemic. I
On Friday, July 3, 2020 at 5:30:47 PM UTC-4, Ryan Sleevi wrote:
> On Fri, Jul 3, 2020 at 4:19 PM Peter Bowen wrote:
>
I feel compelled to respond here for the first time even though I have never
participated in CA/B forum proceeding and have never read through a single one
of the 55 BRs that
On Friday, July 3, 2020 at 5:30:47 PM UTC-4, Ryan Sleevi wrote:
> On Fri, Jul 3, 2020 at 4:19 PM Peter Bowen wrote:
>
I feel compelled to respond here for the first time even though I have never
participated in CA/B forum proceeding and have never read through a single one
of the 55 BRs that
Ryan,
I'm moving our particular discussions to Bugzilla.
I just want to clarify, again, that I'm not proposing to delay the revocation
of the offending CA certificate, what I'm proposing is to give more time to the
key destruction. Our position right now, is that the certificate would be
Pedro: I said I understood you, and I thought we were discussing in the
abstract.
I encourage you to reread this thread to understand why such a response
varies on a case by case basis. I can understand your *attempt* to balance
things, but I don’t think it would be at all appropriate to treat
On Sat, Jul 4, 2020 at 9:17 AM Buschart, Rufus
wrote:
> Dear Ryan!
>
> > From: dev-security-policy
> On Behalf Of Ryan Sleevi via dev-security-policy
> > Sent: Freitag, 3. Juli 2020 23:30
> > To: Peter Bowen
> > Cc: Ryan Sleevi ; Pedro Fuentes ;
> mozilla-dev-security-pol...@lists.mozilla.org
Thanks, Ryan.
I’m happy we are now in understanding to this respect.
Then I’d change the literally ongoing plan. We should have the new CAs
hopefully today. Then I would do maybe also today the reissuance of the bad
ones and I’ll revoke the offending certificates during the period.
Best.
On Sat, Jul 4, 2020 at 6:22 AM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> El viernes, 3 de julio de 2020, 18:18:49 (UTC+2), Ryan Sleevi escribió:
> > Pedro's option is to reissue a certificate for that key, which as you
> point
> > out, keeps the
Dear Ryan!
> From: dev-security-policy On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Freitag, 3. Juli 2020 23:30
> To: Peter Bowen
> Cc: Ryan Sleevi ; Pedro Fuentes ;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: SECURITY RELEVANT FOR CAs: The curious case of the
El viernes, 3 de julio de 2020, 18:18:49 (UTC+2), Ryan Sleevi escribió:
> Pedro's option is to reissue a certificate for that key, which as you point
> out, keeps the continuity of CA controls associated with that key within
> the scope of the audit. I believe this is the heart of Pedro's risk
>
On Fri, Jul 3, 2020 at 4:19 PM Peter Bowen wrote:
> >> For the certificates you identified in the beginning of this thread,
> >> we know they have a certain level of key protection - they are all
> >> required to be managed using cryptographic modules that are validated
> >> as meeting overall
On Fri, Jul 3, 2020 at 9:18 AM Ryan Sleevi wrote:
>
>
>
> On Fri, Jul 3, 2020 at 10:57 AM Peter Bowen wrote:
>>
>> While it may be viewed as best practice to have short lived responder
>> certificates, it must not be viewed as a hard requirement for the BRs
>> or for the Mozilla program. As you
On Fri, Jul 3, 2020 at 10:57 AM Peter Bowen wrote:
> While it may be viewed as best practice to have short lived responder
> certificates, it must not be viewed as a hard requirement for the BRs
> or for the Mozilla program. As you have pointed out previously, a
> browser could make this a
Ryan,
I have read through this thread and am also somewhat perplexed.
I want to be clear, I'm posting only for myself, as an individual, not
on behalf of any current or former employers.
On Fri, Jul 3, 2020 at 4:26 AM Ryan Sleevi via dev-security-policy
wrote:
> On Fri, Jul 3, 2020 at 3:24 AM
On Fri, Jul 3, 2020 at 10:04 AM Arvid Vermote
wrote:
> GlobalSign recognizes the reported security issue and associated risk, and
> is working on a plan to remediate the impacted CA hierarchies with first
> priority on terminating those branches that include issuing CA with private
> keys
On Fri, Jul 3, 2020 at 8:06 AM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Ryan,
> I don’t think I’m failing to see the security problem, but we evidently
> have different perception of the risk level for the particular case of
> internal delegation.
>
GlobalSign recognizes the reported security issue and associated risk, and
is working on a plan to remediate the impacted CA hierarchies with first
priority on terminating those branches that include issuing CA with private
keys outside of GlobalSign's realm. We will soon share an initial plan on
On 03/07/2020 12:24, Ryan Sleevi via dev-security-policy wrote:
The key destruction is the only way I can see being able to provide some
assurance that “things won’t go wrong, because it’s impossible for them to
go wrong, here’s the proof”
Ryan, distrusting the root(s) would be another way to
Ryan,
I don’t think I’m failing to see the security problem, but we evidently have
different perception of the risk level for the particular case of internal
delegation.
Anyway I will just cease in my intent and just act as it’s expected, looking as
guidance to the reaction of other CAs where
Hi Pedro,
I’m not sure how best to proceed here. It seems like we’ve reached a point
where you’re wanting to discuss possible ways to respond to this, as a CA,
and it feels like this should be captured on the bug.
I’m quite worried here, because this reply demonstrates that we’re at a
point
For those who are interested, in contrast to the direct EKU validation with
Test-Certificate, certutil does validate the OCSP signing EKU on the
delegated OCSP signing certificate but doesn't validate the
certificate chain for the OCSP signing EKU.
Full test script and output can be found here:
>
> Yes. But that doesn't mean we blindly trust the CA in doing so. And that's
> the "security risk".
But the point then is that a delegated responder that had the required
"noCheck" extension wouldn't be affected by this issue and CAs wouldn't need to
react, and therefore the issue to solve
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
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
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
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
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
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 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
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
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
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
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
1 - 100 of 117 matches
Mail list logo
