The certificate warning paradigm is over blown given that the typical alternative is no TLS. An unauthenticated TLS connection is practically speaking, no different to no TLS at all. The same of true when you see certificate warring messages S/MIME messages when the rest of the inbox is unsigned email. As long as the two cases are treated equal why cannot you dispense with the certificate warning messages?
From: perpass [mailto:[email protected]] On Behalf Of Richard Barnes Sent: Wednesday, November 19, 2014 3:47 PM To: Michael Richardson Cc: perpass Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... On Wed, Nov 19, 2014 at 1:42 PM, Michael Richardson <[email protected]> wrote: Richard Barnes <[email protected]> wrote: >> I don't think this is is this going to help eliminate the invalid >> certificates that seem inevitable from things like ILOMs/iDRAC/etc. because >> the https interface to the service processor never knows what zone it will >> use. I'd love to find a way for such appliance uses of HTTPS to come >> up secure in some way. >> > I would be interested in that as well, since those things are a major > source of cert validation bugs. Any ideas for what the authentication > would be? Or maybe there's no meaningful authentication here, and it's a > use case for HTTP over unauthenticated TLS. I agree that given what we have here, HTTP over unauthenticated TLS (with TOFU, ideally) would be significant better than training IT managers to click through the warning. I think that we should have, as a goal, elimination of the click through certificate warning... nobody should ever do that. In the case of an ILOM, we can't predict a name or an IP address which the device can claim... but, the manufacturer usually has a MAC address, Asset Tag, or other identifier which is often unique. If only *THAT* could go into the Location Bar instead of the IP address. Yes, this is user interface thing... sorta.. it's really about a different kind of URI. We do have some history of putting identifiers besides domain names in the URL bar. Namely with EV certs, browsers typically display the authenticated owner name. So the real question is whether it's possible to make a PKI that can authenticate those identifiers. We would of course need some new types for subjectAltName, but that's just more OIDs. The more interesting question is how the PKI would be structured -- who are the trusted authorities for asset tags? --Richard -- Michael Richardson <[email protected] <mailto:mcr%[email protected]> >, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
