On 18.9.2014, at 18.17, Michael Thomas <m...@mtcc.com> wrote: > On 09/18/2014 06:49 AM, Markus Stenberg wrote: >> On 18.9.2014, at 16.05, Ted Lemon <mel...@fugue.com> wrote: >>> On Sep 18, 2014, at 7:38 AM, STARK, BARBARA H <bs7...@att.com> wrote: >>>> X.509 certificates can be self-signed. That is, the device acts as its own >>>> CA. In fact, this is the recommended approach. >>> Of course. But if there is never going to be a CA-signed key, there is no >>> reason to have a cert at all. Self-signed certs are essentially a way of >>> carrying a bare key in a cert, unless you install your signer key as a CA >>> key, in which case you have an administratively configured CA key that is >>> signing the cert, and it’s no longer really a self-signed cert. >> On the other hand, use of certificates facilitates also use of something >> like (hardware bound) device certificates, that would be much harder to >> generate on demand (and therefore blacklisting them might actually make >> sense in opportunistic scheme). > With device certificates, you still have the original authz problem. That is, > just because I can identify you > reliably tells me nothing about whether I want to participate with routing > updates with you. So in that > way, they not any more useful than naked keys.
If the device certificate is on hardware, you cannot generate them at will, and therefore they _are_ more useful as you can e.g. blacklist device and be sure that even with leap of faith code active, it will not come out of woodwork with new certificate. (See above.) Cheers, -Markus _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
