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. It seems to be more common among
lesse
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 te
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
> https://www.the
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 wit
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 a
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
http
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
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.
>
Y
On 28/03/2017 15:20, Ryan Sleevi wrote:
On Tue, Mar 28, 2017 at 8:52 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
While this has apparently already passed, the earlier date for
requiring revalidation is going to be a problem for any CA that has
already
On Tue, Mar 28, 2017 at 8:52 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> While this has apparently already passed, the earlier date for
> requiring revalidation is going to be a problem for any CA that has
> already sold a large number (thousands, mil
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 _dra
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 it
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.
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 i
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:
http://unicode
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.
>
>
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, an
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 compreh
* mono riot:
>> I've been wondering if CT is a good tool for things like safe
>> browsing to monitor possible phishing sites and possibly detect
>> them faster.
>
> Are there general proposals yet on how to distinguish phishing vs
> legitimate when it comes to domains? (like apple.com vs app1e.com
On 27/03/17 16:18, Ryan Sleevi wrote:
> I'm curious whether you would consider 18 months an appropriate target for
> a deprecation to 1 year certificates. That is, do you believe a transition
> to 1 year certificates requires 24 months or 18 months, or was it chosen
> simply for its appeal as a sta
20 matches
Mail list logo