Re: Incidents involving the CA WoSign

On Wed, Aug 24, 2016 at 6:08 AM, Gervase Markham wrote: > Dear m.d.s.policy, > > Several incidents have come to our attention involving the CA "WoSign". > Mozilla is considering what action it should take in response to these > incidents. This email sets out our understanding of

Re: Cerificate Concern about Cloudflare's DNS

On Mon, Sep 12, 2016 at 6:42 AM, Peter Kurrasch wrote: > I was thinking of more the server (cloud) side of things. I'm not familiar > enough with Cloudflare's service, but I imagine that if I have a server set > up I will also have access to my private key. If so, I now have

Re: Sanctions short of distrust

On Tue, Sep 13, 2016 at 7:53 AM, Ryan Sleevi wrote: > We also see a variety of domains using certs from either for purposes that > are ostensibly not relevant to browsers - a frequent dead give-away is a cert > for autodiscover.[example.com] - which is an Exchange

Re: Cerificate Concern about Cloudflare's DNS

On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei wrote: > So when I delegated the DNS service to Cloudflare, Cloudflare have the > privilege to issue the certificate by default? Can I understand like that? I would guess that they have a clause in their terms of service or

Re: Sanctions short of distrust

On Mon, Sep 12, 2016 at 7:02 PM, Ryan Sleevi <r...@sleevi.com> wrote: > On Monday, September 12, 2016 at 6:09:05 PM UTC-7, Peter Bowen wrote: >> This would have two advantages: >> 1) Helps limit blast radius of whitelisting a name/domain > > I'm unclear what you mean

Re: Sanctions short of distrust

On Mon, Sep 12, 2016 at 2:46 PM, Ryan Sleevi wrote: > To that end, I'm going to offer one more suggestion for consideration: > G) Distrust with a Whitelist of Hosts > > The issue with C is that it becomes easily inflated by issuing certificates, > even if they're not used; that

Re: Sanctions short of distrust

On Mon, Sep 12, 2016 at 2:46 PM, Ryan Sleevi wrote: > > Consider if we start with the list of certificates issued by StartCom and > WoSign [...] Extract the subjectAltName from every one of these certificates, > and then compare against the Alexa Top 1M. This yields more than

Re: SHA-1 exception First Data

On Wed, Oct 5, 2016 at 10:02 PM, Michael Ströder wrote: > Dean Coclin wrote: >> First Data's customers don't use browsers so Firefox can disable SHA-1 >> tomorrow >> and not affect them. > > So why to have your CA certificate trusted in Firefox's cert DB? > >> First Data

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

On Tue, Oct 4, 2016 at 6:29 AM, Rob Stradling wrote: > On 04/10/16 13:18, Nick Lamb wrote: >> On Tuesday, 4 October 2016 11:14:01 UTC+1, Rob Stradling wrote: >>> Neither. I'd like to run cablint over all certs pre-issuance, but >>> unfortunately it's not practical to

Re: cablint/certlint updated

b.com/awslabs/certlint/pull/38 > > -- Eric > > On Sat, Oct 8, 2016 at 5:59 PM, Peter Bowen <pzbo...@gmail.com> wrote: >> >> I pushed a major update to cablint/certlint today. It contains a >> massive performance improvement thanks to Matt Palmer who turned the >> asn1

cablint/certlint updated

I pushed a major update to cablint/certlint today. It contains a massive performance improvement thanks to Matt Palmer who turned the asn1c code into an in-process extension, allowing replacement of numerous fork/exec calls per certificate. This has moved the performance on my test system to 596

Re: Include Symantec-brand Class 1 and Class 2 Root Certs

On Thu, Oct 6, 2016 at 3:57 PM, Richard Barnes wrote: > I seem to recall we had some discussion a while back about what criteria > should be applied to email CAs. Where did we end up on that? I don't believe anything was settled. There is one small item in the CA policy:

Re: Incident Report - certificate with 'sb' as a SAN:dnsName

