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
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
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
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
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
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
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
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
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
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
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
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
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”
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
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
15 matches
Mail list logo