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

This topic is frustrating in that there seems to be a wide attempt by people to use one form of authentication (DV TLS) to verify another form of authentication (EV TLS). There seems an issue for people not being able to understand that a FREE service with a vey low bar in knowledge

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

On Mon, Mar 27, 2017 at 09:02:48PM +0100, Gervase Markham via dev-security-policy wrote: > On 27/03/17 16:08, Martin Heaps wrote: > > The next level is now that any business or high valued entity should > > over the course of the next few years implement EV certificates (many > > already have)

Question: Transfering the private key of an EV-approved CA

Are there existing rules, in the CABForum BRs, or in the Mozilla CA policy, that define under which circumstances the private key of an actively used EV approved root CA may be transferred to a different company, that hasn't been audited for EV compliance? As soon as the private key has been

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

On 27/03/17 16:08, Martin Heaps wrote: > The next level is now that any business or high valued entity should > over the course of the next few years implement EV certificates (many > already have) and that browsers should make EV certificates MORE > noticable on websites.. or we should

Re: EKU in Google sub CAs in violation of RFC5280?

On Mon, Mar 27, 2017 at 9:45 AM, tpg0007--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On https://pki.goog, all 5 of Google's newer subCAs have Extended Key > Usage extension of serverAuth and clientAuth, unusual for CAs but not > forbidden I guess. Their Key Usage

Re: Next CA Communication

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 _draft_ - the form parts will not work,

Re: Google Trust Services roots

It's probably my ignorance in these matters, but how does purchasing a root certificate affect revocation? 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

Re: Question: Transfering the private key of an EV-approved CA

On Mon, Mar 27, 2017 at 3:09 PM, Kai Engert via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Are there existing rules, in the CABForum BRs, or in the Mozilla CA > policy, that > define under which circumstances the private key of an actively used EV > approved > root CA

Re: Grace Period for Sub-CA Disclosure

On 27/03/2017 23:41, Rob Stradling wrote: On 27/03/17 22:37, Jakob Bohm via dev-security-policy wrote: It should also be made a requirement that the issued SubCA certificate is provided to the CCADB and other root programs before providing it to the SubCA owner/operator, That'd be a bit

Grace Period for Sub-CA Disclosure

[ Corresponding issue on GitHub: https://github.com/mozilla/pkipolicy/issues/67 ] Mozilla's CA Certificate Policy says: > All certificates that are capable of being used to issue new > certificates, that are not technically constrained, and that directly > or transitively chain to a certificate

Re: Google Trust Services roots

Clarified on the new thread you started, but I don't believe there's any inconsistency. Further details on the new thread you started. On Mon, Mar 27, 2017 at 10:02 AM, Roland Fantasia via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Anyone care to comment on the fact

Re: Grace Period for Sub-CA Disclosure

On 28/03/2017 00:16, Ben Wilson wrote: What if the third party needs to review the certificate to see whether it meets expected profile requirements? In some cases the certificate subject must first "accept" the certificate. -Original Message- From: dev-security-policy

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

Martin Heaps via dev-security-policy writes: >This topic is frustrating in that there seems to be a wide attempt by people >to use one form of authentication (DV TLS) to verify another form of >authentication (EV TLS). The overall problem is that browser

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

> 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 vs mom'n'pop

Re: Next CA Communication

Gerv, 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 staggered number (1 year -> 2 year certs,

Re: Next CA Communication

On Mon, Mar 27, 2017 at 10:18 AM, Ryan Sleevi wrote: > Gerv, > > 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

EKU in Google sub CAs in violation of RFC5280?

On https://pki.goog, all 5 of Google's newer subCAs have Extended Key Usage extension of serverAuth and clientAuth, unusual for CAs but not forbidden I guess. Their Key Usage extension contains the expected cert and CRL sign bits. Put together though they appear to be noncompliant with RFC 5280

Re: Google Trust Services roots

Anyone care to comment on the fact that Google's new subCAs under the GTS branding have inconsistent EKU and KU bits? What's more disturbing is FF doesn't make a fuss about it when connecting to the test sites (after adding the roots manually of course).