On Thu, Oct 6, 2016 at 7:33 AM, Peter Bowen <pzbo...@gmail.com> wrote: > On Thu, Oct 6, 2016 at 7:29 AM, Rob Stradling <rob.stradl...@comodo.com> > wrote: >> On 04/10/16 19:39, Peter Bowen wrote: >>> On Tue, Oct 4, 2016 at 6:29 AM, Rob Stradling <rob.stradl..

Re: Incidents involving the CA WoSign

is hosted by Qihoo 360 > > https://pierrekim.github.io/blog/2016-02-16-why-i-stopped-using-startssl-because-of-qihoo-360.html > and > that you're the sole director of StartCom, it's hard for me to believe > that > you "don't know anything" about Qihoo 360. >

Re: Incidents involving the CA WoSign

On Sat, Sep 10, 2016 at 6:43 PM, Richard Wang wrote: > We will publish a more comprehensive report in the next several days that > will attempt to cover most / all issues. > Thanks for your patience. Richard, Thank you in advance for working on a comprehensive report. I

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

On Wed, Aug 3, 2016 at 2:45 PM, Kathleen Wilson wrote: > This request from Guangdong Certificate Authority (GDCA) is to include the > "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and > enabled EV treatment. > > * CA Hierarchy: This root certificate

Re: Incidents involving the CA WoSign

Richard, As someone pointed out on Twitter this morning, it seems that the PSC notification for Startcom UK was filed recently: https://s3-eu-west-1.amazonaws.com/document-api-images-prod/docs/UdxHYAlFj6U9DNs6VBJdnIDv4IQAWd4YKYomMERO_2o/application-pdf Were you unaware of this filing?

Re: Incidents involving the CA WoSign

Richard, I'm still somewhat confused. Can you review the following statements and either confirm they are true or specify they are not true and correct them? On 15 December 2015: 1) סטארט קומארשל בע"מ ("Start Commercial Limited" or StartCom IL) was a registered company in Israel. 2) 王高华

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

On Mon, Sep 19, 2016 at 1:56 AM, wrote: > Dear Peter, Thanks for your comments! We think that there are some good > suggestions for our work. We’ll take notes and do better in our future work. > > We have discussed these questions with our auditor. Here are our reply to

Audit requirements

Kathleen, Gerv, Richard and m.d.s.p, In reviewing the WebTrust audit documentation submitted by various CA program members and organizations wishing to be members, it seems there is possibly some confusion on what is required by Mozilla. I suspect this might also span to ETSI audit

WoSign and StartCom audit reports

As hinted at in my earlier email about what is expected in audit reports, I've been looking at WebTrust audit reports from many CAs in the Mozilla program and those applying to be in the program. Since there has been lots of discussion about WoSign and Startcom recently, I took a look at their

Re: Audit requirements

On Fri, Sep 23, 2016 at 5:29 AM, Kurt Roeckx <k...@roeckx.be> wrote: > On 2016-09-23 00:57, Peter Bowen wrote: >> >> Kathleen, Gerv, Richard and m.d.s.p, >> >> In reviewing the WebTrust audit documentation submitted by various CA >> program members and organi

Re: WoSign and StartCom audit reports

On Fri, Sep 23, 2016 at 10:46 AM, Eddy Nigg <eddy_n...@startcom.org> wrote: > On 09/23/2016 05:53 AM, Peter Bowen wrote: >> >> Review of StartCom audit reports >> for the period 1 January 2015 to 31 December 2015 >> >> Good: >> - Uses AICPA standards

Re: Incidents involving the CA WoSign

Richard, I'm having a really hard time reconciling what you describe with what is found in the CT logs and what I observed today when doing as you suggested and getting a cert from https://buy.wosign.com/free/. I pulled all the WoSign certificates from CT logs that have embedded SCTs. There are

Re: Incidents involving the CA WoSign

On Wed, Sep 21, 2016 at 9:10 PM, Richard Wang wrote: >> Are you saying out of over 40,000 orders over the last year, only six >> "stopped to move forward" for a period of a week or more and these happen to >> all have been ordered on Sunday, December 20, 2015 (China time)? >

