[ofriel] Another requirement is that the full public key Y_c is not transmitted as part of TLS handshake from client to server. We cannot not use RFC 7250 as is. Instead, something like the Known Certificates proposal in cTLS https://tools.ietf.org/html/draft-ietf-tls-ctls-01#section-5.1.3 would work.
Is that a primary requirement or a derived requirement? I'm not sure of the distinction you're making here. Well, once again, it seems like the technical requirement is that: 1. You want to authenticate the server to the client (as noted below, I don't think that the distinction you are making between "assurance" and "authenticate" is sufficiently crisp to be helpful). 2. The only secret information that the server shares with the client is Y_c. But this doesn't necessarily preclude the client *sending* Y_c, it merely requires that it not send it to anyone who hasn't proven they know Y_c first. For instance, if Y_c was used as a PSK (as owen suggests), then it might (again, no analysis here) allow the client to send Y_c in an RFC 7250 certificate message because it would already be being encrypted under a key that required knowing Y_c. [ofriel] This makes sense, and should avoid having to use cTLS ‘Known Certificates’ for the client’s Certificate RPK.
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
