0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-------------------------------+-------------------------------+
 |  Cert-ID (8)  |         Algorithm (16)        | Signature(*)...
 +---------------------------------------------------------------+
 

Figure 10: CERTIFICATE_PROOF frame payload

The CERTIFICATE_PROOF frame (0xFRAME-TBD4) contains an Algorithm field (a SignatureAndHashAlgorithm, from [I-D.ietf-tls-tls13] section 6.3.2.1), describing the hash/signature algorithm pair being used. [[TODO: Sixteen bits because it is in TLS 1.3; if we’re using a bitmask to express allowed values, we’re down to ~5 bits needed to contain all permitted algorithms. Shrink?]]

The signature is performed as described in [I-D.ietf-tls-tls13], with the following values being used:

• The context string for the signature is “HTTP/2 CERTIFICATE_PROOF”
• The “specified content” is an [RFC5705] exported value, with the following parameters:
  • Disambiguating label string: “EXPORTER HTTP/2 CERTIFICATE_PROOF”
  • Length: 64 bytes

Because the exported value can be independently calculated by both sides of the TLS connection, the value to be signed is not sent on the wire at any time. The same signed value is used for all CERTIFICATE_PROOF frames in a single HTTP/2 connection.

A CERTIFICATE_PROOF frame MUST be sent only after all CERTIFICATE frames with the same Cert-ID have been sent, and MUST correspond to the first certificate presented in the first CERTIFICATE frame with that Cert-ID. Receipt of multiple CERTIFICATE_PROOF frames for the same Cert-ID, receipt of a CERTIFICATE_PROOF frame without a corresponding CERTIFICATE frame, or receipt of a CERTIFICATE frame after a corresponding CERTIFICATE_PROOF MUST be treated as a session error of type PROTOCOL_ERROR.

If the AUTOMATIC_USE flag is set, the recipient MAY omit sending CERTIFICATE_REQUIRED frames on future streams which would require a similar certificate and use the referenced certificate for authentication without further notice to the holder. This behavior is optional, and receipt of a CERTIFICATE_REQUIRED frame does not imply that previously-presented certificates were unacceptable, even if AUTOMATIC_USE was set. Servers MUST set the AUTOMATIC_USE flag when sending a CERTIFICATE_PROOF frame. A server MUST NOT send certificates for origins which it is not prepared to service on the current connection.

4. Indicating failures during HTTP-Layer Certificate Authentication

Because this draft permits certificates to be exchanged at the HTTP framing layer instead of the TLS layer, several certificate-related errors which are defined at the TLS layer might now occur at the HTTP framing layer. In this section, those errors are restated and added to the HTTP/2 error code registry.

BAD_CERTIFICATE (0xERROR-TBD1):

A certificate was corrupt, contained signatures that did not verify correctly, etc.

UNSUPPORTED_CERTIFICATE (0xERROR-TBD2):

A certificate was of an unsupported type or did not contain required extensions

CERTIFICATE_REVOKED (0xERROR-TBD3):

A certificate was revoked by its signer

CERTIFICATE_EXPIRED (0xERROR-TBD4):

A certificate has expired or is not currently valid

BAD_SIGNATURE (0xERROR-TBD5):

The digital signature provided did not match the claimed public key

CERTIFICATE_TOO_LARGE (0xERROR-TBD6):

The certificate cannot be transferred due to the recipient’s SETTINGS_MAX_FRAME_SIZE

CERTIFICATE_GENERAL (0xERROR-TBD7):

Any other certificate-related error

As described in [RFC7540], implementations MAY choose to treat a stream error as a connection error at any time. Of particular note, a stream error cannot occur on stream 0, which means that implementations cannot send non-session errors in response to CERTIFICATE_REQUEST, CERTIFICATE, and CERTIFICATE_PROOF frames. Implementations which do not wish to terminate the connection MAY either send relevant errors on any stream which references the failing certificate in question or process the requests as unauthenticated and provide error information at the HTTP semantic layer.

5. Security Considerations

This mechanism defines an alternate way to obtain server and client certificates other than the TLS handshake. While the signature of exporter values is expected to be equally secure, it is important to recognize that a vulnerability in this code path is at least equal to a vulnerability in the TLS handshake.

This could also increase the impact of a key compromise. Rather than needing to subvert DNS or IP routing in order to use a compromised certificate, a malicious server now only needs a client to connect to some HTTPS site under its control. Clients SHOULD continue to validate that destination IP addresses are valid for the origin either by direct DNS resolution or resolution of a validated Alternative Service. (Future work could include a mechanism for a server to offer proofs.)

This draft defines a mechanism which could be used to probe servers for origins they support, but opens no new attack versus making repeat TLS connections with different SNI values. Servers SHOULD impose similar denial-of-service mitigations (e.g. request rate limits) to CERTIFICATE_REQUEST frames as to new TLS connections.

While the CERTIFICATE_REQUEST frame permits the sender to enumerate the acceptable Certificate Authorities for the requested certificate, it might not be prudent (either for security or data consumption) to include the full list of trusted Certificate Authorities in every request. Senders, particularly clients, are advised to send an empty Certificate-Authorities element unless they are expecting a certificate to be signed by a particular CA or small set of CAs.

Failure to provide a certificate on a stream after receiving CERTIFICATE_REQUIRED blocks processing, and SHOULD be subject to standard timeouts used to guard against unresponsive peers.

In order to protect the privacy of the connection against triple-handshake attacks, this feature of HTTP/2 MUST be used only over TLS 1.3 or greater, or over TLS 1.2 in combination with the Extended Master Secret extension defined in [RFC7627].

Client implementations need to carefully consider the impact of setting the AUTOMATIC_USE flag. This flag is a performance optimization, permitting the client to avoid a round-trip on each request where the server checks for certificate authentication. However, once this flag has been sent, the client has zero knowledge about whether the server will use the referenced cert for any future request, or even for an existing request which has not yet completed. Clients MUST NOT set this flag on any certificate which is not appropriate for currently-in-flight requests, and MUST NOT make any future requests on the same connection which they are not willing to have associated with the provided certificate.

Implementations need to be aware of the potential for confusion about the state of a connection. The presence or absence of a validated certificate can change during the processing of a request, potentially multiple times, as USE_CERTIFICATE frames are received. A server that uses certificate authentication needs to be prepared to reevaluate the authorization state of a request as the set of certificates changes.

Finally, validating a multitude of signatures can be computationally expensive, while generating an invalid signature is computationally cheap. Implementations will require checks against attacks from this direction. Signature proofs SHOULD NOT be validated until a stream requires the certificate to make progress. A signature which is not valid based on the asserted public key SHOULD be treated as a session error, to avoid further attacks from the peer, though an implementation MAY instead disable HTTP-layer certificates for the current connection instead.

6. IANA Considerations

This draft establishes two new registries, and adds entries in three others.

Acceptable signature methods are registered in Section 6.1. Acceptable forms of supplemental data are registered in Section 6.2.

The HTTP/2 SETTINGS_HTTP_CERT_AUTH setting is registered in Section 6.3. Five frame types are registered in Section 6.4. Six error codes are registered in Section 6.5.

6.1. Signature Methods

This document establishes a registry for signature methods acceptable for use with this extension. The “HTTP-Layer Certificate Signature Method” registry manages a space of sixteen values. The “HTTP-Layer Certificate Signature Method” operates under either the “RFC Required” or “IESG Approval” policy.

New entries in this registry require the following information:

Signature Method:

A name or label for the signature method

Bit assignment:

A single-bit value from 0x0000 to 0x8000

Specification:

A document which describes how the signature may be performed

The entries in the following table are registered by this document.

+-------------------------------+------------+------------------------------+
| Signature Method              | Bit        | Specification                |
+-------------------------------+------------+------------------------------+
| ECDSA P-256 with SHA-256      | 1 (0x0001) | [FIPS-186-4]                 |
| ECDSA P-384 with SHA-384      | 2 (0x0002) | [FIPS-186-4]                 |
| Ed25519                       | 3 (0x0004) | [I-D.josefsson-eddsa-ed25519]|
| Ed448                         | 4 (0x0008) | [I-D.josefsson-eddsa-ed25519]|
| RSA-PSS with SHA-256 and MGF1 | 5 (0x0010) | [PKCS.1]                     |
+-------------------------------+------------+------------------------------+

+------------------------+------------+-------+----------------------+
| Data Type              | Bit        | Value | Specification        |
+------------------------+------------+-------+----------------------+
| Reserved               | 1 (0x0001) | N/A   | {{setting}}          |
| OCSP                   | 2 (0x0002) | 0x00  | [RFC2560]            |
| SCT                    | 3 (0x0004) | 0x01  | [RFC6962]            |
+------------------------+------------+------------------------------+