Re: Comodo issued a certificate for an extension

On Sun, Oct 2, 2016 at 9:49 AM, Nick Lamb wrote: > > The second thing obviously is that they do have exactly the "rule" Richard > Wang described, and they believe this was justified under the BRs old 3.2.2.4 > method 7 (which isn't a method at all, it's basically a

Re: Comodo issued a certificate for an extension

On Sun, Oct 2, 2016 at 6:23 PM, Nick Lamb <tialara...@gmail.com> wrote: > On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen wrote: > >> Under the new rules, which should be in >> effect as of 1 March 2017, validating www. will not be a valid >> method of showing

Re: Comodo issued a certificate for an extension

to be an Authorization Domain Name requested by the applicant ? > However, according to section 3.2.2.4, each FQDN listed in the > certificate is required to be validated using AT LEAST one of the > methods only. > > Thanks, > > Man > > > On 10/3/2016 3:53 AM, Peter Bow

Re: Comodo issued a certificate for an extension

On Sun, Sep 25, 2016 at 9:19 AM, Nick Lamb wrote: > On Sunday, 25 September 2016 15:35:07 UTC+1, mono...@gmail.com wrote: >> am I the only one who a) thinks this is slightly problematic and b) is >> surprised that the cert still isn't revoked? > > I don't know enough about

Re: Updating Production Common CA Database

How about CA ID? On Sep 26, 2016 16:26, "Kathleen Wilson" wrote: > > "Certificate ID" seems like entirely the wrong name for this field, > > given that it [SHA-256(der(subject) + der(spki))] doesn't actually > > identify a unique certificate! > > Indeed, the whole point of

Re: Apple's response to the WoSign incidents

On Sat, Oct 1, 2016 at 6:40 AM, wrote: > Do you have a link to that process and is it automated. Reason is I have a > few hundred startSSL certs that my clients rely on. I can't speak for the specific process Apple is using, but in general you can use https://crt.sh/ or

Re: Deficiencies in the Web PKI and Mozilla's shepherding thereof, exposed by the WoSign affair

On Mon, Oct 3, 2016 at 5:24 PM, Jakob Bohm wrote: > On 03/10/2016 20:41, Kyle Hamilton wrote: >> WoSign is known to be cross-signed by several independent CAs (as well as > >> 2. There is only One Certificate Path that can be proven in TLS, which >> prevents risk management

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

> On Oct 29, 2016, at 2:23 PM, Han Yuwei wrote: > > 在 2016年10月28日星期五 UTC+8下午9:23:01，wangs...@gmail.com写道： >> We are not intended to cover-up anything since we had disclosed every change >> to the Chinese version CP/CPS at once after the auditor reviewed. >> The

Re: StartCom & Qihoo Incidents

On Sat, Oct 29, 2016 at 2:29 PM, Percy wrote: > So 400 million Chinese users[1] are left vulnerable to MITM by even a casual > attacker and we cannot do anything about it!? As stated previously, it is not for one browser to tell another how to behave and the CA/Browser

Re: Action on undisclosed intermediates

On Tue, Nov 8, 2016 at 10:17 AM, Gervase Markham <g...@mozilla.org> wrote: > Hi Peter, > > On 08/11/16 16:53, Peter Bowen wrote: >> Can the "undisclosed" list be broken down further into "CA not >> disclosed at all" versus "missing disclos

Re: Action on undisclosed intermediates

On Tue, Nov 8, 2016 at 11:05 AM, Gervase Markham <g...@mozilla.org> wrote: > On 08/11/16 18:25, Peter Bowen wrote: >> No, the problem is that the Issuer reported their subCA but Salesforce >> links the audit info to certificates not to CAs. In the above >> example, t

Re: Action on undisclosed intermediates

On Tue, Nov 8, 2016 at 8:18 AM, Gervase Markham wrote: > Of course, if intermediates aren't disclosed, we can't be certain what > they are, but crt.sh has a good idea of many of them: > https://crt.sh/mozilla-disclosures#undisclosed > > There is also a list on that page of certs

Re: SHA-1 issuances in 2016 That Chain to Mozilla Roots

> On Nov 5, 2016, at 6:49 AM, Ryan Sleevi wrote: > > On Saturday, November 5, 2016 at 2:06:00 AM UTC-7, Gervase Markham wrote: >> On 04/11/16 21:23, Ryan Sleevi wrote: >>> If there's concerns about GAs - would it be best to reply on this thread or >>> start a new one per-CA?

Re: Can we require id-kp-serverAuth now?

y=digicert.com@lists.mozilla > .org] On Behalf Of Peter Bowen > Sent: Wednesday, November 9, 2016 11:50 AM > To: Gervase Markham <g...@mozilla.org> > Cc: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Can we require id-kp-serverAuth now? > > On Wed, Nov 9, 20

