On Thu Nov 20 2014 at 6:02:00 PM Trevor Freeman <[email protected]> wrote:
> 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. > It is different: it is secure against passive attackers. > 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]>, 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 >
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
