Hello Jim, Thank you for your email. I am in the process of revising the document for the December update agreed in Singapore, so these comments are extremely helpful. Comments are inline.
On Thu, Dec 5, 2019 at 6:19 AM Jim Schaad <[email protected]> wrote: > I got to the point of needing to start producing and validating > certificates > for MQTT and started running into some questions as well as starting to > pickup some odd information that this document does not point to. > > 1. Should probably reference the mqtt(s) URI scheme, I am however somewhat > irritated that it is not a registered scheme with IANA. > Indeed, we used MQTT over TLS to mean MQTTS, though it is not mentioned explicitly in the MQTT v5 OASIS spec, but here: https://github.com/mqtt/mqtt.github.io/wiki/URI-Scheme Do you suggest we reference this? The latest I know: "The URI scheme has been discussed by the technical committee a few times. The proposal was to produce a committee note rather than make it a formal part of the spec." based on this - https://github.com/mqtt/mqtt.github.io/issues/41 I will see if I can find more information from OASIS. 2. Has OASIS done anything sort of document for certificate validation. As > an example is there an OID defined for extended key usage? > This is what is mentioned in the MQTT v5 for authenticating the AS with a certificate: "Implementations providing MQTT service for multiple hostnames from a single IP address should be aware of the Server Name Indication extension to TLS defined in section 3 of [RFC6066] <https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#RFC6066>. This allows a Client to tell the Server the hostname of the server it is trying to connect to." I also found the following information when first writing the draft: https://www.oasis-open.org/committees/download.php/50161/X-MQTT-Security.txt that goes into some detail but did not cite it because it did not look official. However, it at least mentions things like TLS versions and certificate types. > > 3. What should be said about matching data in the response from the AS and > the certificate. What should be said about matching for raw public keys. > I > think that later is easy as it should just match the rs_cnf returned from > the AS, but I don't know what should be said for certificates. > At the moment I have the following text: The Broker MUST be authenticated during TLS handshake. If the Client authentication included TLS:Known(RPK/PSK), then the Broker is authenticated using the respective method. For the other Client Authentication cases, to authenticate the Broker, the client MAY either have the ability to receive and validate a server-side certificate or an RPK from the Broker checked against the 'rs_cnf' parameter in the token. The reason why I did not go into more detail for TLS/certificate use on the server-side, was because MQTT OASIS standard recommends it but does not go into detail (as discussed in the previous points). And my experience with mqtt brokers that they define how to set it up in their config pages: e.g., HiveMQ with BoringSSL https://www.hivemq.com/docs/4.2/hivemq/security.html (HiveMQ is what Edinburgh colleagues are implementing ACE mqtt-tls profile with now). or Mosquitto with OpenSSL https://mosquitto.org/man/mosquitto-conf-5.html https://mosquitto.org/man/mosquitto-tls-7.html My assumption was that for MQTT developers who have opted for a certain MQTT implementation and want to use server-side certificates, they would continue configuring the server-side TLS as they always do, and then use the ACE plugin to do the client authentication/authorisation. > > 4. With the definition of some guidance in COSE, should there be a field > for doing certificates in the rs_cnf - returning a fingerprint not the > entire certificate. > This is interesting - do you mean working with this draft: https://tools.ietf.org/html/draft-ietf-cose-x509-04 Thanks, --Cigdem > > Jim > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
