search

ace-wg / mqtt-tls-profile

Document for MQTT-TLS-profile
Other
0 stars 2 forks source link

2.2.4.1 - Correct wording for TLS exporter value #41

Closed ciseng closed 4 years ago

ciseng commented 4 years ago

On January 1, 2020, Jim wrote: 2.2.4.1 - In my view it is not the secret, but the content that is being obtained from the TLS exporter.  That is one is signing (or MACing) the exporter value not using that value to compute a MAC on something else. While it is true that only the two parties know that value, exposure to a third party does not lead to a compromise.

ciseng commented 4 years ago

Daniel commented:

Just to make sure I follow, the secret is signed or MACed without being sent. The secret is not used to derive the key used to the signature or MAC. Instead this key is in the access token.  If I am correct, the use of MAC or signature is defined by the PoP symmetric or asymmetric. Correct ? I believe the text could be clearer.  
ciseng commented 4 years ago

Changed the word secret to content. It does say the content is signed or MACed, and sent in the Authentication Data. Rejigged the wording that it is more clear. Added into token validation HS256 and RS256 are mandatory to implement.

jimsch commented 4 years ago

RS256 is an interesting choice, by and large the IETF is going with Ed25519 for signature algorithms at this point although a large number are still stuck with ECDSA w/ P-256.

ciseng commented 4 years ago

I lapsed there. Ed25519 obviously better.

ciseng commented 4 years ago

Changed to Ed25519.