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

On 05/07/17 18:08, Ryan Sleevi wrote: On Wed, Jul 5, 2017 at 4:32 AM Gervase Markham wrote: That is, the difference between, say: "label": "Verisign/RSA Secure Server CA" And CKA_LABEL "Verisign/RSA Secure Server CA" I would argue there isn't a meaningful difference for "human readability",

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

On Wed, Jul 5, 2017 at 4:32 AM Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 29/06/17 16:27, Ryan Sleevi wrote: > > Well, the current certdata.txt is a text file. Do you believe it's > human-readable, especially sans-comments? > > Human readability

Re: SRVNames in name constraints

> On Jul 5, 2017, at 4:23 AM, Gervase Markham via dev-security-policy > wrote: > > On 03/07/17 17:44, Peter Bowen wrote: >> We still need to get the policy changed, even with the ballot. As >> written right now, all name constrained certificates are no

Re: FW: P-521

On Wed, Jul 5, 2017 at 7:51 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I agree crypto algorithms are not "gotta catch 'em all", but the > algorithm is ECDH, which NSS must implement anyway to support P-256 and > P-384, and a curve is just another

Re: FW: P-521

I agree crypto algorithms are not "gotta catch 'em all", but the algorithm is ECDH, which NSS must implement anyway to support P-256 and P-384, and a curve is just another set of parameters to it. I also think that there is little value and there is potential confusion (as we have seen) in Mozilla

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

On 03/07/17 16:09, Kai Engert wrote: > I'd prefer a simple open source tool that operates on files, which can be used > from a command line, with a free license, e.g. MPL2. Of course. > If the intention is to define a file format that is shared with other groups, > who would be the owner of the

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

On 03/07/17 16:53, Kai Engert wrote: > On Wed, 2017-06-28 at 15:08 -0700, Ryan Sleevi via dev-security-policy wrote: >> On Wednesday, June 28, 2017 at 5:29:19 PM UTC-4, Gervase Markham wrote: >>> Well, the fact that we now use Git, > > NSS and the root store don't use Git, it uses HG/Mercurial.

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

On 29/06/17 16:27, Ryan Sleevi wrote: > Well, the current certdata.txt is a text file. Do you believe it's > human-readable, especially sans-comments? Human readability is, of course, a little bit of a continuum. You can open it in a text editor and get some sense of what's going on, but it's

Re: SRVNames in name constraints

On 03/07/17 17:44, Peter Bowen wrote: > We still need to get the policy changed, even with the ballot. As > written right now, all name constrained certificates are no longer > considered constrained. I'm not sure what you mean... What's the issue you are raising here? Gerv

Re: SRVNames in name constraints

On 03/07/17 17:29, Peter Bowen wrote: > "name constraints which do not allow Subject Alternative Names (SANs) > of any of the following types: dNSName, iPAddress, SRVName, > rfc822Name" > > SRVName is not yet allowed by the CA/Browser Forum Baseline > Requirements (BRs), so I highly doubt any CA

FW: P-521

Hi As CERTUM, we are not aware of any implementations which do not support P-521 (with the exception of BoringSSL where P-512 is disabled but not unsupported). All popular web browsers support all three P-256, P-384 and P521 curves. The P-521 certificates are imported correctly even to the

Re: ETSI auditors still not performing full annual audits?

Am Montag, 19. Juni 2017 21:15:09 UTC+2 schrieb Kathleen Wilson: > I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=1374381 about an > audit statement that I received for SwissSign. I have copied the bug > description below, because I am concerned that there still may be ETSI >