Elliptic Curve Cryptography (ECC) Support

but well you have to setup VPN to start and for some or another reason I needed another software on my PC to connect to the VPN of an earlier workplace,a dn well I dont wannt to need to install extra software, portable and browser-services 4ever

1 Like

yeah i guessā€¦ although depending on OS some have native support i.e Windows and L2TP IPSEC VPN native support so no added software

ah someone bring this back to ECC talk hehe

1 Like

@My1 You would not the only one who would use ECDSA with RSA key.
MAy java implementation would be ready to generate ecsda csr and select the cert based on browser support.

1 Like

Since LEā€™s plans for ECC has already been stated by @jsha, there is no need for further discussion on the merits of ECC certificates or "+1"s.

Letā€™s Encrypt is not against supporting ECC certs, or arguing that they dont have benefits. They have a firm position: they will have support in 2016.

3 Likes

agreedā€¦ but would more discussion and thus interest and demand lead to them moving up the timetable for ECC support ? :smiley: :sunglasses: :wink:

1 Like

No, i dont believe it would. There was a thread requesting Wildcard support which similarly carried on and was locked by @schoen, who requested the behavior stopped. The staff has more than enough to do with the public beta coming this week. They dont need more to worry about and I dont think the forum should be cluttered up with off-topic discussion and unhelpful requests for features which have already been promised.

1 Like

well unlike wildcard thread, this thread has a more constructive and informative feel to it - would be useful for folks wanting to understand ECC matters ? or start a new thread for ECC discussions :slight_smile:

1 Like

Can't say I agree with you on this.

As you can read above, there was some misconception about the need for a separate ECDSA keying ceremony, which is not needed et cetera.

I think this thread can be used to assist Let's Encrypt in their efforts by brainstorming and perhaps helping the developers getting started. Who knows :slight_smile:

2 Likes

Hi, there is an difference. At least for some points.

  1. One of the result of the discussion in this topic was that jsha recognized that EC support dies not require an signed EC
    root or intermediate, For the start it is OK only to sign the EC-CSR with an RSA-Intermediate
  2. As long as the browser supports both key types also the ocsp does not require EC.
    These two point mean so much simplification that the implementation will be in the near future since only an key check is required. Instead of new key party for the HSM module with new cross sign etcā€¦
    So not quite the same as wildcard discussion.
3 Likes

I agree there is not currently any need to lock this thread, so long as people stay on topic and avoid +1 posts. :smile_cat:

3 Likes

well I would say allow signing of ECs using RSA Root/intermediate right now and make the EC Root and stuff later.

1 Like

I think both can wait for 2016. Itā€™s just another month until itā€™s 2016. :stuck_out_tongue_winking_eye:

Generally itā€™s better to have robust support for one thing than having not that good support for multiple things. More features will be added later anyway.

3 Likes

[quote=ā€œkelunik, post:53, topic:34ā€]
I think both can wait for 2016. Itā€™s just another month until itā€™s 2016
[/quote] indeed 31.00001 days till Jan 2016 (Aussie timezone wise :slight_smile: )

1 Like

[quote="kelunik, post:53, topic:34, full:true"]
I think both can wait for 2016. It's just another month until it's 2016. ;-P[/quote]

It's not like the keying ceremony is planned for Januari 1st 2016 09:00 GMT or something, right? :wink: No, it's probably going to be more like April 2016.. (But I've got no clue ofcourse.. Just guessing here, but it's safer to be betting later than earlier..)

What's wrong with "Good support for RSA signed ECDSA certificates" if it's not hard to implement (I hope :stuck_out_tongue:) For some reason it's all black & white for some folks here.. But I haven't read any good concrete arguments?

1 Like

If you want support now, just fill the stub and send a PR that can be reviewed. :wink:

1 Like

Sure! I would if I could!

