2
$\begingroup$

Even the up to date RFC 8446 lists at the page 41 as the options for the ECDSA in e.g. TLS_ECDHE_ECDSA_WITH_... only NIST curves:

      /* ECDSA algorithms */
      ecdsa_secp256r1_sha256(0x0403),
      ecdsa_secp384r1_sha384(0x0503),
      ecdsa_secp521r1_sha512(0x0603),

Does it mean that the certificates containing the public key based on Brainpool curves cannot be used for signing the (EC)DHE parameters in SERVER KEY EXCHANGE?

$\endgroup$

2 Answers 2

6
$\begingroup$

RFC 8734 defines how to use Brainpool curves within TLS 1.3, including how they can be used in ECDSA signatures (section 4) . Hence, yes, there is an official way to negotiate Brainpool curves for use in the SERVER KEY EXCHANGE.

$\endgroup$
7
  • 3
    $\begingroup$ Doesn't necessarily mean that they will be supported a lot, of course. Especially nowadays, where most interest goes to Ed25519. To be honest, I'm not sure if I've seen any X509v3 certificates with brainpool signatures in the trust stores / browser caches. $\endgroup$
    – Maarten Bodewes
    Commented Sep 6, 2020 at 16:25
  • 1
    $\begingroup$ My job was unfortunately to extend a legacy project utilizing the TLS 1.2 by Brainpool-based ECDSA so the upgrade of the TLS stack is not a option. $\endgroup$
    – Vic
    Commented Nov 13, 2020 at 13:26
  • $\begingroup$ @Vic: if you're stuck with TLS 1.2, why did you reference the TLS 1.3 RFC? As for TLS 1.2, RFC5246 does allow the client/server to agree on an RSA vs ECDSA certificate (in case the server has both), however I don't see any restriction on the curve type within an ECDSA cert, including a Brainpool curve. Of course, there is also no way for the client to indicate specific support/nonsupport of Brainpool. $\endgroup$
    – poncho
    Commented Nov 13, 2020 at 14:08
  • $\begingroup$ What should the server then use to indicate the named brainpool curve in the ASN.1 structure describing the signature in the server key exchange message? The enum in the RFC 8734 referenced in my question doesn't contain anything but NIST. I'm talking not about the ECDHE, where I definitely can use any curve having the named curve id. In case of signature there must be an ID provided describing both the hash and signature, like ecdsa_secp256r1_sha256 $\endgroup$
    – Vic
    Commented Nov 14, 2020 at 15:34
  • 1
    $\begingroup$ @Vic: I believe RFC5639 has all the Brainpool-specific OID values you need to generate a Brainpool specific certificate. And, TLS 1.2 doesn't make a distinction between curves, relying on the certificate to carry the curve type. $\endgroup$
    – poncho
    Commented Nov 15, 2020 at 3:28
0
$\begingroup$

RFC 7027 defines short names for the brainpool curves that may be used in TLS 1.0, 1.1, and 1.2 for key exchange (by adding them the NamedCurve defined types). As mentioned in poncho's answer, RFC 8374 applies for TLS 1.3.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.