On Tuesday, 30 August 2016 16:19:18 UTC+1, dymu...@gmail.com wrote: > It is interesting that WoSign followed the redirect. I suppose it is assumed > that with a 301 permanent redirect that the new domain is controlled by the > same person, but that seems a bit sketchy.
Hmm. I think that if there's a 301 redirect in place for every URL then in practice the effect is that the target site does control the content of the origin site. Such circumstances already exist without redirects. Suppose the site http://theclown.example.net/ functions as a thin proxy of another site, say http://famous-cloud-provider.example.com/ and simply copies the contents of equivalent resources at this other site, but replaces all instances of the word "cloud" in human-readable text with "clown". An amusing prank. We can expect that the legitimate owner of famous-cloud-provider.example.com would be able to obtain a certificate for theclown.example.net by obeying either the typical ad hoc validation scheme of the sort which you experienced with WoSign, or a Ballot 169-compliant scheme like ACME. This is because it is very unlikely that the validation content would include the exact word "cloud" and so it would pass through the proxy unaltered and be readable by the CA's validation system when checking theclown.example.net But this seems like no great loss, since in fact the contents of theclown.example.net are almost exactly controlled by famous-cloud-provider.example.com, the certificate's implications about who controls theclown.example.net are functionally true. If the legitimate owner of theclown.example.net doesn't want this to be possible under prior ad hoc validation systems it's a bit tricky to prevent, but under Ballot 169 it's simply a matter of making /.well-known/ exempt from the proxy rule, which is anyway already a very good idea. NB. If my musing inspires substantial further debate it should happen in another thread, not this one about WoSign. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy