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

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.

Re: SRVNames in name constraints

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

Re: FW: P-521

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

Re: P-521

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

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

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

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

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

Re: FW: P-521

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

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

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,

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

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: SRVNames in name constraints

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

Re: FW: P-521

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

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

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