p-256 curve considered insecure.

[nimbius]

Subject of the issue

the default P256 curve is considered...untrustworthy at best. http://safecurves.cr.yp.to Daniel J. Bernstein and Tanja Lange have found several issues with P256. Coefficients are generated by hashing an unexplained seed, and specially selected domain parameters from a state actor make is highly suspect. https://en.wikipedia.org/wiki/NIST#Controversy_regarding_NIST_standard_SP_800-90

Your environment

• OS - Arch
• Version -

Additional context

ED25519 should be made the safe default for curves when possible. P-384 also harbors many of the same concerns as 256. is there a documented method to select this at init time?

[mmalone]

Hey @nimbius,

Thanks for the feedback. Yes, we're aware of and sensitive to concerns about implementation difficulties and unexplained magic numbers related to the NIST curves. If advanced persistent threats like the NSA are in your threat model you should definitely take both of these issues very seriously.

Before continuing, can I clarify what you're asking for? Are you trying to set the key type for your root & intermediate cert(s) during CA initialization (i.e., during step ca init)? I think that is possible today, but you're right that it could be made easier. I'd be happy to help with a workaround for now if you can confirm that's what you're trying to do.

Returning to NIST curves vs safe curves (ECDSA vs EdDSA)... the problem is that the safe curves aren't as well supported. If you're able to use EdDSA (e.g., Ed25519), you should. Consensus is, it's better crypto. But, for the vast majority of people, this will not be their weakest link. Most people are already relying on both ECDSA P-256 and RSA for their security (e.g., I think G Suite single sign-on uses both at various points). If you create a root and intermediate using Ed25519, then later on you add some PKI relying parties that can't use Ed25519, you're gonna have a bad time.

[maraino]

@nimbius To start a CA using Ed25519, just replace the certificate and keys with the ones created with:

# Root
step certificate create --profile root-ca --kty OKP "My Root CA" root_ca.crt root_ca.key
# Intermediate
step certificate create --profile intermediate-ca --kty OKP --ca root_ca.crt --ca-key root_ca.key  "My Intermediate CA" intermediate_ca.crt intermediate_ca.key

And then for example, if you want to sign a leaf using the CA:

# Create a CSR
step certificate create --csr --kty OKP my.host.net myhost.csr myhost.key
# Sign the CSR
step ca sign myhost.csr myhost.crt

Edit: Even with that the CA will automatically generate an P-256 certificate for itself.

[maraino]

@mmalone a good approach would be to be able to define the key type in step ca init, and then use the key type of the root certificate by default in step ca certificate.

[mmalone]

@maraino yea we could do that. I'm not sure what support is like for EdDSA keys in root & intermediate signing certificates though. I'm pretty sure EdDSA support was only recently added for TLS... the RFC might still be in draft, even.

If most people are unable to actually use EdDSA keys in practice, because browsers and other TLS clients don't support them, then there's no point in making this easy. In fact, making it easy could be dangerous because folks may spin up an EdDSA root without context on compatibility issues, then end up with a PKI that fails in weird and obscure ways for some subset of PKI relying parties.

I could be wrong about the level of support in practice today. If I am wrong -- if browsers and libraries and whatnot have all been upgraded at this point -- that would change my mind. Unfortunately I don't have time right now to go and assess clients. It's hard to even imagine how that would work, since there are so many clients out there. What's the threshold? Do we care about Python 2.x? What versions of Java are we interested in? Seems like a quagmire until someone can say "it's implemented pretty much everywhere" with a straight face.

Honestly, I'm more interested in the ability to specify key type as you've described for folks who want to use RSA. That's (unfortunately) probably less niche than EdDSA. Given the NIST curve concerns and the EdDSA compatibility issues, RSA is still a reasonable choice. If we're gonna do it for RSA I suppose it would sort of lame of us to not also support EdDSA, but I'd want to think about ways we could surface the compatibility issue in the UI.

[polarathene]

the RFC might still be in draft, even.

Still in draft, third iteration due to expire this September.

Unfortunately I don't have time right now to go and assess clients.

I had a brief look, as I was recalling EdDSA had been added into TLS 1.3(RFC 8446 - Aug 2018) (which I later realized is unrelated to PKI support for usage with root/intermediate certificates which the linked draft is covering?), I came across BearSSL TLS 1.3 support, and they mention support for EdDSA is lacking, so I wouldn't be surprised if that is the case elsewhere too.

When the RFC is complete and we're at a point that certs could be signed with EdDSA, do clients need to do additional support for that specifically or just implementing TLS 1.3 support for EdDSA?

[maraino]

Just a small summary of features @ v0.15.0:

• step-ca supports TLS 1.3
• step ca init creates ECDSA P-256 root and intermediates, but they can be replaced by Ed25519 ones using step certificate create --kty OKP. [1]
• step-ca certificate (for https) is always P-256. [2]
• step ca certificate supports --kty OKP to create Ed25519 leaf certificates.
• Ed25519 is supported.
• Ed448 is not, currently, there's not a large adoption of this curve, and it has not been added to Go. [3]

So we would need to:

1. Add --kty to step ca init
2. Probably change the way we generate/renew the step-ca certificate to use for example the same type of key than the intermediate.
3. We don't have at this moment plans to support Ed448.

[nodakai]

Can you also support ca init --crv P-384 as a mitigation against QC