Just implementing section 5.6.2.3.2 or 5.6.2.3.3 (page 36 and 37 resp.) of NIST Special Publication 800-56A
Revision 2: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography
(I assume we're using the second revision nowadays?) where I find all kind of stuff I have the slightest idea of (high grade mathmathics.. :anguished:) and write it into code (assuming I DO understand what I'm reading) in a language I'm not proficient in.. :stuck_out_tongue:

Yeah, that'll work :wink:

Doesn't mean I'm not willing to try though. Just.. I can't guarantee anything :stuck_out_tongue:

1 Like

Hi, i can not code ā€œgoā€ but i extracted the relevant documentation
and the add if to the function stub. So maybe here is some crack that can do the final touch.

// GoodKeyECDSA determines if an ECDSA pubkey meets our requirements
func GoodKeyECDSA(key ecdsa.PublicKey) (err error) {
log := blog.GetAuditLogger()
err = NotSupportedError(ā€œECDSA keys not yet supportedā€)

// key.X          big.Int        := xQ
// key.Y          big.Int        := yQ
// key.Params().P    big.Int
// key.Params().N    big.Int
// key.Params().B    big.Int
// key.Params().Gx    big.Int
// key.Params().Gy    big.Int
// key.Params().BitSize    int
// key.Params().Name    string    (P224, P256, P383, P521)

// http://csrc.nist.gov/groups/ST/toolkit/documents/SP800-56Arev1_3-8-07.pdf
// https://www.nsa.gov/ia/_files/ecdsa.pdf A.3

// 5.6.2.5 ECC Full Public Key Validation Routine 
// ECC full public key validation refers to the process of checking all the arithmetic properties of a 
// candidate  ECC  public  key  to  ensure  that  it  has  the  unique  correct  representation  in  the  correct  
// (additive)  subgroup  (and  therefore  is  also  in  the  correct  EC  group)  specified  by  the  associated  
// ECC  domain  parameters.  ECC  full  public  key  validation  does  not  require  knowledge  of  the  
// associated private key and so may be done at any time by anyone. This method may be used for a static  ECC  public  key,  
// or  an  ephemeral  ECC  public key,  when  assurance  of the  validity  of  the  key is obtained by method 1 or method 2 
// of Sections 5.6.2.1, 5.6.2.2, and 5.6.2.3. 

// Input: 
// 1. (q, FR, a, b {, SEED } , G, n, h): A valid set of ECC domain parameters, and 
// 2. Q =( xQ , yQ ): A candidate ECC public key. 

// Process: 
// 1. Verify that Q is not the point at infinity O. 
// This can be done by inspection if the point is entered in the standard affine representation. 
// (Partial check of the public key for an invalid range in the EC group.) 
// O = A + -A = A + -1 * A = A + A
// if (A + A ==  A) then A is the point at infinity., this mean unusable for secure signatures.

// TODO translate to GO : IF( ((-1 * [key.X , key.Y]) + [key.X , key.Y])==[key.X , key.Y] THEN [key.X , key.Y] is the infinite point and there is an error

// 2. Verify   that   xQ and yQ are integers in the interval [0, p -1] in the case that q is an odd prime p , 
// or that xQ and yQ are bit strings of length m bits in the case that q = 2^m . 
// (Ensures  that  each  coordinate  of  the  public  key  has  the  unique  correct  representation  of  an element in the underlying field.) 
// TODO: if(p==2^m) xQ und yQ must be bitstring of len m
//       else       xQ und yQ must between 0 and p-1

// 3. If   q is an odd prime p , verify that yQ^2 = xQ^3 + a * xQ + b           (mod p).  
//    If   q = 2^m ,             verify that yQ^2 + xQ*yQ = xQ^3 + a * xQ^2 + b      in the finite field of size 2^m . 
// (Ensures that the public key is on the correct elliptic curve.) 

log.Debug(err.Error())
return

}

3 Likes

Hi, even if the stub is done with the PublicKey checks. I think there is one point open.
There should be an list what curveā€™s are supported. Because the check define only if the
key is ok. But same as with rsa maybe there should be and bit length limit?

