Re: Machine- and human-readable format for root store information?

2017-07-06 Thread Kai Engert via dev-security-policy
On Mon, 2017-07-03 at 20:47 -0400, Ryan Sleevi wrote: > On Mon, Jul 3, 2017 at 11:53 AM, Kai Engert wrote: > > > > > I suspect, means anyone could plug > > > > in a modern CI > > > > CI meaning Continuous Integration ? > > > > Yes. Gerv's proposal rests on the idea of having a file committed t

Re: FW: P-521

2017-07-06 Thread Gervase Markham via dev-security-policy
On 05/07/17 14:49, Alex Gaynor wrote: > Is it really true that additional curves are just additional parameters? I That was my assumption; additional clue on this point would be welcome. Gerv ___ dev-security-policy mailing list dev-security-policy@list

Re: SRVNames in name constraints

2017-07-06 Thread Gervase Markham via dev-security-policy
On 05/07/17 15:10, Peter Bowen wrote: > The second bullet says “any”. As the rule for name constraints is that if > they are not present for a type, then any name is allowed, you have to > include name constraints for all four types. The issue comes down to the > definition of “working server”

Re: Machine- and human-readable format for root store information?

2017-07-06 Thread Gervase Markham via dev-security-policy
On 06/07/17 14:44, Kai Engert wrote: > My response was based on my interpretation of Gerv's suggestion, which I > understood as follows: > - certdata.txt remains the master, keeps maintained and published with NSS > - we define a new file format that's accepted as the standard for several > root

Re: Machine- and human-readable format for root store information?

2017-07-06 Thread Gervase Markham via dev-security-policy
On 05/07/17 18:08, Ryan Sleevi wrote: > That is, the difference between, say: > "label": "Verisign/RSA Secure Server CA" > And > CKA_LABEL "Verisign/RSA Secure Server CA" Not much, but you've picked the clearest part of certdata.txt to compare :-) > It isn't, because JSON can't. As Rob notes, yo

Re: FW: P-521

2017-07-06 Thread Ryan Sleevi via dev-security-policy
On Thu, Jul 6, 2017 at 10:46 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 05/07/17 14:49, Alex Gaynor wrote: > > Is it really true that additional curves are just additional parameters? > I > > That was my assumption; additional clue on this poin

RE: Root Store Policy 2.5: Call For Review and Phase-In Periods

2017-07-06 Thread Doug Beattie via dev-security-policy
Gerv, Moving to a new CA within 6 months is certain reasonable, but having enterprise customers also replace all certificates so the CA can be revoked within 6 months might be a bit short, especially since several of those months are over the holidays. Would you consider an approach were the C

Re: Machine- and human-readable format for root store information?

2017-07-06 Thread Ryan Sleevi via dev-security-policy
On Thu, Jul 6, 2017 at 10:57 AM, Gervase Markham wrote: > On 05/07/17 18:08, Ryan Sleevi wrote: > > That is, the difference between, say: > > "label": "Verisign/RSA Secure Server CA" > > And > > CKA_LABEL "Verisign/RSA Secure Server CA" > > Not much, but you've picked the clearest part of certdat

Re: P-521

2017-07-06 Thread J.C. Jones via dev-security-policy
On Tue, Jun 27, 2017 at 1:49 PM, Tom . wrote: > On 27 June 2017 at 11:44, Alex Gaynor wrote: > > I'll take the opposite side: let's disallow it before it's use expands > :-) > > But is that what we're talking about? I didn't think the question was > "Should we remove P-521 code from NSS" it's "Sh

Re: FW: P-521

2017-07-06 Thread Gervase Markham via dev-security-policy
On 06/07/17 16:20, Ryan Sleevi wrote: > compelling to add support for, and the security boundary between 192-bits > and 256-bits is somewhere in the "heat death of the universe" level > security (see > https://www.imperialviolet.org/2014/05/25/strengthmatching.html ) Perhaps this is the discussion

Re: SRVNames in name constraints

2017-07-06 Thread Ryan Sleevi via dev-security-policy
On Thu, Jul 6, 2017 at 10:48 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > What EKU(s) get used with certs containing SRVName? I confess I don't > understand this technology as well as I might. > Relevant to this group, id-kp-serverAuth (and perhap

Re: Root Store Policy 2.5: Call For Review and Phase-In Periods

2017-07-06 Thread Gervase Markham via dev-security-policy
On 06/07/17 16:31, Doug Beattie wrote: > Moving to a new CA within 6 months is certain reasonable, but having > enterprise customers also replace all certificates so the CA can be revoked > within 6 months might be a bit short, especially since several of those > months are over the holidays. W

WoSign new system passed Cure 53 system security audit

2017-07-06 Thread Danny 吴熠 via dev-security-policy
Hi all, This is Danny from WoSign. As per requirements, WoSign new issuing infrastructure has been completed and passed the Cure 53 white box security audit successfully in June 27. Cure53 is approved by Mozilla. The full audit report has been sent to Mozilla and other browsers. The Summar

Final removal of trust in WoSign and StartCom Certificates

2017-07-06 Thread asymmetric--- via dev-security-policy
Hello M.D.S.P., We've posted the following update regarding Chrome's treatment of WoSign and StartCom certificates to Chromium's Security-dev and net-dev groups. I've included both links below in case you'd like to follow the discussion there. https://groups.google.com/a/chromium.org/forum/#!to

Re: WoSign new system passed Cure 53 system security audit

2017-07-06 Thread Matt Palmer via dev-security-policy
On Fri, Jul 07, 2017 at 06:12:58AM +, Danny 吴熠 via dev-security-policy wrote: > As per requirements, WoSign new issuing infrastructure has been completed > and passed the Cure 53 white box security audit successfully in June 27. > Cure53 is approved by Mozilla. The full audit report has been