Re: Can we require id-kp-serverAuth now?

On Wed, Nov 9, 2016 at 1:58 AM, Gervase Markham wrote: > So, it is now possible to change Firefox to mandate the presence of > id-kp-serverAuth for EE server certs from Mozilla-trusted roots? Or is > there some reason I've missed we can't do that? Here are some certs that

Proposal to define applicability of BRs and expectations of CAs

Given that there is a lack of clarity on when the CABF BRs apply, and that applicability of the BRs is outside the scope of the BRs, I propose the following text to clarify and help CAs understand the expectations of operating a publicly trusted CA. Thanks, Peter Requirements for a CA in the

Re: Proposal to define applicability of BRs and expectations of CAs

On Fri, Nov 11, 2016 at 6:03 AM, Dimitris Zacharopoulos wrote: > (something weird happened in the reply all. Re-sending). > > On 11/11/2016 3:45 μμ, Gervase Markham wrote: >> >> On 11/11/16 13:26, Dimitris Zacharopoulos wrote: >>> >>> Although this is very helpful so that people

Re: StartCom & Qihoo Incidents

On Fri, Oct 14, 2016 at 4:32 PM, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > Peter Bowen <pzbo...@gmail.com> writes: > >>The CA/Browser Forum is not a regulatory body. They publish guidelines but >>do not set requirements nor regulate compliance. > > It

Re: Remediation Plan for WoSign and StartCom

On Thu, Oct 20, 2016 at 1:57 PM, Kathleen Wilson wrote: > 1) Distrust certificates with a notBefore date after October 21, 2016 which > chain up to the following affected roots. If additional back-dating is > discovered (by any means) to circumvent this control, then

Re: StartCom & Qihoo Incidents

On Sat, Oct 22, 2016 at 9:08 PM, Peter Gutmann wrote: > popcorn writes: > >>There were comments admonishing StartCom and WoSign for not reporting change >>of ownership in a timely manner. >> >>I am not sure if this has been reported earlier,

Re: Draft Email - Non-Disclosed SubCAs

onduct a search. > ________ > From: Peter Bowen > Sent: ‎10/‎21/‎2016 10:08 AM > To: Kathleen Wilson > Cc: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Draft Email - Non-Disclosed SubCAs > > On Thu, Oct 20, 2016 at 1:09 PM, Kathleen Wilso

Re: Remediation Plan for WoSign and StartCom

On Tue, Oct 18, 2016 at 2:33 PM, Ryan Sleevi wrote: > > I think there's some confusion there. CNNIC's audits "expire" on Feb "29" > 2017 (I say "29" because of ambiguity on "1 year"). That is, within 3 months > of Feb "29", 2017, CNNIC would be expected to provide a new audit,

Re: Action on undisclosed intermediates

On Tue, Nov 8, 2016 at 8:18 AM, Gervase Markham wrote: > I'd like to take some action about persistent failures to properly > disclose intermediates. The deadline for this was June, and CAs have had > a number of reminders, so there's no excuse. > > Of course, if intermediates

Re: Technically Constrained Sub-CAs

On Mon, Nov 14, 2016 at 3:46 AM, Gervase Markham wrote: > > If this is the only privacy mechanism available for 6962bis, I suspect > we will see a lot more TCSCs about, particularly if CAs figure out ways > to mint them at scale within the letter of the BRs and other

