Section 2.5 lists ClientCertificate as one of a set of 3 auth schemes that MUST be implemented. But draft-thomson-httpbis-cant-01 expired about 10 months ago, with no recent discussion about resurrecting it.
RC32-01:
Work with the httpbis WG to resurrect the expired draft. This may cause the RFC Editor to hold the draft longer than otherwise needed.
RC32-02:
Remove ClientCertificate from the list. Effectively stating that the server MUST implement at least Basic or Digest, excluding the possibility that it could avoid password-based authentication.
RC32-03:
Assert that only client-certificate based auth is supported (like NETCONF over TLS). This would effectively remove the need for WWW-Authenticate altogether.
RC32-04:
Let client-certificates be silently (without a challenge) used in addition also allowing HTTP Authenticate schemes. A server receiving a client-certificate or an an Authentication header can use either directly (without sending a challenge). If neither is sent, or the authentication is invalid, the server can send a challenge (401 + WWW-authenticate header). The only downside is that, for now, no HTTP authentication scheme can direct the client to use a client-certificate.
Currently option RC32-04 is reflected in the -09 draft update.
abierman
commented
8 years ago
Section 2.5 lists ClientCertificate as one of a set of 3 auth schemes that MUST be implemented. But draft-thomson-httpbis-cant-01 expired about 10 months ago, with no recent discussion about resurrecting it.
RC32-01:
Work with the httpbis WG to resurrect the expired draft. This may cause the RFC Editor to hold the draft longer than otherwise needed.
RC32-02:
Remove ClientCertificate from the list. Effectively stating that the server MUST implement at least Basic or Digest, excluding the possibility that it could avoid password-based authentication.
RC32-03:
Assert that only client-certificate based auth is supported (like NETCONF over TLS). This would effectively remove the need for WWW-Authenticate altogether.
RC32-04:
Let client-certificates be silently (without a challenge) used in addition also allowing HTTP Authenticate schemes. A server receiving a client-certificate or an an Authentication header can use either directly (without sending a challenge). If neither is sent, or the authentication is invalid, the server can send a challenge (401 + WWW-authenticate header). The only downside is that, for now, no HTTP authentication scheme can direct the client to use a client-certificate.
Currently option RC32-04 is reflected in the -09 draft update.