One advantage of using X.509 certs is that the code to support them is widely
available with multiple implementations.
I guess then you could go all the way and use the whole DTLS for HNCP
unicast traffic (and keep MC unencrypted since its more or less a
signaling channel for UC and doesn't contain sensitive data). This would
then avoid the need to redefine and reimplement most of the DTLS
features in HNCP anyway.
Cheers,
Steven
Another is that the same cert can be used for TLS negotiation in embedded web
services, etc. to each device.
And of course if the registration mechanism is integrated into client OS's then
those X.509 certs can easily participate in the usual trust policy stuff
supported by those OS's.
On Sep 18, 2014, at 6:34 AM, Ted Lemon <[email protected]> wrote:
On Sep 18, 2014, at 4:27 AM, STARK, BARBARA H <[email protected]> wrote:
UPnP Device Protection uses X.509 certificates (which can be self-signed, and
in order not to assume a WAN connection, really should be self-signed) and TLS.
I think that something like this, in combination with the promiscuous
registration mechanism that I think Michael described earlier, would do the
trick. It's not clear that we need X.509 certs, since I have trouble
imagining that the keys these devices have would ever be signed by a CA. A
bare key might be plenty. But I think this is a better option than trying to
shoehorn this functionality into IPsec, which was designed for a _very_
different security context.
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