Re: Proposal to define applicability of BRs and expectations of CAs

On Fri, Nov 11, 2016 at 4:42 AM, Gervase Markham <g...@mozilla.org> wrote: > Hi Peter, > > On 11/11/16 01:42, Peter Bowen wrote: >> Given that there is a lack of clarity on when the CABF BRs apply, and >> that applicability of the BRs is outside the scope of the BRs,

Re: Technically Constrained Sub-CAs

On Mon, Nov 14, 2016 at 7:14 AM, Gervase Markham <g...@mozilla.org> wrote: > On 14/11/16 14:00, Peter Bowen wrote: >> It is very easy to mint TCSCs at scale without violating the letter or >> the spirit of the BRs and other requirements. > > I guess I didn't mean to imp

Re: Technically Constrained Sub-CAs

On Mon, Nov 14, 2016 at 8:51 AM, Jakob Bohm <jb-mozi...@wisemo.com> wrote: > On 14/11/2016 16:31, Peter Bowen wrote: >> >> On Mon, Nov 14, 2016 at 7:14 AM, Gervase Markham <g...@mozilla.org> wrote: >>> >>> On 14/11/16 14:00, Peter Bowen wrote: >

Re: SHA-1 Phase-out

On Tue, Nov 15, 2016 at 7:25 AM, Kurt Roeckx wrote: > > - If it's an enterprise root they need to switch to SHA-2 This is a lot easier said than done for many organizations. Depending on the CA software this might be a small configuration change or might involve a very large

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

On Tue, Nov 15, 2016 at 3:02 AM, wrote: > > Because we misunderstand that we only need to provide the related chapters of > CP/CPS in English, and non-related sections are not required. We are terribly > sorry that we misinterpreted your requirement and upload an

Re: Cerificate Concern about Cloudflare's DNS

On Wed, Nov 2, 2016 at 9:38 AM, Jakob Bohm <jb-mozi...@wisemo.com> wrote: > On 02/11/2016 17:08, Peter Bowen wrote: >> >> On Wed, Nov 2, 2016 at 8:26 AM, Tom Ritter <t...@ritter.vg> wrote: >>> >>> On 2 November 2016 at 09:44, Jakob Bohm <jb-moz

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

On Sun, Oct 30, 2016 at 11:34 PM, wrote: > wangs...@gmail.com於 2016年10月31日星期一 UTC+8下午2時22分05秒寫道： >> 在 2016年10月28日星期五 UTC+8上午8:19:43，Percy写道： >> > "When facing any requirements of laws and regulations or any demands for >> > undergoing legal >> > process of court and

Re: Update on transition of the Verizon roots and issuance of SHA1 certificates

On Thu, Nov 3, 2016 at 11:28 AM, Jeremy Rowley wrote: > This email is intended to gather public and browser feedback on how we are > handling the transitioning Verizon's customers to DigiCert and share with > everyone the plan for when all non-DigiCert hosted sub CAs

Re: Cerificate Concern about Cloudflare's DNS

On Wed, Nov 2, 2016 at 8:26 AM, Tom Ritter wrote: > On 2 November 2016 at 09:44, Jakob Bohm wrote: >> The only thing that might be a CA / BR issue would be this: > > There's been (some) mention that even if a user moves off Cloudflare, > the CA is not

Re: WoSign: updated report and discussion

On Tue, Oct 11, 2016 at 7:08 AM, Nick Lamb wrote: > > Some of the major root trust stores (e.g. Microsoft, Apple) also operate > their own root CA, which they include in that store, for internal purposes at > least. I believe none of them is trusted by another root trust

Re: Taiwan GRCA Root Renewal Request

On Thu, Sep 22, 2016 at 12:57 AM, <horn...@gmail.com> wrote: > Peter Bowen於 2016年9月20日星期二 UTC+8下午11時53分29秒寫道： >> On Fri, Sep 16, 2016 at 2:00 PM, Kathleen Wilson <kwil...@mozilla.com> wrote: >> > >> > * CA Hierarchy: Diagram of CA Hierarchy: http://gr

