On Thu, Jul 13, 2017 at 7:07 AM, Gervase Markham via dev-security-policy < [email protected]> wrote:
> On 12/07/17 15:47, Ryan Sleevi wrote: > > One challenge to consider is how this is quantified. Obviously, if you > > reported to Comodo the issue with the key, and then they issued another > > certificate with that key, arguably that's something Comodo should have > > caught. > > I'd say so. > > > However, if you reported the compromise to, say, ACME CA, and then > > Comodo issued an equivalent cert, that's questionable. > > Sure. This would be a provision to deter accidental stupidity, not > wilful stupidity. The common case is a clueless person just resubmits > the same keypair to their current CA. > Right. My point in that was that it's easy to rathole into a definition of "known Key Compromise" that implies an obligation to check others revocation lists to see if a certificate with the same public key has been revoked due to keyCompromise, which is further undesirable given that CAs can't be trusted with the revocation reasons in the first place. My goal was to try to capture that, to some extent, the burden of knowledge can only be on the CA's own direct knowledge - which means it only prevents the subscriber from getting a cert (from the same CA), and not from another CA. This is both a limitation of the mitigation - it doesn't prevent another CA from issuing - and a potential concern from CAs - others can issue what they cannot. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
