Re: Other Curves

On Wed, 1 Feb 2017 22:38:54 + Jeremy Rowley wrote: > Some of these curves are considered much better than the NIST curves > (well, that’s what I’ve read anyway). Overall they have mostly the same weaknesses than the NIST curves. There are differences in detail,

RE: Other Curves

I'd be happy with those as alternatives to SuiteB. They aren't requested as often as the others, but enough that we could push customers worried about using a NIST curve that way (assuming I can get the HSM dealers to support the curve). -Original Message- From: Hanno Böck

Re: Other Curves

https://tools.ietf.org/html/draft-ietf-curdle-pkix-03 needs to move forward first. It is currently in working group last call. https://tools.ietf.org/html/rfc8032 is now published, which replaces I-D.irtf-cfrg-eddsa, so that removes the last dangling reference from curdle-pkix. We also need to

Re: Other Curves

Unfortunately, despite the Bitcoin community's enthusiasm, secp256k1 has very bad side-channel properties: https://eprint.iacr.org/2014/161.pdf https://bugzilla.mozilla.org/show_bug.cgi?id=1051509 Overall, I agree with Ryan that proliferation in this space is to be avoided. I expect that the

Issuer field in the CRL should be byte-for-byte equivalent with that in cert

All, I've added another Potentially Problematic Practice, as follows. https://wiki.mozilla.org/CA:Problematic_Practices#Issuer_Encoding_in_CRL The encoding of the Issuer field in the CRL should be byte-for-byte equivalent with the encoding of the Issuer in the certificate; that is, using the

Re: Suspicious test.com Cert Issued By GlobalSign

Thank you for undertaking this investigation Doug and for sharing what you found. I am glad to hear that GlobalSign had taken action to make similar issuances less likely in the future even before Andrew reported this. In hindsight probably it would have been helpful to suggest to all members

Re: Other Curves

That seems altogether a bad idea for the ecosystem. Current (and presently proposed) Mozilla policy does not allow them. Nor are they supported in Mozilla NSS anymore (and their previous support was not one you should use for security-critical purposes). Nor are they supported in other UAs. I'm

Re: Other Curves

On Wed, Feb 01, 2017 at 11:51:48PM +0100, Hanno Böck wrote: > On Wed, 1 Feb 2017 22:38:54 + > Jeremy Rowley wrote: > > > Some of these curves are considered much better than the NIST curves > > (well, that’s what I’ve read anyway). > > Overall they have mostly

RE: Other Curves

Both preferably, but I’d accept at the EE level. Primarily secp256k1 and brainpool, but mostly secp256k1. From: Richard Barnes [mailto:rbar...@mozilla.com] Sent: Wednesday, February 1, 2017 3:35 PM To: Jeremy Rowley Cc:

RE: Other Curves

That’s a pretty vague argument against adding some curves. With that logic, we’d never have moved away from MD5 hash as moving away would have disrupted the ecosystem… From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Wednesday, February 1, 2017 3:46 PM To: Jeremy Rowley

Re: Other Curves

Perhaps I might suggest "No earlier than an RFC defining how they're used in certificates is approved"? :) Is there a reason you wouldn't just bring this up in the Forum? We (Google) would be happy to support a ballot - once the RFC has reached the consensus process - for allowing it for leaves.

RE: Other Curves

Some of these curves are considered much better than the NIST curves (well, that’s what I’ve read anyway). With how many new curves there are (many with an international flavor), it’d be nice if Mozilla considered some of the new curves and added them if appropriate. Brainpool is supported in

Re: Other Curves

On Wed, Feb 1, 2017 at 2:38 PM, Jeremy Rowley wrote: > Some of these curves are considered much better than the NIST curves > (well, that’s what I’ve read anyway). With how many new curves there are > (many with an international flavor), it’d be nice if Mozilla

RE: Other Curves

Works for me. Any idea on when Mozilla is planning to permit Curve22519 and Curve448? I’d like to plan for that date. From: Richard Barnes [mailto:rbar...@mozilla.com] Sent: Wednesday, February 1, 2017 4:04 PM To: Jeremy Rowley Cc: Hanno Böck ;

Other Curves

I know the use of other ECC curves comes up often, but I couldn't recall where Mozilla landed on using other ECC curves. Requests for secp256k1 and brainpool curves are increasing rapidly. If Mozilla updated its policy, we could start using these curves for client certs, even if the baseline

Re: Other Curves

Do you mean for signing by the CA, or as the key in the EE cert? On Wed, Feb 1, 2017 at 2:26 PM, Jeremy Rowley wrote: > I know the use of other ECC curves comes up often, but I couldn't recall > where Mozilla landed on using other ECC curves. Requests for secp256k1

RE: Other Curves

I think I should mention that I suggested secp256k1 for blockchain reasons... -Original Message- From: Hanno Böck [mailto:ha...@hboeck.de] Sent: Wednesday, February 1, 2017 3:52 PM To: Jeremy Rowley Cc: r...@sleevi.com;

Re: [FORGED] Re: Other Curves

Ryan Sleevi writes: >Current (and presently proposed) Mozilla policy does not allow them. Nor are >they supported in Mozilla NSS anymore (and their previous support was not one >you should use for security-critical purposes). Nor are they supported in >other UAs. I should point

Re: Useful Heuristics

On Tuesday, 31 January 2017 09:27:30 CET Peter Bowen wrote: > On Tue, Jan 31, 2017 at 5:50 AM, Hubert Kario wrote: > > On Monday, 30 January 2017 23:48:51 CET Peter Bowen wrote: > >> See notes inline about known cities with numbers in their name. > >> > >> On Mon, Jan 30, 2017

RE: Suspicious test.com Cert Issued By GlobalSign

Hi Gerv, We've researched the audit events around the certificate: https://crt.sh/?sha256=9d503e7c6c4fb6e6d7436c07ff445b95214871ea13ac1cb3b0d7abbce9be6cfb The domain test.com was inadvertently used in a certificate request and issuance - here are the audit events for the managed service