Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am making a CA that I hope to be able to sign RSA and Elliptic Curve-capable (EC) keys with. I was wondering if the best approach was:

  1. CA with RSA keys capable of signing RSA and EC CSRs
  2. CA with EC keys capable of signing RSA and EC CSRs
  3. 2 CA key sets (one RSA, one EC) each signing CSRs of their respective type
  4. 2 separate CAs

I'm using openssl to do this.

Any ideas or recommendations are greatly appreciated, thanks!

share|improve this question
    
I'm curious - ECC is quite different than RSA and not as widely adopted. Certicom owns the patents to several aspects of ECC. I haven't play around with ECC much but I recall it's a more efficient asymmetric crypto algorithm. What are you trying to accomplish? –  bangdang Apr 26 '12 at 21:08
    
I am making an SSL server, but ultimately want to migrate to using EC cryptography instead of just RSA. (ECC is a server requirement, but RSA is acceptable in the interim.) I wanted to make a CA that would be able to handle both RSA and EC client certificate requests, but didn't know if there were any restrictions on what CA's are capable of signing, or what is the most efficient way to set it up. –  aspergillusOryzae Apr 27 '12 at 1:01
    
Option 4 is your best bet from an inter-operability standpoint, especially if you're planning to roll out production ssl certs. There are hybrid certs in the wild as well as a few public CA's (entrust being one of them) offering ecc certs but it's still hugely experimental. I know RedHat's CA offers broader support for EC signed certs. My $0.02 –  bangdang Apr 27 '12 at 2:58
    
google has EC certificate signed with sha1-rsa serverfault.com/a/558322/201011 –  Smit Johnth Nov 29 '13 at 21:52

4 Answers 4

up vote 4 down vote accepted

In X.509, a CA can use any signature algorithm, regardless of the type of key in the signed certificates. Theoretically, if both the CA and the signed certificate use DSA keys or EC keys, and the two keys share the same group parameters (i.e. work over the same curve, for EC keys), then the designation of the curve might be omitted in the signed certificate. For EC keys, this may save perhaps a dozen bytes, and PKIX (the group responsible for the Internet X.509 Profile) explicitly forbids this "optimization". Hence I confidently state that there is no link between the types of keys in a CA certificate and the certificates that CA issues.

EC support in the existing deployed software based can be described as "flaky". Although X9.62 specifies how to encode parameters for EC keys in quite arbitrary curves, almost everybody implements only a limited set of "known curves", mostly from the 15 curves from FIPS 186-3. Actually, among these 15 curves, only two of them (P-256 and P-384) have non-anecdotic support in existing browsers. These two curves are the "bare minimum" of EC support as per NSA "suite B" (a recommendation from NSA for non-NSA people -- what constitutes "suite A" is not publicly known).

Also, X9.62 defines quite clearly how an ECDSA signature should be computed for every combination of hash function and curve (i.e. how hash values should be truncated or expanded to fit the curve group order). As could be expected, implementers got it wrong, and many believe that with P-256 (respectively P-384) only SHA-256 (respectively SHA-384) may be used. Therefore, if you use any other hash function, you will run in interoperability issues (I mean, more issues than what you will get for merely trying to use an algorithm which was not born in the Disco era).

The bright side is that P-256 with SHA-256 is, security-wise, "fine" (I love that word). The dark side is that even with that most supported combination, you will get into issues with old browsers (and there are places which are quite conservative with regards to updates -- at my workplace, the only allowed browser is IE 7 !). So you need a backup plan. Since the backup should be a whole-RSA PKI (RSA everywhere from the root down to the server and user certificates) for compatibility, and you want to ultimately switch to a whole-EC PKI, then you need two roots, one with RSA and one with EC. You can smooth out transitions to some extent with cross-certificates, but it is a whole can of worms.

share|improve this answer

You can sign EC certificates with RSA, and you will not lose speed on clients due to using RSA since RSA public key operation are much faster that ones with private key, it is even faster than checking ECDSA signatures.

                              sign    verify    sign/s verify/s
rsa 2048 bits            0.019616s 0.000583s     51.0   1714.3
256 bit ecdsa (nistp256)   0.0007s   0.0030s   1532.8    329.1

As you see from test results, it's even faster to test RSA signed certificate than EC signed :)

share|improve this answer

According to RFC 3280 no constrain is applied to signature algorithms:

4.1.2.7 Subject Public Key Info

This field is used to carry the public key and identify the algorithm with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The algorithm is identified using the AlgorithmIdentifier structure specified in section 4.1.1.2. The object identifiers for the supported algorithms and the methods for encoding the public key materials (public key and parameters) are specified in [PKIXALGS].

Thus any algorithm specified in RFC 3279 can be used for CA, Subject and CRL signature independently.

share|improve this answer

No, they don't need to have the same type of key, to the best of my knowledge. As far as I know, the CA's public key does not need to use the same algorithm as the entity whose public key it is signing.

But you should be able to test it pretty readily, and testing with popular browsers is highly recommended.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.