Subject: [COSE] Review draft-ietf-ace-mqtt-tls-profile-05

From: Jim Schaad <[email-masked]>
Date: Mon, 8 Jun 2020 15:01:52 -0700

* Style Issue. "Abbreviations should be expanded in document title and upon
first use in the document.  Full expansion of the text should be followed by
the abbreviation in parentheses."  Some items such as TLS are considered to
be known by everybody and thus do not need to be expanded.
https://www.rfc-editor.org/materials/abbrev.expansion.txt contains both
"known" and "unknown" abbreviations.  (Yes this means you are going to have
a really long title.)  (I might argue that  OASIS should be listed as well
known.)

* Section 1 - para 1 - Sentence two has a plurality mismatch between client
and server.  I think in this case server (and broker) should be pluralized.

* Section 1.3 - Broker - s/publishes/publish/  The set of pluralized items
seems to be too large by one.

* Section 1.3 - I think we ought to define Session given that we no longer
require that Clean Session be used.

* Section 1.3 - I do not believe that CONNACK is always the first packet
from the broker to a client.  An AUTH message may be the first one.

* Section 2.1 - para 3 s/the public key used by the RS/the public key to be
used by the RS/

* Section 2.1 - I think (but am not sure) that we may need to do some
registrations around the use of thumbprints in a confirmation claim.  If I
forget, please remind me to track this down.

* Section 2.2.2 - para #1 - s/using client authentication/using server
authentication/  If we are doing MQTT as the default then the server not the
client is authenticated here.  You may not want to have lost the potentially
here.

* Section 2.2.3 - I think that the client state MUST include the token and
either the same token is supplied or a token with the same key is supplied
in order to match with an existing state.

* Section 6.2 - I think it makes sense to put in a note that between the
fact that the server will disconnect on almost any error and is not required
to keep session state between connections, clients need to make a greater
effort to ensure that tokens remain valid and they do not attempt to publish
to topics that they do not have permissions for.

* Section 8 - The storage of tokens long term can be restricted to only
current valid ones if an immediate validation of the token is done.  This
means that the RS spends time doing the validation, but does not need to
consume memory.

This is looking really good.  I think we have only two technical issues open
at this point.  The question of registrations for hash identifications in
confirmation claims and if changes to the default scope structure are to be
done.

Jim

---

From: Jim Schaad <[email-masked]>
Date: Mon, 8 Jun 2020 16:11:37 -0700

Wrong list.

-----Original Message-----
From: COSE <[email-masked]> On Behalf Of Jim Schaad
Sent: Monday, June 8, 2020 3:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: [COSE] Review draft-ietf-ace-mqtt-tls-profile-05

Jim

_______________________________________________
COSE mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cose