Based on what i found i would limit the curve onyl to curves that have an 128 Bit equivalent
Here is an List what i found (TLS-EC Number , CurveName-Rfc , NistName , RFC , RSA equivalent , Symmetric equivalent)
// [ 0] unknownCurve(0),
// [ 1] sect163k1 K-163 1.3.132.0.1 rfc4492 nistk163
// [ 2] sect163r1 1.3.132.0.2 rfc4492
// [ 3] sect163r2 B-163 1.3.132.0.15 rfc4492
// [ 4] sect193r1 1.3.132.0.24 rfc4492
// [ 5] sect193r2 1.3.132.0.25 rfc4492
// [ 6] sect233k1 K-233 1.3.132.0.26 rfc4492 nistk233 (eq. 2240 bits RSA) (112 bit)
// [ 7] sect233r1 B-233 1.3.132.0.27 rfc4492 nistb233 (eq. 2240 bits RSA) (112 bit)
// [ 8] sect239k1 1.3.132.0.3 rfc4492 (eq. 2304 bits RSA) (115 bit)
// [ 9] sect283k1 K-283 1.3.132.0.16 rfc4492 nistk283 (eq. 7680 bits RSA) (192 bit)
// [10] sect283r1 B-283 1.3.132.0.17 rfc4492 (eq. 7680 bits RSA) (192 bit)
// [11] sect409k1 K-409 1.3.132.0.36 rfc4492 nistk409 (eq. 7680 bits RSA) (192 bit)
// [12] sect409r1 B-409 1.3.132.0.37 rfc4492 nistb409 (eq. 7680 bits RSA) (192 bit)
// [13] sect571k1 K-571 1.3.132.0.38 rfc4492 nistt571 (eq. 15360 bits RSA) (256 Bit)
// [14] sect571r1 B-571 1.3.132.0.39 rfc4492 (eq. 15360 bits RSA) (256 Bit)
// [15] secp160k1 1.3.132.0.9 rfc4492
// [16] secp160r1 1.3.132.0.8 rfc4492
// [17] secp160r2 1.3.132.0.30 rfc4492
// [18] secp192k1 1.3.132.0.31 rfc4492 (eq. 1536 bits RSA) ( 96 bit)
// [19] secp192r1 P-192 1.2.840.10045.3.1.1 rfc4492 nistp192 (eq. 1536 bits RSA) ( 96 bit)
// [20] secp224k1 1.3.132.0.32 rfc4492 (eq. 2048 bits RSA) (112 bit)
// [21] secp224r1 P-224 1.3.132.0.33 rfc4492 nistp224 (eq. 2048 bits RSA) (112 bit)
// [22] secp256k1 1.3.132.0.10 rfc4492 (eq. 3072 bits RSA) (128 bit)
// [23] secp256r1 P-256 1.2.840.10045.3.1.7 rfc4492 (eq. 3072 bits RSA) (128 bit)
// [24] secp384r1 P-384 1.3.132.0.34 rfc4492 (eq. 7680 bits RSA) (192 bit)
// [25] secp521r1 P-521 1.3.132.0.35 rfc4492 (eq. 15360 bits RSA) (256 Bit)
// [26] brainpoolP256r1 1.3.36.3.3.2.8.1.1.7 rfc7027
// [27] brainpoolP384r1 1.3.36.3.3.2.8.1.1.11 rfc7027 (eq. 7680 bits RSA)
// [28] brainpoolP512r1 1.3.36.3.3.2.8.1.1.13 rfc7027 (eq. 15360 bits RSA) (256 Bit)

1 Like

I was under the impression that RSA keys could sign ECC certificates, and vice versa. Would there theoretically be any issue with letsencrypt.org signing a ECC certificate with their intermediate RSA key?

1 Like

No only that they need to check the EC-Key quality. This check needs to be implemented.

2 Likes