I’ll leave Jeremy’s comments as DigiCert’s most recent.
From: Eric Mill [mailto:e...@konklone.com]
Sent: Tuesday, October 24, 2017 2:34 PM
To: Ben Wilson
Cc: Doug Beattie ; Gervase Markham
; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Proposed policy change: require private pr
Ben, I think Gerv addressed Doug's concern and indicated that situation
wouldn't fall under this policy. If that's not accurate, it'd be worth an
on-list clarification.
On Tue, Oct 24, 2017 at 9:01 AM, Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I echo Dou
Godaddy LLC first became aware of possible ROCA vulnerability exposure on
Monday October 16th 2017 at 9:30am. The following are the steps we took for
detection, revocation, and the permanent fix of certificate provisioning:
• Monday October 16th 2017 AZ, first became aware of the ROCA
vul
Assuming the rule applies only to externally run third parties, I think it's
an excellent idea, but perhaps it should be a public pre-notification? As
you mentioned, the relationship will become transparent through CCDAB
submission and the audit report, so what's the advantage of keeping it
private
I echo Doug's concerns. I can see this process as being useful/helpful
where the private key is off-premises, but for vanity CAs where the operator
of the root CA maintains control of the private key the same as it does for
all other issuing CAs, I think this would introduce unnecessary additional
Hi Doug,
On 24/10/17 16:43, Doug Beattie wrote:
> I assume this applies equally to cross signing,
Yes.
> but not to "Vanity" CAs that are set up and run by the CA on behalf of a
> customer.
If you have physical control of the intermediate and control of
issuance, it doesn't apply.
Gerv
Gerv,
I assume this applies equally to cross signing, but not to "Vanity" CAs that
are set up and run by the CA on behalf of a customer. Is that accurate?
Doug
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozi
I think this would be of great benefit to the community.
1) It provides meaningful opportunity to ensure that the Mozilla-specific
program requirements are being met. The spate of misissuances discussed in
the past few months have revealed an unfortunately common trend of CAs not
staying aware of
One of the ways in which the number of organizations trusted to issue
for the WebPKI is extended is by an existing CA bestowing the power of
issuance upon a third party in the form of control of a
non-technically-constrained subCA. Examples of such are the Google and
Apple subCAs under GeoTrust, bu
9 matches
Mail list logo