Re: Taiwan GRCA Root Renewal Request

On Sat, Dec 3, 2016 at 9:22 AM, Jakob Bohm wrote: > On 03/12/2016 09:34, lcchen.ci...@gmail.com wrote: >> >> In CA/Browser Forum 34th F2F meeting, the minutes is in >> https://cabforum.org/2015/03/11/2015-03-11-minutes-of-cupertino-f2f-meeting-34/. >> Li-Chun Chen (me) of

Re: Taiwan GRCA Root Renewal Request

On Sun, Dec 4, 2016 at 7:26 AM, 王文正 <capuchin...@gmail.com> wrote: > Gervase Markham於 2016年12月4日星期日 UTC+8下午6時27分55秒寫道： >> On 03/12/16 17:42, Peter Bowen wrote: >> > As to the inclusion request, I think Mozilla should reject this >> > request and add a clear rule t

Re: Misissued/Suspicious Symantec Certificates

"auditing standards that underlie the accepted audit schemes found in Section 8.1" This is obviously a error in the BRs. That language is taken from Section 8.1 and there is no list of schemes in 8.1. 8.4 does have a list of schemes: 1. WebTrust for Certification Authorities v2.0; 2. A national

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang via dev-security-policy wrote: > As I understand, the BR 4.2.1 required this: > > “The CA SHALL develop, maintain, and implement documented procedures that > identify and require additional verification activity

Re: Google Trust Services roots

Ryan, Both Gerv and I posted follow up questions almost two weeks ago. I know you have been busy with CT days. When do you expect to have answers available? Thanks, Peter On Fri, Feb 10, 2017 at 2:01 AM, Gervase Markham via dev-security-policy wrote: >

Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

quot;, "Microsoft" is not a high risk domain, then I don’t > know which domain is high risk domain, maybe only "github". > > Best Regards, > > Richard > > -Original Message- > From: Peter Bowen [mailto:pzbo...@gmail.com] > Sent: Thurs

Re: Google Trust Services roots

Ryan, Thank you for the quick reply. My comments and questions are inline. On Thu, Feb 9, 2017 at 11:55 AM, Ryan Hurst via dev-security-policy wrote: > Peter, > > Thank you very much for your, as always, thorough review. > > Let me start by saying I agree

Re: Google Trust Services roots

On Thu, Feb 9, 2017 at 9:56 PM, Richard Wang via dev-security-policy wrote: > I can't see this sentence > " I highlight this because we (the community) see the occasional remark like > this; most commonly, it's directed at organizations in particular

Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

On Thu, Feb 9, 2017 at 7:41 AM, Gervase Markham via dev-security-policy wrote: > On 09/02/17 14:32, Gijs Kruitbosch wrote: >> Would Mozilla's root program consider changing this requirement so that >> it *does* require public disclosure, or are there

Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

On Mon, Feb 13, 2017 at 4:14 AM, Gervase Markham via dev-security-policy wrote: > On 10/02/17 12:40, Inigo Barreira wrote: >> I see many "should" in this link. Basically those indicating "should notify >> Mozilla" and "should follow the physical relocation

Re: (Possible) DigiCert EV Violation

On Mon, Feb 27, 2017 at 1:41 PM, Ryan Sleevi via dev-security-policy wrote: > The EV Guidelines require certificates issued for .onion include the > cabf-TorServiceDescriptor extension, defined in the EV Guidelines, as part of > these certificates. This is

Re: Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates

On Thu, Mar 23, 2017 at 12:54 PM, Jakob Bohm via dev-security-policy wrote: > > The above message (and one by Symantec) were posted to the > mozilla.dev.security.policy newsgroup prior to becoming aware of > Google's decision to move the discussion to its

Re: Symantec: Next Steps

On Fri, Mar 24, 2017 at 9:06 AM, Ryan Sleevi via dev-security-policy wrote: > (Wearing an individual hat) > > On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: >> >> One common scenario

Re: Next CA Communication

