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:
I'm using openssl to do this.
Any ideas or recommendations are greatly appreciated, thanks!
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.
Tom's answer is correct for X.509 standard and many browsers which are based on standard SSL libraries support the case. However, in this rough real world, I found some devices rejecting ECDSA certificate which has RSA signatures, with TLS 1.2 negotiation.
I think the reason is that the authors of the devices followed the RFC-4492, (** is mine)
2.2. ECDHE_ECDSA
In ECDHE_ECDSA, the server's certificate **MUST** contain an ECDSA-
capable public key and **be signed with ECDSA.**
The server sends its ephemeral ECDH public key and a specification of
the corresponding curve in the ServerKeyExchange message. These
parameters MUST be signed with ECDSA using the private key
corresponding to the public key in the server's Certificate.
though RFC-5246, TLS1.2, loosened this restriction. (** is mine):
7.4.4. Certificate Request
...
If the client provided a "signature_algorithms" extension, then all
certificates provided by the server MUST be signed by a
hash/signature algorithm pair that appears in that extension. **Note
that this implies that a certificate containing a key for one
signature algorithm MAY be signed using a different signature
algorithm (for instance, an RSA key signed with a DSA key). This is
a departure from TLS 1.1, which required that the algorithms be the
same.** Note that this also implies that the DH_DSS, DH_RSA,
ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
algorithm used to sign the certificate. Fixed DH certificates MAY be
signed with any hash/signature algorithm pair appearing in the
extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
historical.
So be warned that such a device exists.
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.
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.
According to RFC4492 related to Elliptic Curve Cipher Suites:
Key Exchange Algorithm Server Certificate Type
---------------------- -----------------------
ECDH_ECDSA Certificate MUST contain an
ECDH-capable public key. It
MUST be signed with ECDSA.
ECDHE_ECDSA Certificate MUST contain an
ECDSA-capable public key. It
MUST be signed with ECDSA.
ECDH_RSA Certificate MUST contain an
ECDH-capable public key. It
MUST be signed with RSA.
ECDHE_RSA Certificate MUST contain an
RSA public key authorized for
use in digital signatures. It
MUST be signed with RSA.
CA signature algorithm can be different from certificate public key algorithm.
For example, a certificate containing ECDSA public key can be signed by the CA using RSA-SHA256.
Here is a real life example from google ECDSA certificate which is signed by the CA using RSA-SHA256.
$ echo | openssl s_client -connect www.google.com:443 -cipher 'ECDHE-ECDSA-CHACHA20-POLY1305' -tls1_2 2>/dev/null| sed -n '/BEGIN/,/END/ p' | openssl x509 -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3957570017544888113 (0x36ec1cf67d7fdf31)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Google Inc, CN = Google Internet Authority G2
Validity
Not Before: Apr 17 12:48:49 2018 GMT
Not After : Jul 10 12:38:00 2018 GMT
Subject: C = US, ST = California, L = Mountain View, O = Google Inc, CN = www.google.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:7a:36:16:34:57:32:b6:b4:b0:53:25:48:14:35:
bb:74:5b:eb:bb:0c:66:1f:33:ed:80:59:f5:b5:a8:
2f:82:ab:6b:e7:9a:41:7e:80:e1:af:7d:6c:59:cc:
9a:9b:27:63:93:f3:d6:94:a0:6e:70:17:11:a5:f8:
35:0c:66:71:8a
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage: critical
Digital Signature
X509v3 Subject Alternative Name:
DNS:www.google.com
Authority Information Access:
CA Issuers - URI:http://pki.google.com/GIAG2.crt
OCSP - URI:http://clients1.google.com/ocsp
X509v3 Subject Key Identifier:
24:E8:32:6E:01:88:23:67:42:C7:FA:F1:C1:1F:CA:BA:AC:B8:A9:5B
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Authority Key Identifier:
keyid:4A:DD:06:16:1B:BC:F6:68:B5:76:F5:81:B6:BB:62:1A:BA:5A:81:2F
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.11129.2.5.1
Policy: 2.23.140.1.2.2
X509v3 CRL Distribution Points:
Full Name:
URI:http://pki.google.com/GIAG2.crl
Signature Algorithm: sha256WithRSAEncryption
8e:c6:4b:84:e7:90:af:91:ae:7b:0d:63:89:b4:29:6a:61:92:
93:79:c4:b2:b0:db:f6:d8:8b:2e:3c:5b:9b:f7:8c:2f:00:df:
d1:72:40:ba:22:0b:51:fa:84:01:9b:db:24:15:b9:9c:99:02:
82:18:fd:8b:ce:42:ff:17:3d:55:b9:dc:b4:60:cd:0a:5e:d0:
69:37:f2:54:38:6a:ab:2a:e8:83:e6:56:cc:58:bf:b1:ac:65:
7d:f7:6f:7a:88:87:dc:54:fc:16:2b:e7:8a:7d:88:23:54:9c:
3f:e9:6b:e5:b5:71:34:b4:46:0d:19:a2:78:92:b6:c2:8e:4a:
0f:c8:20:b7:d9:48:df:ed:44:98:df:c1:ed:0c:c2:2c:5e:54:
e2:12:42:b0:5a:0a:50:36:62:39:81:e2:0a:83:45:ca:25:f5:
40:85:c4:7d:99:47:3f:fd:df:ce:cd:0b:7d:f5:56:45:21:db:
9a:6c:ee:37:0e:cd:c1:33:8d:3f:7a:98:d1:ff:68:61:58:52:
37:6d:34:79:b0:28:fd:fe:e9:f8:53:75:59:39:77:6f:54:7b:
3d:97:08:3f:b6:55:36:9b:b8:b0:86:01:ac:92:9b:ac:30:eb:
fe:f2:2e:5d:2a:57:a4:75:6b:94:a1:4c:b3:2e:3d:25:5c:35:
65:3d:dd:67
$
Long ago (TLS 1.0 or earlier SSL. I don't want to look it up right now but its there in the RFCs) there used to be a requirement that all of the cryptography in the cert chain should be of the same type. But, that went away by I believe TLS 1.1. However, for safety's sake because some implementations may not be able to handle mixed mode cert chains it is a safe practice not to mix and match.
I may be a little cynical but I'd guess that Google mixes up their crypto with ECC leaves and RSA roots because they want to see if they can break things. Then they can lecture anyone who complains that they are a non-compliant ignorant twit who should read the RFC's
