Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

Nick Lamb via dev-security-policy writes: >In order for Symantec to reveal anybody's private keys they'd first need to >have those keys That's standard practice for many CAs, they generate the key and certificate for you and email it to you as a PKCS #12.

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

On Tuesday, March 28, 2017 at 3:46:05 PM UTC-4, Nick Lamb wrote: > In order for Symantec to reveal anybody's private keys they'd first need to > have those keys, which is already, IIRC forbidden in the BRs. So even proof > that Symantec routinely had these keys is a big deal. >From what I can

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

On Tuesday, March 28, 2017 at 11:08:08 PM UTC-4, uri...@gmail.com wrote: > For what it's worth, this is the latest post on facebook from the researcher. > https://www.facebook.com/cbyrneiv/posts/10155129935452436 > > The private key storage issue sounds like a reseller tool, like >

Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

For what it's worth, this is the latest post on facebook from the researcher. https://www.facebook.com/cbyrneiv/posts/10155129935452436 The private key storage issue sounds like a reseller tool, like https://www.thesslstore.com/ssltools/csr-generator.php and he found the private key was stored

Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

In order for Symantec to reveal anybody's private keys they'd first need to have those keys, which is already, IIRC forbidden in the BRs. So even proof that Symantec routinely had these keys is a big deal. The whole reason things like CSR signing exist is that public CAs have no reason to know

Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

https://www.bleepingcomputer.com/news/security/researcher-says-api-flaw-exposed-symantec-certificates-including-private-keys/ Does anyone have further information about this? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Next CA Communication

On 28/03/2017 16:13, Ryan Sleevi wrote: On Tue, Mar 28, 2017 at 10:00 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: In principle any source of information could change just one minute later. A domain could be sold, a company could declare bankruptcy, a

Re: Next CA Communication

On Tue, Mar 28, 2017 at 10:00 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > In principle any source of information could change just one minute > later. A domain could be sold, a company could declare bankruptcy, a > personal domain owner could die. >

Re: Next CA Communication

On 27/03/2017 11:10, Gervase Markham wrote: On 17/03/17 15:30, Gervase Markham wrote: The URL for the draft of the next CA Communication is here: https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2 Note that this is a

Re: Grace Period for Sub-CA Disclosure

On 28/03/17 13:32, Jakob Bohm via dev-security-policy wrote: On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote: Your case is missing the part where you explain why you think this is bad :-) What risks are associated with undisclosed dormant sub-CA certs? Actually, I think

Re: Grace Period for Sub-CA Disclosure

On 28/03/2017 12:21, Rob Stradling wrote: On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote: On 27/03/17 23:12, Andrew Ayer wrote: My interpretation of the policy is that a CA could delay disclosure for quite some time if the sub-CA is not used to issue certificates right away.

Re: Grace Period for Sub-CA Disclosure

On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote: On 27/03/17 23:12, Andrew Ayer wrote: My interpretation of the policy is that a CA could delay disclosure for quite some time if the sub-CA is not used to issue certificates right away. If the sub-CA is created as a backup that

Re: Over 14K 'Let's Encrypt' SSL Certificates Issued To PayPal Phishing Sites

On 27/03/17 23:15, mono.r...@gmail.com wrote: > Are there general proposals yet on how to distinguish phishing vs > legitimate when it comes to domains? (like apple.com vs app1e.com vs > mom'n'pop farmer's myapple.com) Not for those sorts of differences. There are in an IDN context:

Re: Grace Period for Sub-CA Disclosure

On 27/03/17 23:12, Andrew Ayer wrote: > My interpretation of the policy is that a CA could delay disclosure for > quite some time if the sub-CA is not used to issue certificates right > away. If the sub-CA is created as a backup that is never used, the > disclosure would never need to happen. >

Re: Google Trust Services roots

On 27/03/17 23:18, okaphone.elektron...@gmail.com wrote: > Will that remain the responsibility of GlobalSign for any existing > certificates that have been signed with these roots? (Those would be > intermediate certificates, if I understand correctly.) Or does > revocation also require signing,

Re: Next CA Communication

On 27/03/17 16:22, Ryan Sleevi wrote: > Would it be useful to thus also query whether there would be impact in > Mozilla applications failing to trust such certificates, but otherwise to > continue permitting their issuance. That is a good idea. How about: If you are unable to support a