Estoy creando una CA con la que espero poder firmar con las claves RSA y con capacidad de curva elíptica (EC). Me preguntaba si el mejor enfoque era:
Estoy usando openssl para hacer esto.
Cualquier idea o recomendación es muy apreciada, gracias!
En X.509, una CA puede usar cualquier algoritmo de firma, independientemente del tipo de clave en los certificados firmados. Teóricamente , si tanto la CA como el certificado firmado utilizan claves DSA o EC, y las dos claves comparten los mismos parámetros de grupo (es decir, trabajo sobre la misma curva, para las claves EC), la designación de La curva puede omitirse en el certificado firmado. Para las claves EC, esto puede ahorrar una docena de bytes, y PKIX (el grupo responsable del perfil de Internet X.509 ) prohibe explícitamente esta "optimización". Por lo tanto, declaro con confianza que no hay un vínculo entre los tipos de claves en un certificado de CA y los certificados que emite CA.
El soporte de EC en el software implementado existente basado se puede describir como "escamoso". Aunque X9.62 especifica cómo codificar parámetros para claves EC en curvas bastante arbitrarias , casi todos implementan solo un conjunto limitado de "curvas conocidas", en su mayoría de las 15 curvas de FIPS 186-3 . En realidad, entre estas 15 curvas, solo dos de ellas (P-256 y P-384) tienen soporte no anecdótico en los navegadores existentes. Estas dos curvas son el "mínimo indispensable" del soporte de la CE según la "suite B" de la NSA (una recomendación de la NSA para personas que no pertenecen a la NSA: lo que constituye la "suite A" no se conoce públicamente).
Además, X9.62 define claramente cómo se debe calcular una firma ECDSA para cada combinación de función de hash y curva (es decir, cómo deben truncarse o expandirse los valores de hash para ajustarse al orden del grupo de curvas). Como era de esperar, los implementadores se equivocaron, y muchos creen que con P-256 (respectivamente P-384) solo se puede usar SHA-256 (respectivamente SHA-384). Por lo tanto, si utiliza cualquier otra función hash, se ejecutará en problemas de interoperabilidad (es decir, más problemas que los que obtendrá simplemente por intentar utilizar un algoritmo que no nació en la era Disco).
El lado positivo es que P-256 con SHA-256 es, por seguridad, "bien" (me encanta esa palabra). El lado oscuro es que incluso con la combinación más compatible, se tendrá problemas con los navegadores antiguos (y hay lugares que son bastante conservadores con respecto a las actualizaciones, en mi lugar de trabajo, el único navegador permitido) es IE 7!). Así que necesitas un plan de respaldo. Dado que la copia de seguridad debe ser una PKI RSA completa (RSA en todas partes desde la raíz hasta el servidor y los certificados de usuario) para la compatibilidad, y en última instancia, desea cambiar a una PKI de la EC completa, entonces necesita dos raíces, una con RSA y uno con EC. Puede suavizar las transiciones en cierta medida con certificados cruzados, pero es una lata de gusanos.
Según RFC 3280 no se aplica ninguna restricción a los algoritmos de firma:
4.1.2.7 Información de clave pública del sujeto
Este campo se usa para llevar la clave pública e identificar el algoritmo con el que se utiliza la clave (por ejemplo, RSA, DSA o Diffie-Hellman). los El algoritmo se identifica utilizando la estructura AlgorithmIdentifier especificado en la sección 4.1.1.2. Los identificadores de objeto para el Algoritmos soportados y los métodos para codificar la clave pública. los materiales (clave pública y parámetros) se especifican en [PKIXALGS].
Por lo tanto, cualquier algoritmo especificado en RFC 3279 se puede utilizar para la firma de CA, Asunto y CRL de forma independiente.
No, no es necesario que tengan el mismo tipo de clave, que yo sepa. Por lo que sé, la clave pública de la AC no necesita utilizar el mismo algoritmo que la entidad cuya clave pública está firmando.
Pero debería poder probarlo con bastante facilidad, y se recomienda realizar pruebas con navegadores populares.
La respuesta de Tom es correcta para el estándar X.509 y muchos navegadores que se basan en bibliotecas SSL estándar soportan el caso. Sin embargo, en este mundo real, encontré algunos dispositivos que rechazan el certificado ECDSA que tiene firmas RSA, con negociación TLS 1.2.
Creo que la razón es que los autores de los dispositivos siguieron el RFC-4492, (** es mío)
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.
aunque RFC-5246, TLS1.2, aflojó esta restricción. (** es mío):
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.
Por lo tanto, ten en cuenta que tal dispositivo existe.
Según RFC4492 relacionado con las suites de cifrado de curva elíptica:
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.
El algoritmo de firma de CA puede ser diferente del algoritmo de clave pública certificado.
Por ejemplo, un certificado que contiene una clave pública de ECDSA puede ser firmado por la CA mediante RSA-SHA256.
Aquí hay un ejemplo de la vida real del certificado ECDSA de Google que está firmado por la CA mediante 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
$
Lea otras preguntas en las etiquetas cryptography tls certificates certificate-authority