mmccool
commented
6 years ago After re-reading the security section of the CoAP spec cited above, I realized there are three security specifications: psk (which are symmetric pre-shared keys), raw public keys, and X509 certificate-based keys. So we are probably talking two new schemes: "cert" for the X509-based scheme, and maybe "public" for the Raw Public Key mode.
Then we have to figure out what additional parameters are needed. Unlike the psk scheme, with the asymmetric schemes it is possible to put the public keys in the TD. However, an alternative would be to provide a URL from which the keys can be retrieved, which might be a better idea in many ways. I intend to read the CoAP spec above carefully to figure out what (else) might be appropriate.
Comments?
See https://tools.ietf.org/html/rfc7252#section-9.1
Currently we only support PSK mode for CoAP. For completeness, we should also support the "Raw Public Key" mode, which uses X509 certificates and asymmetric keys. I propose the scheme name "cert". We should see if an equivalent scheme can be used with HTTP and MQTT.
[Edit: the above is not an accurate reflection of the CoAP spec, in fact there are two separate schemes for public keys; one uses certificates, one does not. See discussion below.]
We may also want to consider adding ciphersuite parameters to psk and cert, corresponding to the options available for DTLS. Without parameters, the defaults defined for the protocols (eg CoAP in the section above) should be used.