Hi, draft-ietf-ace-coap-est-18 finished the author interaction and approval a couple of weeks ago. One of the things that came up at the last minute was the way in which "tls-unique" from TLS 1.2 is replaced with a key exporter in TLS 1.3.
This is explained in draft-ietf-kitten-tls-channel-bindings-for-tls13,
and we added an informative to reference to that document.
This was suggested by the Area Director, and the authors were completely in
agreement.
Basically, we inserted this paragraph in section 3.
For (D)TLS 1.3, Appendix C.5 of [RFC8446] describes lack of
channel bindings similar to tls-unique. [TLS13-CHANNEL-BINDINGS] can
be used instead to derive a 32-byte tls-exporter binding from the
(D)TLS 1.3 master secret by using a PRF negotiated in the (D)TLS 1.3
handshake, "EXPORTER-Channel-Binding" with no terminating NUL as the
label, the ClientHello.random and ServerHello.random, and a zero-
length context string. When proof-of-possession is desired, the
client adds the tls-exporter value as a challengePassword in the
attributes section of following the algorithm described PKCS #10
CertificationRequest [RFC5967] to
prove that the client is indeed control the private key at the
time of the (D)TLS session establishment.
This email is something we meant to send at the time, but we didn't assign
someone to do that. I was cleaning up my inbox...
I think the RFC itself will emerge from RPC any minute now.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