On Fri, Mar 17, 2017 at 8:30 AM, Gervase Markham via dev-security-policy wrote: > The URL for the draft of the next CA Communication is here: >

Re: Next CA Communication

On Mon, Mar 20, 2017 at 4:52 PM Rob Stradling <rob.stradl...@comodo.com> wrote: > On 20/03/17 17:07, Peter Bowen via dev-security-policy wrote: > > >> B) Your attention is drawn to the cablint and x509lint tools, which you > >> may wish to incorporate into your

Re: Next CA Communication

On Mon, Mar 20, 2017 at 10:43 AM, Jeremy Rowley via dev-security-policy wrote: > A) Does your CA have an RA program, whereby non-Affiliates of your company > perform aspects of certificate validation on your behalf under contract? If > so, please tell us

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

> On Mar 31, 2017, at 6:01 PM, Daniel Baxter via dev-security-policy > wrote: > > On Saturday, April 1, 2017 at 6:27:27 AM UTC+11, Jakob Bohm wrote: >> Oh, come on, if that's her job title, that's her job title, and at any >> CA, that is actually an

Re: Symantec Issues List

On Fri, Mar 31, 2017 at 4:38 PM, Ryan Sleevi via dev-security-policy wrote: > On Fri, Mar 31, 2017 at 2:39 PM, Gervase Markham wrote: > >> As we continue to consider how best to react to the most recent incident >> involving Symantec, and given that there is

Re: Email sub-CAs

On Thu, Apr 13, 2017 at 9:33 AM, douglas.beattie--- via dev-security-policy wrote: > On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote: >> On 13/04/17 14:23, Doug Beattie wrote: >> > There is no statement back to scope or corresponding

Re: Google Trust Services roots

On Wed, Mar 8, 2017 at 10:14 PM, Richard Wang wrote: > Why we setup one EV OID for all roots is that we use the same policy for all > EV SSL certificate no matter it is issued by which root. The policy OID is > unique ID > > If Google use the GlobalSign EV OID, and

Re: Google Trust Services roots

> Best Regards, > > Richard > > -Original Message- > From: Peter Bowen [mailto:pzbo...@gmail.com] > Sent: Friday, March 10, 2017 2:16 PM > To: Richard Wang <rich...@wosign.com> > Cc: Ryan Sleevi <r...@sleevi.com>; Gervase Markham <g...@mozilla.org>; >

Re: Symantec: Next Steps

On Wed, Mar 8, 2017 at 6:50 AM, Ryan Sleevi <r...@sleevi.com> wrote: > > On Wed, Mar 8, 2017 at 9:23 AM, Peter Bowen wrote: > >> > Does this make it clearer the point I was trying to make, which is that >> > they're functionally equivalent - due to the fac

Re: Google Trust Services roots

Richard, I'm afraid a few things are confused here. First, a single CA Operator may have multiple roots in the browser trust list. Each root may list one or more certificate policies that map to the EV policy. Multiple roots that follow the same policy may use the same policy IDs and different

Re: Google Trust Services roots

On Thu, Mar 9, 2017 at 11:02 PM, Jakob Bohm via dev-security-policy wrote: > > Of all these, Starfield seems to be the only case where a single CA > name now refers to two different current CA operators (GoDaddy and > Amazon). All the others are cases of

Re: DigiCert BR violation

On Mon, Mar 13, 2017 at 6:08 PM, Nick Lamb via dev-security-policy wrote: > On Monday, 13 March 2017 21:31:46 UTC, Ryan Sleevi wrote: >> Are you saying that there are one or more clients that require DigiCert to >> support Teletext strings? > > Can we stop

Re: Symantec: Next Steps

On Wed, Mar 8, 2017 at 5:08 AM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Wed, Mar 8, 2017 at 12:57 AM, Peter Bowen via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: >> >> If the DTP is only performing the functions that Jakob lists,

Re: Google Trust Services roots

