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.

In there paper Authentication and authenticated key exchange Diffie, van Oorschot and Wiener recommend to insert the DH parameters into the certificate of Alice. As a result an attacker can not change the DH parameters unnoticed.

Now my question how do I store the DH parameters in a X.509 certificate? Should I just add them as an extension?

share|improve this question

1 Answer 1

up vote 6 down vote accepted

The usual way this is done is to have Alice sign the set of DH parameters to use. This requires Alice's key and certificate to be appropriate for signatures. In two widely deployed protocols:

  • In SSL/TLS, when Alice (the server) wants to use Diffie-Hellman for key exchange, it selects one of the DHE cipher suites. The DH parameters and the DH public key (the server's half of the DH) are encoded as a ServerKeyExchange message, which the server signs with its private key.

  • In S/MIME, when Alice signs an email, she can include in the signature object (under the cover of the signature) an SMIMECapabilities attribute which can contain the DH parameters and public key to use, should the recipient wish the respond to Alice with an encrypted email.

It is also possible to have a certificate which contains a DH public key (and parameters) directly, but this is much more rarely done because such certificates cannot be used for signatures, only key exchange.

The DH parameters themselves (not the public key) could also be "well-known" and thus distributed with the software. This is what usually happens with elliptic-curve variants of DH (building your own curve is possible but relatively expensive, and most software only supports a subset of the 15 NIST curves).

Custom extensions means that only your software will be able to process them, which is often restrictive, so this is discouraged. Also, embedding data in the certificate implies that the data (whatever it is) is chosen by the CA and has the same lifetime than the certificate itself, which may or may not be adequate (this is worth considering).

share|improve this answer
    
In SSL/TLS, you also have non-DHE DH cipher suites. I'm not sure which SSL/TLS stacks support them, though. Java's SunJSSE doesn't and openssl ciphers ALL doesn't seem to show any either (at least on my machine). –  Bruno Aug 31 '12 at 17:30

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.