On Fri, Nov 21, 2014 at 4:53 PM, Patrick McManus <mcma...@ducksong.com> wrote: > Hi - > > On Fri, Nov 21, 2014 at 5:41 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: >> >> >> Indeed. Huge thanks to everyone who is making Let's Encrypt happen. >> >> > regulatory compliance, >> >> What's this about? > > > nosslsearch.google.com is an example of the weight of regulatory compliance > in action.
It's not clear what the regulation in question is. It seems that the stated use case for nosslsearch was allowing schools to MITM searches to filter out "adult" content, but Google seems to be transitioning to addressing this use case by allowing schools to make Safe Search at Google's end non-user-togglable. Anyway, the question I was trying to ask was: For what regulation do all of the following hold: 1) The regulation disallows crypto that is unMITMable without stealing keys or compromising/fooling a CA. 2) The regulation doesn't disallow all crypto but allows MITMable crypto. 3) The way the MITMability is used is decrypting and re-encrypting and not just inhibiting the upgrade. (If the upgrade is inhibited, OE is just plain old HTTP 1.1 after all.) 4) It is congruent with Mozilla's goals to accommodate the regulation beyond just letting the servers subject to the regulation stay on plain old HTTP 1.1. ? >> > non-access to webpki. >> >> Does this mean intranets? > > mostly.. This is basically the Microsoft argument against https. It would be easier to accept if intranet-motivated things didn't leak to the public Web e.g. by being limited to RFC 1918 addresses. A limitation to RFC 1918 addresses would, for sure, irk some intranet admins who use end-to-end IP addressing, but, OTOH, they are better positioned to get publicly-trusted certs for their stuff. If the intranet case can't be isolated, it seems bad to make the public network worse off in order to let the intranet admins have more convenience. (Also, as an intranet gets larger, the notion of trusting the network gets a worse and worse an idea even on an intranet.) > but more generally things that don't bind well to the global dns > that the webpki relies on.. so potentially peer to peer and mesh > interactions too.. How are these relevant to Firefox? (Also, if the thread on the C/ABforum list about issuing a cert for Facebook's .onion address shows anything, I think it shows that it's bad that the built-in validation of a DNS alternative sticks to a layer below http: and doesn't extend https: validation in a way that'd result in a consistent UX [the visible URL scheme being part of the UX] for all authenticated sites--PKI or not.) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
