On Fri, Jul 14, 2017 at 10:03 AM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On Fri, Jul 14, 2017 at 9:44 AM, Hanno Böck via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > So there are several questions and possible situations here. > > > > I think it's relatively clear that a CA could prevent reissuance of > > certs if they know about a key compromise. > > > > I actually don't think it's clear, that's why I was trying to highlight the > challenges. > > That is, I think we can all agree that for situations where you reported > directly to the CA, it was clear that the CA had knowledge that the > associated private key was compromised. Presumably, a requirement to > prevent issuance would mean that the CA maintains a blacklist of > 'compromised keys' and refuses to issue certificates for them. > > However, if we say that the CA shall not prevent for situations of > compromise, the following interpretations exist, and we should try to > figure out first what we want (from an ecosystem) and then how to specify > that. > - Are we expecting the CA to maintain a database of compromised private > keys (I believe the implied answer is 'yes' - but today, they only need > maintain the database of revoked certificates, which is different) > - Is the CA obligated to check other sources of compromise information > prior to issuing the certificate. > - Example: Should they check other CAs' CRLs? The CRLs themselves don't > provide information about the key, so one would presumably _also_ need to > check sources like Certificate Transparency. > - Tortured example: What happens if a (different CA's) cert is not logged > in CT, revoked in the CRL (for keyCompromise), and then subsequently > disclosed to first CA. Are they obligated to revoke (under 4.9.1.1 #3)? Are > they obligated to not issue (under the proposed change)? > > The reason I highlight this is that preventing CA "Foo" from issuing a > second cert for (compromised) key X doesn't prevent CA "Bar" from doing the > same. Because of this, it's a reasonable question about what security value > we're obtaining, if the party with Key X can simply go to another CA to get > the cert. > > From a CA perspective, requiring that Foo reject a request that Bar can > accept would be unappealing to Foo - it's effectively giving business to > Bar (whether or not this is actually the case, and however illogical it is, > there are plenty of CAs who think this way) > > From a security perspective, requiring that Foo not issue for key X doesn't > ensure that a cert for key X will not be introduced, not unless we make the > requirement of all CAs. > > So that's why I'm not sure how much value we'd get from such a requirement > - and wanted to highlight the challenges in finding a way to establish it > for all CAs, and why it's important (for CAs and relying parties) for a > consistent requirement. > > > > Ultimately I'm inclined to say that there really shouldn't be any good > > reason at all to ever reuse a key. (Except... HPKP) > > > I see. I think I'd strongly disagree with that assertion. There are lots of > good reasons to reuse keys. The most obvious example being for > shorter-lived certificates (e.g. 90 days), which allow you to rotate the > key in case of compromise, but otherwise don't require you to do so. > Considering revocation information is no longer required to be provided > once a certificate expires, it _also_ means that in the CA Foo case, with > Key X compromised, the subscriber could get another cert for it once the > original cert has expired (and thus revocation information no longer able > to be provided) > What you described is a case where it's not harmful to reuse a key, not a case in which it's a good reason to. Indeed defaulting to rotating your key on every new certificate is probably the safest choice, as it ensures that "key compromise" is no different from any other rotation, and keeps that hinge well oiled. Alex > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
