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
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 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 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
>
> 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
All,
on behalf of the Accredited Conformity Assessment Bodies council we would like
to provide the following background information to the guideline “Verifying
ETSI Auditor Qualification” as stated here:
https://wiki.mozilla.org/CA/Audit_Statements#Verifying_ETSI_Auditor_Qualifications
The
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:
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
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
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
On Fri, Jul 3, 2020 at 6:14 AM clemens.wanko--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> All,
> on behalf of the Accredited Conformity Assessment Bodies council we would
> like to provide the following background information to the guideline
> “Verifying ETSI
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
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
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 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.
>
16 matches
Mail list logo
