1

Does anyone know if CertificateVerify is sent in TLS_DH_RSA with client authentication? Does anyone know the RFC or could explain the meaning of it? With TLS_RSA, a hash is normally calculated with the private RSA key at this point. And with DH?

user946822
  • 21
  • 2
  • 1
    Maybe I'm understanding your question wrong, but ... the DH in TLS_DH_RSA specifies the key exchange algorithm for the TLS session. This is unrelated to how CertificateVerify is signed. Which means your question does not make any sense to me. Also, a CertificateVerify is always send by the client if a certificate is send by the client, no matter which cipher. – Steffen Ullrich Jan 05 '24 at 12:50
  • "With TLS_RSA, a hash is normally calculated with the private RSA key at this point" doesn't make too much sense to me either. If client authentication is used then a signature will be created. If you're talking about key establishment / server authentication then a hash is not created. And an RSA key isn't involved in "calculating a hash". – Maarten Bodewes Jan 05 '24 at 22:14
  • 1
    @SteffenUllrich: not quite; for <=1.2 static-[EC]DH suites and client auth, the client sends CertificateVerify if (the server request allows and) it chooses a 'signature' cert and NOT a 'fixed_[ec]dh' cert (which almost nobody has but is techically possible and allowed); see e.g. rfc5246 7.4.8. – dave_thompson_085 Jan 06 '24 at 00:46

1 Answers1

2

Even for <=1.2, the authentication method specified by the ciphersuite fully controls only the server cert&key. If the server uses any cert (i.e. keyexchange is not anonymous or PSK or Kerberos) the client cert&key is controlled instead by the CertificateRequest message sent by the server, and can be different, e.g. a server using a (FF)DH-signed-by-RSA cert could allow a client to use an ECDSA cert&key to sign an ephemeral FFDHE key, or to use an (FF)DH cert&key (in the correct group) signed by an ECDSA CA, etc.

Also note DH(static)_RSA or ECDH(static)_RSA in 1.0 or 1.1 means the server DH or ECDH cert is signed by a CA cert&key that uses RSA. For 1.2 the choice of CA signing algorithm is instead controlled by the sigalgs extension and the second part of the ciphersuite spec is ignored; see rfc5246 7.4.2 and A.7 as referenced on this existing Q you apparently touched.

For 1.3 keyexchange is no specified in the ciphersuite and is never static-DH, so if client auth is done it (always) uses a signature cert and sends CertificateVerify; see rfc8446 4.4.3.

dave_thompson_085
  • 6,319
  • 1
  • 21
  • 23