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

2017-05-11 Thread wangsn1206--- via dev-security-policy
在 2017年5月11日星期四 UTC+8下午5:58:00,Rob Stradling写道: > On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote: > > >> * CPS Appendix1: Certificate information of the publicly trusted CAs: Most > >> of the listed CAs can't be found in crt.sh - it would be great to get them > >> CT logged. > >>

Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-11 Thread Nick Lamb via dev-security-policy
Cory, from your point of view is there interest in being able to tell Requests "I want the no-compromises trust store" and accept a reduced compatibility in exchange for knowing that you're a little safer ? Right now, as a programmer I have three choices with Requests: Verify=True: The

Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-11 Thread Alex Gaynor via dev-security-policy
I think you left this a bit implicit Cory, so I figured it's worth spelling out: the strength of Mozilla's CA program, as a tool for making the web stronger, comes from having people using it, that's the carrot that forces people to meet our standards (also the fact that as a transparent, root

Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-11 Thread Cory Benfield via dev-security-policy
> On 11 May 2017, at 19:27, Gervase Markham wrote: > > On 11/05/17 18:05, Alex Gaynor wrote: >> I don't think Cory's arguing against browsers making use of these types of >> remediations, he just wants the non-browser clients to be able to >> participate as well :-) > > Sure.

Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-11 Thread Gervase Markham via dev-security-policy
On 11/05/17 18:05, Alex Gaynor wrote: > I don't think Cory's arguing against browsers making use of these types of > remediations, he just wants the non-browser clients to be able to > participate as well :-) Sure. I'm just heading off that argument at the pass :-) Gerv

Re: Symantec: Update

2017-05-11 Thread Gervase Markham via dev-security-policy
On 11/05/17 13:02, wiz...@ida.net wrote: > That said, it is fair point that the plan should spell out what happens if > symantec does not cooperate. I think we should cross that bridge when we come to it, which I hope we won't. Not that I'm not prepared to cross it, but there's no point

Re: Hunting for intermediates that still haven't been disclosed to CCADB

2017-05-11 Thread Gervase Markham via dev-security-policy
On 11/05/17 12:46, Rob Stradling wrote: > There's a "Created by" field (Username, Timestamp) and a "Last Modified > By" field (Username, Timestamp) in the CCADB, but neither of these > fields are currently provided in the public CSV reports that Mozilla > publishes. Rob: do you think you could

Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-11 Thread Alex Gaynor via dev-security-policy
On Thu, May 11, 2017 at 1:03 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Cory, > > On 11/05/17 15:21, Cory Benfield wrote: > > While I’m very supportive of this kind of remediation, it is not a > remediation that non-browser implementations can

Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-11 Thread Gervase Markham via dev-security-policy
Hi Cory, On 11/05/17 15:21, Cory Benfield wrote: > While I’m very supportive of this kind of remediation, it is not a > remediation that non-browser implementations can follow very easily. Unfortunately, this is not a good enough reason to remove graduate trust proposals from our arsenal of

Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-11 Thread Ryan Sleevi via dev-security-policy
On Thu, May 11, 2017 at 11:57 AM, Alex Gaynor via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Ryan, > > I think you've correctly highlighted that there's a problem -- the Mozilla > CA store is "designed" to be consumed from NSS, and CA-specific > remediations are a part

Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-11 Thread Alex Gaynor via dev-security-policy
Ryan, I think you've correctly highlighted that there's a problem -- the Mozilla CA store is "designed" to be consumed from NSS, and CA-specific remediations are a part of that (hash algorithms, maximum certificate lifetimes, and any number of other important technical controls). Unfortunately,

Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-11 Thread Ryan Sleevi via dev-security-policy
But if you use the trust database without using NSS, you no longer fit into any of the assumptions or security models with the discussions here on m.d.s.p. A good example of this would be EKU related misissuance. NSS, like CryptoAPI and several other platforms, has for the past 15 or so years

Re: Configuring Graduated Trust for Non-Browser Consumption

2017-05-11 Thread Cory Benfield via dev-security-policy
On Thursday, May 11, 2017 at 3:21:41 PM UTC+1, Cory Benfield wrote: > While I’m very supportive of this kind of remediation, it is not a > remediation that non-browser implementations can follow very easily. For > example, I run a downstream non-browser HTTP client[1] that by default uses a >

Configuring Graduated Trust for Non-Browser Consumption

