Elliptic Curve Cryptography (ECC) Support


#75

Staging has been updated; the changelog is here:


#76

There was actually another update an hour ago by @jsha: https://github.com/letsencrypt/boulder/compare/34c1b83...698b91c

Unfortunately I get the following error:

Invalid key in certificate request :: ECDSA curve P-384 not allowed

:scream:


#77

We generally set up our code so that it can be deployed with no change in behavior, and then switched on with config flags. If you check the code closely, you’ll see that the default mode is old-style (RSA only). I’ll have our ops team flip on ECDSA in staging sometime soon (today).


#78

Yeah, I thought it would be somewhere in a database of some sort, but I couldn’t actually find the code responsible for getting the config out of such DB… :stuck_out_tongue: Although I know it exists :wink:

I’ll try again soon and test some more!

I guess you’re refering to this default:

Though I can’t really find how config.AllowedSigningAlgos would be filled… The GitHub search only gives a result of the definition of it in the type Config struct, but I’ve got no clue how that could be enough to get it frome a DB into the struct (but I don’t know Go either :stuck_out_tongue: ) and it’s in test/boulder-config.json again… But nowhere else :open_mouth:


#79

You’ve got it exactly right: It gets filled from test/boulder-config.json, in cmd/shell.go. However, in production we have a different boulder-config.json that gets loaded.


#80

Okay, we’ve flipped the config flag and ECDSA certificates using the P256 and P384 curves may now be issued from staging. Please test!


#81

Well, I just tested it 10 minutes ago :laughing:

Will try again!

Hmm, no cigar… Still ECDSA curve P-384 not allowed I’m afraid…

Also, prime256v1 is not allowed, so it’s not P-384 specific: ECDSA curve P-256 not allowed

Adding brainpoolP512r1 (obviously a not supported, but prime curve) to the CSR gives the following error: Error: urn:acme:error:malformed :: The request message was malformed :: Error unmarshaling certificate request
Same for “sect283r1 : NIST/SECG curve over a 283 bit binary field”, so I guess everything unknown is hard to unmarshall…?


ECDSA testing on staging
#82

so the ultra paranoid p521 doesnt? too bad.


#83

From the first tests currently nothing work on staging, so no longer an unmarshall issue
ECDSA curve P-384 not allowed
ECDSA curve P-256 not allowed
ECDSA curve P-521 not allowed


#84

Now it works on staging :slight_smile:


#85

Sample result for an EC Certificate (T rating because of statging)
This show that the certifcate works :slight_smile:
https://dev.ssllabs.com/ssltest/analyze.html?d=ec384.suche.org&hideResults=on


#86

Yup working here too --csr and webroot-path webroot-map errors thanks to an assist from @Osiris


#87

@jsha is there already an timeline when this new feature will become available in produktion ?


#88

would be really nice to know.

then I can get close-to-tinfoil encryption more or less (rather less) easily.


#89

suspect need some documentation done first :slight_smile:


#90

Well, as long as the official client doesn’t support it, you might say it’s an easter egg if it’s pushed to production without documentation :wink: :smiley: After all, it’s not like the --csr switch is documentated in the User Guide :slightly_smiling:


#91

true, though when i mean production I mean on client side support too :slight_smile:


#92

@Osiris No for the CA the definition is the protocol. And there was no place in the protocol that say only rsa may be used. So it is not an easter egg.


#93

I don’t quite understand what you mean with that… I just meant if staging would now be pushed to production, it would be a hidden feature… Or no, not even an hidden feature… Perhaps you mean that. Before this, ECDSA’s simply weren’t implemented and Boulder responded with an error message, but there’s not really a reason to deny ECDSA keys… So no documentation would be required, unless it’s somewhere stated only RSA keys can be used…


#94

Just a question about the ACME protocol with RSA and ECC.
Now (in staging) there is only a RSA signing key, so if I send a CSR i can get

  1. a RSA-signed RSA certificate
  • a RSA-signed ECC certificate

When (hopefully) LE will have an ECC based signing key there will be 4 possibilities:

  1. a RSA-signed RSA certificate
  • a RSA-signed ECC certificate
  • an ECC-signed RSA certificate
  • an ECC-signed ECC certificate

1 and 4 will be the most popular ones, but will 2 and 3 be supported?
If no the server can simply look into the CSR and give the client a RSA-signed certificate if the public key is RSA (1) and an ECC-signed certificate if the public key is ECC (4).
If yes the ACME protocol need a flag in order to let the server know if the client want a RSA-signed certificate or an ECC-signed certificate.