Subject: [Ace] AUTH48 changes to draft-ietf-ace-coap-est-18.txt

From: Michael Richardson <[email-masked]>
Date: Thu, 31 Mar 2022 09:13:46 -0400

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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide