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]>, 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
