Hi Ryan, Kathleen has responded, but here are my two cents:
On 14/10/16 13:21, Ryan Sleevi wrote: > It seems to accomplish this, you're willing to continue to trust that > WoSign will not demonstrate any of the past behaviours it already > demonstrated - such as backdating and misissuance, but not to issue > new certificates. Is that correct? It is not that are we willing to blindly trust them on this; it is that we believe that in practice it will be impossible for them to backdate lots of certs to get around the block without it being detected. Such certs, of course, would need to be CT-less, although both CAs have committed to full CT from now on, and both have loaded "every" cert since a certain date into CT. If loads of CT-less older WoSign or StartCom certs with long lifetimes started turning up on their customers sites, it would be fairly obvious. > As a consequence of this - which, > to be fair, is not a problem of Mozilla's creation - there exists the > ecosystem risk that in order to minimize any incompatibilities, these > applications will need to continue to trust WoSign and StartCom for > as long as other popular programs - such as Mozilla - do. Everyone needs to make their own trust decisions, which will be affected by what decisions their code lets them make. A while ago, Mozilla was in this sort of position, but we did engineering work and now the situation is not so bad. I don't think any platform would have size or code constraints on implementing our notBefore solution. A whitelist may have problems, but we aren't proposing we use one. > impact. For example, fully distrusting these certificates in, say, 6 > months, would allow other players in the ecosystem to take > appropriate steps and block these certificates, without having to > suffer the first-mover/only-mover problem. See Kathleen's response. Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
