Summary

  • A 2 November TLS working-group draft adds a recovery rule absent from its 30 September version: if a client rejects a certificate path for a reason other than its root, it SHOULD NOT choose that path’s trust-anchor ID for a retry.
  • Expiry, revocation, a name mismatch and a constraint on the root are the draft’s examples. A trusted root is a starting point for validation, not a pardon for a failed certificate.
  • The rule governs selection of the rejected path’s ID. The draft still allows recovery through another eligible ID and says clients should retry at most once per connection attempt.

The root got in; the certificate did not

Trust-anchor negotiation is designed to save servers from guessing which certificate chain a client can accept. The client advertises anchor IDs; the server selects a path and can list candidate IDs in its encrypted response. If a choice fails, the client may connect again to the same endpoint asking for one anchor. That is the recovery mechanism in the 2 November revision. It is useful when the server chose a chain the client did not mean to accept. It is a poor excuse to recycle a chain the client already found defective.

Section 5.6 now names that distinction. A path can lead to a root in the client’s trust store and still fail because the leaf has expired, a certificate was revoked, the name is wrong, or the client has placed a constraint on that root. In those cases the client SHOULD NOT select the rejected path’s associated trust-anchor ID for its second attempt. The previous version specified the retry and its one-attempt limit without this sentence. The addition changes the instruction at the decision point, where a developer might otherwise mistake “I recognize the root” for “try this path again.”

The draft does not demand that the client abandon every possible recovery. If the server listed other IDs in EncryptedExtensions and the client trusts an eligible one, it can choose according to server order and local preference. With no extension or no match, the error goes back to the application. The exact prohibition is narrower than a ban on all retries: do not send the ID tied to the path rejected on another validation ground. Nor is this a reported certificate bypass. The IETF status page still lists a working-group Internet-Draft, I-D Exists; the checked files show a proposed rule, not an implementation result.

That small qualifier carries a large boundary. A trust anchor establishes who may sign a chain. Certificate validity, identity and local constraints decide whether this particular chain gets through. Conflating the two turns a recovery feature into a second hearing for evidence already disqualified.