Hai bisogno di un tipo speciale di certificato per l'utilizzo di Diffie Hellman come protocollo di scambio delle chiavi in SSL?

Ci sono due modi naturali per farlo.

1. Le specifiche possono identificare una serie di gruppi predefiniti. I parametri di gruppo per ognuno sono hard-coded nel software utilizzato da entrambi gli endpoint. La chiave pubblica quindi specifica quale di quei gruppi è destinato all'uso. Nel caso di Diffie-Hellman, i parametri del gruppo sono g e p , quindi l'identificatore di gruppo nella chiave pubblica determina il valore di g . Poiché l'identificatore di gruppo è nella chiave pubblica, è incluso nel certificato.

2. In alternativa, i parametri di gruppo stessi ( g e p ) possono essere inclusi nel certificato, come parte della chiave pubblica.

In entrambi i casi funziona. In entrambi i casi, le informazioni nel certificato consentono di determinare il valore corretto di g e p da utilizzare. Oltre a ciò, non è richiesto nulla di speciale.

Non è necessario un certificato speciale per lo scambio di chiavi Ephemeral Diffie-Hellman, ma è necessario il messaggio Server Key Exchange. Hai bisogno di un certificato speciale per il DH fisso. Come dice la specifica TLS:

• In Sezione 7.4.3 :

  The server key exchange message is sent by the server only when
  the server certificate message (if sent) does not contain enough
  data to allow the client to exchange a premaster secret.  This is
  true for the following key exchange methods:

       DHE_DSS
       DHE_RSA
       DH_anon

  It is not legal to send the server key exchange message for the
  following key exchange methods:

       RSA
       DH_DSS
       DH_RSA

Meaning of this message:

  This message conveys cryptographic information to allow the client
  to communicate the premaster secret: either an RSA public key with
  which to encrypt the premaster secret, or a Diffie-Hellman public
  key with which the client can complete a key exchange (with the
  result being the premaster secret).

• In Appendice A.5 (su suite di codici DH non effimeri):

The following CipherSuite definitions are used for server- authenticated (and optionally client-authenticated) Diffie-Hellman. DH denotes cipher suites in which the server's certificate contains the Diffie-Hellman parameters signed by the certificate authority (CA). [...]

• In Appendice F.1.1.3 :

When Diffie-Hellman key exchange is used, the server can either supply a certificate containing fixed Diffie-Hellman parameters or use the server key exchange message to send a set of temporary Diffie-Hellman parameters signed with a DSS or RSA certificate. Temporary parameters are hashed with the hello.random values before signing to ensure that attackers do not replay old parameters. In either case, the client can verify the certificate or signature to ensure that the parameters belong to the server.

Nota che i certificati con parametri DH sono piuttosto rari, comunque.

Stephen Henson (di OpenSSL) ha dichiarato quanto segue (certamente molto tempo fa) :

I've asked all over the place and I've yet to see a single example of a DH certificate. From this I can conclude they aren't very common.

Nelson Bolyard (da Mozilla NSS) ha dichiarato quanto segue più recentemente :

[...] I ask because I don't know of ANY public CA that issues such certs today. The last CA I knew of that did was the US DoD's CA that issued certificates for Fortezza cards.

Sospetto che ci sia poca richiesta per questi certificati. Richiederebbe più lavoro dalle CA, oggi è altrettanto facile usare EDH e le suite di crittografia che possono utilizzarle non sono ampiamente supportate. L'elenco più recente di Java 7 di suite di crittografia supportate non elenca alcun DH_RSA o DH_DSS cipher suite (solo DH_anon ed EDH).