Sto creando una CA che spero di poter firmare con RSA e le chiavi che supportano la curva ellittica (EC). Mi stavo chiedendo se l'approccio migliore fosse:
Sto usando openssl per fare questo.
Tutte le idee o le raccomandazioni sono molto apprezzate, grazie!
In X.509, una CA può utilizzare qualsiasi algoritmo di firma, indipendentemente dal tipo di chiave nei certificati firmati. Teoricamente , se sia la CA che il certificato firmato utilizzano chiavi DSA o EC, e le due chiavi condividono gli stessi parametri di gruppo (cioè funzionano sulla stessa curva, per le chiavi EC), la designazione di la curva potrebbe essere omessa nel certificato firmato. Per le chiavi EC, questo può risparmiare forse una dozzina di byte e PKIX (il gruppo responsabile del profilo X.509 di Internet ) proibisce esplicitamente questa "ottimizzazione". Pertanto, dichiaro con certezza che non esiste alcun collegamento tra i tipi di chiavi in un certificato CA e i certificati emessi da CA.
Il supporto EC nel software distribuito esistente basato può essere descritto come "scarso". Sebbene X9.62 specifichi come codificare i parametri per le chiavi EC in curve abbastanza arbitrarie quasi tutti implementano solo un numero limitato di "curve conosciute", principalmente dalle 15 curve di FIPS 186-3 . In realtà, tra queste 15 curve, solo due di esse (P-256 e P-384) hanno un supporto non aneddotico nei browser esistenti. Queste due curve rappresentano il "minimo indispensabile" del supporto della CE secondo la "suite B" dell'NSA (una raccomandazione dell'NSA per le persone non NSA - ciò che costituisce la "suite A" non è pubblicamente noto).
Inoltre, X9.62 definisce in modo abbastanza chiaro come una firma ECDSA debba essere calcolata per ogni combinazione di funzione hash e curva (ad esempio, come i valori hash devono essere troncati o espansi per adattarsi all'ordine del gruppo di curve). Come prevedibile, gli implementatori hanno sbagliato e molti credono che con P-256 (rispettivamente P-384) possa essere usato solo SHA-256 (rispettivamente SHA-384). Pertanto, se si utilizza qualsiasi altra funzione di hash, si eseguiranno problemi di interoperabilità (voglio dire, più problemi di quelli che si otterranno semplicemente cercando di utilizzare un algoritmo che non è nato nell'era Disco).
Il lato positivo è che il P-256 con SHA-256 è, per quanto riguarda la sicurezza, "fine" (adoro quella parola). Il lato oscuro è che anche con quella combinazione più supportata, riuscirà a entrare nei problemi con i vecchi browser (e ci sono posti che sono piuttosto conservativi per quanto riguarda gli aggiornamenti - sul mio posto di lavoro, l'unico browser consentito è IE 7!). Quindi hai bisogno di un piano di backup. Poiché il backup deve essere un PKI RSA intero (RSA ovunque dalla radice fino al server e ai certificati utente) per la compatibilità e si desidera passare a un PKI EC completo, allora sono necessarie due radici, una con RSA e uno con EC. È possibile appianare le transizioni in una certa misura con i certificati incrociati, ma è un intero barattolo di worm.
In base a RFC 3280 nessun vincolo viene applicato agli algoritmi delle firme:
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].
Quindi qualsiasi algoritmo specificato in RFC 3279 può essere utilizzato indipendentemente per la firma di CA, Subject e CRL.
No, non è necessario avere lo stesso tipo di chiave, per quanto ne so. Per quanto ne so, la chiave pubblica della CA non ha bisogno di utilizzare lo stesso algoritmo dell'entità la cui chiave pubblica sta firmando.
Ma dovresti essere in grado di testarlo abbastanza facilmente e si consiglia vivamente di provare con i browser più diffusi.
La risposta di Tom è corretta per lo standard X.509 e molti browser che si basano su librerie SSL standard supportano il caso. Tuttavia, in questo ruvido mondo reale, ho trovato alcuni dispositivi che rifiutavano il certificato ECDSA che ha firme RSA, con negoziazione TLS 1.2.
Penso che la ragione sia che gli autori dei dispositivi hanno seguito la RFC-4492, (** è mia)
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.
sebbene RFC-5246, TLS1.2, ha allentato questa restrizione. (** è mio):
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.
Quindi tieni presente che tale dispositivo esiste.
Secondo l'RFC4492 relativo alle 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.
L'algoritmo della firma CA può essere diverso dall'algoritmo della chiave pubblica del certificato.
Ad esempio, un certificato contenente la chiave pubblica ECDSA può essere firmato dalla CA utilizzando RSA-SHA256.
Ecco un esempio di vita reale dal certificato ECDSA di google firmato dalla CA che utilizza 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
$
Leggi altre domande sui tag cryptography tls certificates certificate-authority