[Ace] Version -03 prep for draft-ietf-ace-mqtt-tls-profile

Cigdem Sengul <cigdem.sengul@gmail.com> Wed, 18 December 2019 10:56 UTC

MIME-Version: 1.0
From: Cigdem Sengul <cigdem.sengul@gmail.com>
Date: Wed, 18 Dec 2019 10:56:40 +0000
Message-ID: <CAA7SwCOryGZ93OGzmoQif_VES1V9uGy_NYAqiNxyFxS=k6AD2g@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>, Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org>
Cc: Ace Wg <ace@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004e47970599f84de4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/ph5ZyszBrOGMVagum_Uwi27JAjE>
Subject: [Ace] Version -03 prep for draft-ietf-ace-mqtt-tls-profile
Precedence: list

Dear Jim and Daniel,

As discussed in Singapore, we've started working on the -03 based on the
comments we've received.

https://github.com/ace-wg/mqtt-tls-profile/tree/v-03-WIP

The main changes are:
 Version 02 to 03:
 1) Added the option of Broker certificate thumbprint in the 'rs_cnf' sent
to the Client.
 2) Clarified the use of a random nonce from the TLS Exporter for PoP,
added to the IANA requirements that the label should be registered.
 3) Added a client nonce, when Challenge/Response Authentication is used
between Client and Broker.
 4) Clarified the use of the "authz-info" topic and the error response if
token validation fails.
 5) Added clarification on wildcard use in scopes for publish/subscribe
permissions
 6) Reorganised sections so that token authorisation for publish/subscribe
messages are better placed.
7) Clarified protection of Application Message payload as out of scope, and
cited draft-palombini-ace-coap-pubsub-profile for a potential solution

Could you provide input regarding the following:
1) Based on Jim's suggestion I added a statement that says:
 The AS MAY include the thumbprint of the RS's X.509 certificate in the
'rs_cnf'
(thumbprint as defined in <xref target="I-D.ietf-cose-x509"></xref>),
 then the client MUST validate the RS certificate against this thumbprint.
Is this implemented by rs_cnf = x5t

and then the client computes the hash and checks against x5t?


Regarding other questions raised by Jim on OASIS certificate guidelines and
the mqtt/mqtt(s), I have not managed to get more information than:

   1.

   there is no official UIR scheme but there is a community wiki entry
   which proposes something:
   https://github.com/mqtt/mqtt.github.io/wiki/URI-Scheme. The MQTT 5
   server redirection feature uses a very simple way of indicating a server
   reference, see
   https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html#_Server_redirection
   2.

   There's currently no certificate validation document. The
   recommendations linked in the spec can be found here:
   https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901280
   .

2) I temporarily added the exporter label to our draft but will wait on the
final decision on that.
So, if it is defined and registered in another document, I can refer to it.

I will push changes as 03 once there is an agreement on how to resolve
these issues.

Kind regards,
--Cigdem

[Ace] Version -03 prep for draft-ietf-ace-mqtt-tl… Cigdem Sengul