On Fri, Nov 21, 2014 at 10:39 AM, Patrick McManus <[email protected]> wrote: > > On Fri, Nov 21, 2014 at 10:25 AM, Kathleen Moriarty > <[email protected]> wrote: >> >> That's in line with consensus from the STRINT workshop. Fallback to >> unauthenticated crypto would appear to the user same as an http session. > > > I bet we're on the same page, but I think there is a little potential > confusion in that statement that I want to clarify. > > https:// cannot fallback to unauthenticated crypto and automatically change > the scheme to http:// when it does so for at least 2 reasons: > > 1] https:// demands authenticated crypto and the users of those links expect > that property and we want to promote that > > 2] https://foo/bar and http://foo/bar are simply different origins and > independent resources. There is nothing about the web model that says they > carry the same content over different transports despite our intuition when > looking at them. So we can't go automatically converting from one to the > other and have web compatibility unless the server issues a redirect. > > Instead of being a fallback for https, O-S is an opportunistic upgrade for > otherwise plaintext http://.. ciphertext is the new plaintext for http:// > and it isn't treated any differently in the UI because of it. https:// urls > with self signed certificates will continue to get giant warnings even in > the presence of O-E; nothing about https:// handling changes.
Thanks, Patrick. As long as OS doesn't look the same to the user as an authenticated encrypted session... so not fallback (wrong term), but OS might look the same as HTTP. Sounds good, thanks for your work on this effort! Kathleen > -- Best regards, Kathleen _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
