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.
dev-security-policy mailing list