11. Design of the Signature Component

Signature algorithms complete the set. They authenticate the handshake and bind it to a certificate, and like groups they are advertised through a capability and carry a code point. This chapter is shorter than its predecessors because the mechanism is closely analogous to Chapter 10; the differences are in the certificate coupling and in the two-layer naming.

11.1 What must be supplied

A usable signature algorithm requires four things: key management for the key type, the signature operations themselves, an association with an OID so certificates can be matched, and a capability entry so the algorithm can be offered in the signature_algorithms extension.

The OID requirement is the structural difference from a group. A group exists only for the duration of a handshake and is identified solely by its code point. A signature algorithm must also be recognisable in a certificate, which is an X.509 structure identifying algorithms by object identifier. An algorithm advertised in the handshake but absent from any certificate the server holds can be negotiated and then not used.

11.2 Dispatch table

static const OSSL_DISPATCH tlsext_signature_functions[] = {
    { OSSL_FUNC_SIGNATURE_NEWCTX,       (void (*)(void))sig_newctx },
    { OSSL_FUNC_SIGNATURE_FREECTX,      (void (*)(void))sig_freectx },
    { OSSL_FUNC_SIGNATURE_DUPCTX,       (void (*)(void))sig_dupctx },
    { OSSL_FUNC_SIGNATURE_SIGN_INIT,    (void (*)(void))sig_sign_init },
    { OSSL_FUNC_SIGNATURE_SIGN,         (void (*)(void))sig_sign },
    { OSSL_FUNC_SIGNATURE_VERIFY_INIT,  (void (*)(void))sig_verify_init },
    { OSSL_FUNC_SIGNATURE_VERIFY,       (void (*)(void))sig_verify },
    { OSSL_FUNC_SIGNATURE_SET_CTX_PARAMS,
                                        (void (*)(void))sig_set_ctx_params },
    { 0, NULL }
};

As with key exchange, the signing operation follows the two-call convention for output length. The length reported must be the maximum the algorithm can produce, since the caller allocates before signing.

11.3 The capability entry and the two names

The capability entry carries both an IANA name and an algorithm name, and §4.3.2 verified the parameter set. The distinction is worth drawing out, because it is the mechanism by which a protocol-level identifier is decoupled from an implementation-level one.

The security-bits value is not decorative. OpenSSL's security-level mechanism filters algorithms whose claimed strength falls below the configured level, so an algorithm advertising an understated value may be filtered out of a handshake it could have served, and one advertising an overstated value defeats a control the deployment believes it has.

11.4 Certificate coupling

For the algorithm to be usable end to end, the server must hold a certificate whose subject public key the algorithm can sign with, and the peer must be able to verify that certificate. In practice this means the key type must be encodable and decodable in the structures certificates use, which brings the encoder and decoder operations of the provider interface into scope.

These are beyond the scope of this design, and the limitation should be stated plainly: a provider supplying a novel signature algorithm for TLS is not finished when signing works. It is finished when a certificate carrying such a key can be parsed, presented, chained and verified by both endpoints. That is a larger undertaking than the signature operation itself, and it is the reason a design of this kind is usually attempted for groups before signature algorithms.

11.5 Relationship to the paper's core design

The three algorithm classes named in this paper's title are the block cipher, the elliptic curve and the hash. The signature component is specified here for completeness — a TLS connection cannot authenticate without one — but a design that supplies the other three may reasonably use a standard signature algorithm from the default provider. Doing so reduces the certificate problem of §11.4 to nothing, and is recommended for a first implementation.