Dear Cigdem,
Thank you for preparing the revised version, it looks pretty good to me.
Some replies inline:
On 3/4/22 14:23, Cigdem Sengul wrote:
Section 1.3:
"Will
If the network connection is not closed
normally, […]"
I suggest to make this a bit more specific:
Does "the network connection" refer to a TCP connection, or a TLS
session? Or
does it refer to MQTT's notion of "connection"? Does "not closed
normally" mean
anything other than a FIN-ACK exchange to close a TCP connection?
Or does it
depend on the used transport protocol (however, in this document,
it should all
refer to TLS over TCP iiuc?) If the notion of a "network
connection is not
closed normally" is a well-defined concept in this context, please
provide a
reference if possible.
[CS: Introduced a formal definition of Network Connection to
MQTT-related terminology - as defined in MQTT standard.
To the Will definition, added the situations when the connection is
considered not to have closed normally.
Question: Normal disconnection is DISCONNECT with reason code is 0x00,
according to MQTT standard - is this definition also needed?"
[TE] So "not closed normally" means any way to terminate the Network
Connection, other than DISCONNECT with reason code 0x00? If so, I think
this would be a good addition to the definition, either as its own
definition or added to the "Will" definition.
Section 2.1
"The PoP token includes a 'cnf' parameter with a
symmetric or asymmetric PoP key. "
The 'cnf' (and 'rs_cnf' in Section 2.2.1) parameter is mentioned
here and in
some other places, but it is not obvious what it means and why it is
special/important. I suggest to provide a brief explanation or
reference.
[CS: Added for cnf:
The AS includes a 'cnf' parameter to the PoP token,
to declare that the Client possesses a particular key and RS can
cryptographically confirm that the Client has possession of that key.
The 'cnf' parameter is REQUIRED if a symmetric key is used, and MAY
be present for asymmetric proof-of-possession keys, as described in
[I-D.ietf-ace-oauth-params].
rs_cnf:
Otherwise, to authenticate the Broker, the Client MUST validate a
public key from a
X.509 certificate or an RPK from the Broker against the 'rs_cnf'
parameter in the token response, which contains information about the
public key used by the RS to authenticate if the token type is "pop"
and asymmetric keys are used as defined in
[I-D.ietf-ace-oauth-params].
[TE] These explanations already help, thanks! However, and this might
just be me, but I keep wondering what 'cnf' stands for, i.e., if it is
an acronym for something, and if it is, if it makes sense to expand the
acronym. But it might just be a string that comes from "somewhere",
which is fine with me, too. :)
Best,
Reese (aka Theresa)
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
