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.
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
