Elliptic Curve Cryptography (ECC) Support

Osiris · December 4, 2015, 10:43pm

Uch… I’m really, really trying to get something going here, but this elliptic curve stuff is just… Way above my head…

I’ve found a NSA document explaining the ‘Partial Public-Key Validation Routine’ on page 31… And it has a nice definition list… But even so… I’m no mathematician… I’m not getting any further than getting the ECC curve parameters from a named curve through openssl ecparam -noout -text -param_enc explicit -name secp384r1… And that’s not even in Go

tlussnig · December 16, 2015, 10:05pm

Is no one here that could fill the GoodKeyECDSA function in go ?

Osiris · December 16, 2015, 10:31pm

Perhaps it’s better to open an Issue @ GitHub?

Or even better, fork Boulder and start coding…

tlussnig · December 16, 2015, 10:37pm

Already opened https://github.com/letsencrypt/boulder/issues/158
Problem is i can code java , c, vs and even pascal or asm.
But i do not like to install an GO environment only for this.
I do not even know if there is an good IDE for this.

Osiris · December 19, 2015, 1:03am

NICE! Someone just made a PR with a lot of fancy code

eva2000 · December 19, 2015, 2:49am

thanks for the heads up

janitor · December 20, 2015, 12:06am

On the client side, there’s actually no current way to generate an ECDSA cert with the pyopenssl bindings that the letsencrypt script uses. There have been various pull requests to add bindings to do that since at least 2014, but the project (which seems rather essential) is actually kind of starved for maintainer-man-hours and none were ever merged. The latest pull request is getting their attention, though, however slowly.

But even when that gets merged to master, letsencrypt will presumably still need to open-code their own bindings to the exact same API to call in the places it needs? Since it won’t be in any distro-packaged version of pyopenssl for ages.

Osiris · December 20, 2015, 12:23am

But you could just generate a CSR with a ECC public key and let it sign by Let’s Encrypt…?

janitor · December 22, 2015, 1:53am

I’m aware of that? But a key appeal of letsencrypt is making simplicity, automation, and modern crypto the default experience. So presumably, it should eventually be at least able to, when the web server in question supports it, auto generate and install an ECDSA cert alongside an RSA cert as fallback for the ~5% of clients that need one. (Apache 2.2.26 and later can take both an ECDSA and RSA cert)

tlussnig · December 22, 2015, 6:13am

Webkey support it. And i only wait for the merge of the pull request for GoodKey check so that LE-Boulder support it too.
The keytype in webkey is instead of RSA there are
o "P-256"
o "P-384"
o "P-521"
Found in https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-6.2.1.1

Osiris · January 7, 2016, 11:19pm

Woohoo

Can’t wait until Boulder’s master branch is pushed to the staging branch and finally to the release branch

eva2000 · January 8, 2016, 1:46am

sweet thanks @Osiris for heads up !

Osiris · January 11, 2016, 9:50pm

And the master branch has been merged to the staging branch! https://github.com/letsencrypt/boulder/pull/1366

Unfortunately, Boulder still runs the old build: Boulder=( +34c1b83 Tue Jan 5 22:16:57 UTC 2016)

That’s probably the reason why my test ECDSA certificate still wasn’t supported

I guess someone has to give the staging server a kick (i.e. restart or something) before we can test our new ECDSA “Happy hacker fake CA” certificates

I guess Jeff doesn’t consider ECDSA keys very important: “This is mostly for some email fixes, but there’s some DNS error changes, too.”

jcjones · January 12, 2016, 6:53pm

Staging has been updated; the changelog is here:

Osiris · January 12, 2016, 9:25pm

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

jsha · January 12, 2016, 9:55pm

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).

Osiris · January 12, 2016, 10:06pm

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… Although I know it exists

I’ll try again soon and test some more!

I guess you’re refering to this default:

github.com

letsencrypt/boulder/blob/staging/cmd/config.go#L216


	Prefix string
}


// ConfigDuration is just an alias for time.Duration that allows
// serialization to YAML as well as JSON.
type ConfigDuration struct {
	time.Duration
}


// ErrDurationMustBeString is returned when a non-string value is
// presented to be deserialized as a ConfigDuration
var ErrDurationMustBeString = errors.New("cannot JSON unmarshal something other than a string into a ConfigDuration")


// UnmarshalJSON parses a string into a ConfigDuration using
// time.ParseDuration.  If the input does not unmarshal as a
// string, then UnmarshalJSON returns ErrDurationMustBeString.
func (d *ConfigDuration) UnmarshalJSON(b []byte) error {
	s := ""
	err := json.Unmarshal(b, &s)
	if err != nil {
		if _, ok := err.(*json.UnmarshalTypeError); ok {

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 ) and it’s in test/boulder-config.json again… But nowhere else

jsha · January 13, 2016, 5:16am

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.

jsha · January 13, 2016, 8:11pm

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

Osiris · January 13, 2016, 8:13pm

Well, I just tested it 10 minutes ago

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…?