2017-05-11 Thread Cory Benfield via dev-security-policy
All, While this ongoing discussion regarding Symantec is going on, I wanted to chime in quickly to make a suggestion about graduated trust. Many of the proposals that Mozilla, Google, and other teams running CA programs put forward in cases of CA misbehaviour is to transition a CA from

RE: Hunting for intermediates that still haven't been disclosed to CCADB

2017-05-11 Thread Ben Wilson via dev-security-policy
Both sets had been publicly disclosed through affirmative publishing in the repositories of the respective CAs--that's probably how your crawler found them, because I don't believe they are issuing SSL/TLS certificates. I thought I had disclosed the ones chaining to the DigiCert Orion Health

Re: Symantec: Update

2017-05-11 Thread Jonathan Rudenberg via dev-security-policy
> On May 10, 2017, at 11:52, Gervase Markham via dev-security-policy > wrote: > > I would appreciate people's comments on the details of the current draft. I don’t think that this proposal goes far enough. Symantec has demonstrated that they have no

Re: Symantec: Update

2017-05-11 Thread urijah--- via dev-security-policy
Possibly this is irrelevant, but I have some concerns on how Symantec, it seems to me, is willfully mischaracterizing their certificate compliance issues in their prepared remarks to their investors yesterday.[1] It makes it sound as if there are some generic certificate industry changes that

Questions for Symantec (2)

2017-05-11 Thread Gervase Markham via dev-security-policy
Dear Steve and Rick, This is an official communication from the Mozilla CA program requesting Symantec's answers to the following questions by close of business on Monday 15th May. Your answers will be posted in mozilla.dev.security.policy if you don't put them there yourselves. Your speedy

Re: Symantec: Update

2017-05-11 Thread wizard--- via dev-security-policy
Symantec, in previous blog posts on their site, has indicated that they will support their customers [1]. That said, it is fair point that the plan should spell out what happens if symantec does not cooperate. It seems appropriate to have the plan do what it says -- scheduled phase out of the

Re: Hunting for intermediates that still haven't been disclosed to CCADB

2017-05-11 Thread Rob Stradling via dev-security-policy
On 11/05/17 12:28, Kurt Roeckx via dev-security-policy wrote: On 2017-05-11 13:07, Rob Stradling wrote: It would seem that DigiCert noticed these 19 intermediates appear on https://crt.sh/mozilla-disclosures#undisclosed whilst I was asleep, because they've all now been disclosed to the CCADB.

Re: Hunting for intermediates that still haven't been disclosed to CCADB

2017-05-11 Thread Kurt Roeckx via dev-security-policy
On 2017-05-11 13:07, Rob Stradling wrote: It would seem that DigiCert noticed these 19 intermediates appear on https://crt.sh/mozilla-disclosures#undisclosed whilst I was asleep, because they've all now been disclosed to the CCADB. They should've been disclosed some time ago, however. Does

Hunting for intermediates that still haven't been disclosed to CCADB

2017-05-11 Thread Rob Stradling via dev-security-policy
Yesterday I knocked together a script that: scrapes a URL (or a list of URLs) for certificate files; then attempts to build a trust chain (using https://crt.sh/gen-add-chain) for each certificate found; then submits to some CT logs any trust chains that crt.sh hasn't previously seen. I've

Re: Find a 5-year certificate

2017-05-11 Thread userwithuid via dev-security-policy
> https://bugzilla.mozilla.org/show_bug.cgi?id=908125 . > > Gerv Wow, embarrassingly weak google-fu on my part... Sorry and thanks! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

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

2017-05-11 Thread Rob Stradling via dev-security-policy
On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote: * CPS Appendix1: Certificate information of the publicly trusted CAs: Most of the listed CAs can't be found in crt.sh - it would be great to get them CT logged. Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation

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

2017-05-11 Thread wangsn1206--- via dev-security-policy
Hi Andrew, Thanks for the comments. Please check our following responses. > * Please don't protect your PDFs for printing > We have removed the restrictions on the printing of the PDF documents and re-uploaded them to the BUG, these documents are available at:

Re: Find a 5-year certificate

2017-05-11 Thread Gervase Markham via dev-security-policy
On 10/05/17 18:12, userwithuid wrote: > Limiting to 60 months could be done right now as a sanity check and shouldn't > cause any problems, right? https://bugzilla.mozilla.org/show_bug.cgi?id=908125 . Gerv ___ dev-security-policy mailing list