Ryan, I appreciate you finally sending responses. I hope you appreciate that they are clearly not adequate, in my opinion. Please see the comments inline. On Mon, Mar 6, 2017 at 6:02 PM, Ryan Hurst wrote: > First, let me apologize for the delay in my response, I have had a

Re: Google Trust Services roots

One more question, in addition to the ones in my prior response: On Mon, Mar 6, 2017 at 6:02 PM, Ryan Hurst wrote: > rmh: I just attached two opinion letters from our auditors, I had previously > provided these to the root programs directly but it took some time to get >

Re: Maximum validity of pre-BR certificates

On Sat, Mar 4, 2017 at 12:22 PM, Daniel Cater via dev-security-policy wrote: > On Saturday, 4 March 2017 20:14:09 UTC, Jeremy Rowley wrote: >> 1.0 is not the definitive version any more. As of 2015‐04‐01, Section >> 6.3.2 prohibits validity periods longer

Re: Symantec: Next Steps

On Tue, Mar 7, 2017 at 9:27 PM, Ryan Sleevi via dev-security-policy wrote: > On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: ]> >> For example, an RA whose sole involvement is to receive a

Re: Symantec Issues List

On Sun, Apr 2, 2017 at 9:36 PM, Ryan Sleevi <r...@sleevi.com> wrote: > > On Sun, Apr 2, 2017 at 11:14 PM Peter Bowen via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: >> >> On Fri, Mar 31, 2017 at 11:39 AM, Gervase Markham via >> d

Re: Grace Period for Sub-CA Disclosure

On Mon, Apr 3, 2017 at 1:45 PM, Jakob Bohm via dev-security-policy wrote: > On 03/04/2017 21:48, Ryan Sleevi wrote: >> >> On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >>> >>> >>> The

Re: Grace Period for Sub-CA Disclosure

On Mon, Apr 3, 2017 at 12:36 PM, Jakob Bohm via dev-security-policy wrote: > On 03/04/2017 19:24, Ryan Sleevi wrote: >> >> On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >>> >>> >>>

Re: Symantec Issues List

On Fri, Mar 31, 2017 at 11:39 AM, Gervase Markham via dev-security-policy wrote: > As we continue to consider how best to react to the most recent incident > involving Symantec, and given that there is a question of whether it is > part of a pattern of

Re: Criticism of Google Re: Google Trust Services roots

On Fri, Mar 31, 2017 at 8:18 AM, Gervase Markham via dev-security-policy wrote: > On 30/03/17 15:01, Peter Kurrasch wrote: >> By "not new", are you referring to Google being the second(?) >> instance where a company has purchased an individual root cert from

Re: Final Decision by Google on Symantec

On Mon, Jul 31, 2017 at 7:17 AM, Jakob Bohm via dev-security-policy wrote: > On 31/07/2017 16:06, Gervase Markham wrote: >> >> On 31/07/17 15:00, Jakob Bohm wrote: >>> >>> - Due to current Mozilla implementation bugs, >> >> >> Reference, please? >> > > I am

Re: Final Decision by Google on Symantec

On Thu, Jul 27, 2017 at 11:14 PM, Gervase Markham via dev-security-policy wrote: > Google have made a final decision on the various dates they plan to > implement as part of the consensus plan in the Symantec matter. The > message from blink-dev is included

Re: DigiCert-Symantec Announcement

On Wed, Aug 2, 2017 at 8:10 PM, Peter Gutmann via dev-security-policy wrote: > Jeremy Rowley via dev-security-policy > writes: > >>Today, DigiCert and Symantec announced that DigiCert is acquiring the >>Symantec CA

Re: DigiCert-Symantec Announcement

On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy wrote: > Today, DigiCert and Symantec announced that DigiCert is acquiring the > Symantec CA assets, including the infrastructure, personnel, roots, and > platforms. At the same time,

Re: SRVNames in name constraints

On Tue, Aug 15, 2017 at 8:01 AM, Jeremy Rowley wrote: > I realize use of underscore characters was been debated and explained at the > CAB Forum, but I think it's pretty evident (based on the certs issued and > responses to Ballot 202) that not all CAs believe certs

<    1   2   3   4   >