Request and secondary certificate correlation

[egorbaty]

It has come up in discussion that there might be cases where clients and servers need the ability to "agree" on what certificates are used for a given request. If this was something we wanted to support, we'd probably need a mechanism for the server to identify the certificate, and then for the client to subsequently present the ID on requests where correlation was necessary.

There are a few questions for discussion here:

• Does the WG think this should be in-scope for the document? Does anyone have an actual use case?
• If so, what form does a solution take? Do we need to reintroduce a certificate ID or something in the certificate_request_context to allow clients/servers to coordinate the usage of particular certificates?

As far as possible solutions are concerned:

• The previous iteration of secondary certs included a Cert ID field which could be used for this.
  • The server sends this either as a field in the certificate frame, or as part of the certificate_request_context in the exported authenticator
  • The client could then associate a received and validated certificate to a request via a header which indicates the Cert ID for the request

[egorbaty]

Post IETF-120 Update:

Doesn't seem like there is a strong desire for this. It was discussed that it might be useful to add a general mechanism for clients to indicate the way they got to make the request (ie, altsvc, secondary certs, etc) but that'd probably be in a different document.

Will double check on the mailing list before closing the issue.