On Fri, Jul 3, 2020 at 9:18 AM Ryan Sleevi <r...@sleevi.com> wrote: > > > > On Fri, Jul 3, 2020 at 10:57 AM Peter Bowen <pzbo...@gmail.com> wrote: >> >> While it may be viewed as best practice to have short lived responder >> certificates, it must not be viewed as a hard requirement for the BRs >> or for the Mozilla program. As you have pointed out previously, a >> browser could make this a requirement, but I am unaware of any >> publicly available requirement ot do so. > > > Thanks, and I think you're making a useful clarification here. The 'need' > being talked about is the logical consequence of a secure design, and the > assumptions that go with it, as well as the role the BRs play in "profiling > down" RFC 5280-and-related into sensible subsets appropriate for their use > case. > > I think we're in agreement here that nocheck is required, and that the > consequences of nocheck's presence, namely: > CAs issuing such a certificate should realize that a compromise of > the responder's key is as serious as the compromise of a CA key > used to sign CRLs, at least for the validity period of this > certificate. CAs may choose to issue this type of certificate with > a very short lifetime and renew it frequently. > > As BR-consuming clients, the majority of implementations I looked at don't > recursively check revocation for the delegated responder. That is, rather > than "nocheck" determining client behaviour (vs its absence), "nocheck" is > used to reflect what the clients will do regardless. This can be > understandably seen as 'non-ideal', but gets back into some of the discussion > with Corey regarding profiles and client behaviours.
So we are in agreement that is a certificate consumer bug if it fails to check revocation on certificates that do not have nocheck set. (Yes, I know that is a massive set of negations, sorry.). Good news is that all the certificates are in the category of "need revocation checking". >> > It seems we’re at an impasse for understanding the issue for >> > internally-operates Sub CAs: this breaks all of the auditable controls and >> > assurance frameworks, and breaks the security goals of a “correctly” >> > configured delegated responder, as discussed in the security considerations >> > throughout RFC 6960. >> >> This is where I disagree. Currently CAs can create as many delegated >> OCSP responder certificates as they like with as many distinct keys as >> they like. There are no public requirements from any browser on the >> protection of OCSP responder keys, as far as I know. The few >> requirements on revocation information are to provide accurate >> information and provide the information within 10 seconds "under >> normal operating conditions" (no SLO if the CA determines it is not >> operating under normal conditions). > > > I suspect this is the reopening of the discussion about "the CA organization" > or "the CA certificate"; does 6.2.7 apply to all Private Keys that logically > make up the CA "the organization"'s services, or is 6.2.7 only applicable to > keys with CA:TRUE. Either extreme is an unsatisfying answer: do the TLS keys > need to be on FIPS modules? (no, ideally not). Does this only apply to CA > keys and not to delegated responders (no, ideally not). As I read the BRs today, the requirement only applies to CA keys and not to keys for delegated responders. However that does not matter in this case, because all the certificates you identified are for CAs, so we know their keys are in HSMs. > Going back to 6960 and the requirement of pkix-nocheck, we know that such a > responder certificate is 'as powerful as' the Private Key associated with the > CA Certificate for which the responder is a responder for. Does the > short-lived validity eliminate the need for protection? > > I suspect when you disagree, is with respect to the auditable > controls/assurance frameworks, and less with respect to security goals > captured in 6960, since we seemed to agree on those above. > >> >> For the certificates you identified in the beginning of this thread, >> we know they have a certain level of key protection - they are all >> required to be managed using cryptographic modules that are validated >> as meeting overall Level 3 requirements in FIPS 140. We also know >> that there CAs are monitoring these keys as they have an obligation in >> BR 6.2.6 to "revoke all certificates that include the Public Key >> corresponding to the communicated Private Key" if the "Subordinate >> CA’s Private Key has been communicated to an unauthorized person or an >> organization not affiliated with the Subordinate CA". > > > Sure, but we know that such revocation is largely symbolic in the existence > of these certificates for the vast majority of clients, and so the security > goal cannot be reasonably demonstrated while that Private Key still exists. > > Further, once this action is performed according to 6.2.6, it disappears with > respect to the obligations under the existing auditing/reporting frameworks. > This is a known deficiency of the BRs, which you rather comprehensively tried > to address when representing a CA member of the Forum, in your discussion > about object hierarchies and signing actions. A CA may have provisioned > actions within 6.2.10 of their CPS, but that's not a consistent baseline that > they can rely on. > > At odds here is how to square with the CA performing the action, but not > achieving the result of that action? As long as the key is a CA key, the obligations stand. >> I agree with Pedro here. If the CA has control over the keys in the >> certificates in question, then I do not see that there is a risk that >> is greater than already exists. The CA can determine that these are >> approved OCSP responders and easily assess whether they have controls >> in place since the creation of the certificate that provide assurance >> that all OCSP responses signed using the key were accurate (if any >> such responses exist). They can also easily validate that they have >> controls around these keys to provide assurance that any future OCSP >> responses signed using the key will be accurate, the same that they >> presumably do for their other OCSP responders. > > > But that's not an assurance "we", the relying party, have. We don't have a > way to know what process the CA used to assess what controls they have in > place, and whether those controls were reliable. After all, CAs were supposed > to have controls in place with respect to Delegated Responders, and this > incident is, in part, because some CAs assessed those controls as compliant, > but they were not. This is the breakdown of assurance I spoke to above. You > yourself are familiar with the fact that 5.4.1 of the BRs doesn't actually > require that CAs maintain logs of the messages they've signed via the HSM, so > that's not a guarantee we can simply take at face value. > > Obviously, we're talking about a spectrum of responses, and I am of course > interested if there are options other than what I've outlined, based on facts > not yet considered. > > I would hope we would agree that if a CA simply revoked the certificate, and > did nothing beyond that (no reissuance, no destruction), it would not provide > the necessary assurance regarding that key. > - The key would be outside the scope of much of the audited activities, > which are presently oriented around "certificates" > - For the lifetime of the certificates that were revoked, we have to worry > that they, or their siblings, may "come back to haunt us" Agreed, simply revoking doesn't solve the issue; arguably it makes it worse than doing nothing. > Pedro's option is to reissue a certificate for that key, which as you point > out, keeps the continuity of CA controls associated with that key within the > scope of the audit. I believe this is the heart of Pedro's risk analysis > justification. > - However, controls like you describe are not ones that are audited, nor > consistent between CAs > - They ultimately rely on the CA's judgement, which is precisely the thing > an incident like this calls into question, and so it's understandable not to > want to throw "good money after bad" To be clear, I don't necessarily see this as a bad judgement on the CA's part. Microsoft explicitly documented that _including_ the OCSP EKU was REQURIED in the CA certificate if using a delegated OCSP responder (see https://support.microsoft.com/en-us/help/2962991/you-cannot-enroll-in-an-online-certificate-status-protocol-certificate). Using a delegated OCSP responder can be a significant security enhancement in some CA designs, such as when the CA key itself is stored offline. >> So, from my personal view, what needs to happen here is that each CA >> needs to acknowledge each of the keys in the certificats as a valid >> OCSP responder key, according to their internal procedures for such, >> if they have not already done so. Then they need to revoke the >> certificates and issue new certificates with different serial numbers >> that do not have the OCSP EKU to correct the certificate profile >> issue. While not required, they should also consider having controls >> in place for the lifetime of the key (until destruction) to provide >> assurance that any OCSP responses it signs are accurate, as we know >> some certificate status consumers may not check the validity of the >> response signer certificate. > > > Is this from the point of view of "what meets the compliance obligations" or > "what demonstrates the CA understands the risks, has sufficient safeguards, > and can demonstrate them other than 'trust us'"? > > I readily admit, I framed the security issue within a compliance issue > precisely because CAs were having trouble recognizing the security issue. I > would hate to see the response predicated on treating it like a compliance > issue, though. When you talk about "while not required", that is indeed the > heart of what I'm talking about in terms of how do we mitigate the security > risks? "It's a security risk, but we're not required to address it" is, I > think, a reasonable ground to criticize the incident response and the CA's > handling of it. > > The question of controls in place for the lifetime of the certificate is the > "cost spectrum" I specifically talked about in > https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13530.html > , namely "Well, can't we audit the key usage to make sure it never signs a > delegated OCSP response". > > As I mentioned, I think the response to these incidents is going to have to > vary on a CA-by-CA basis, because there isn't a one-size-fits-all category > for mitigating these risk factors. Some CAs may be able to demonstrate a > sufficient number of controls that mitigate these concerns in a way that some > browsers will accept. But I don't think we can treat this as "just" a > compliance failure, particularly when the failure means that the intended > result of a significant number of obligations cannot be met because of it. As you pointed out, I pushed for a number of improvements in WebTrust audits when I was involved with operation of a publicly trusted CA. One of those resulted in practitioner guidance that is relevant here. In the guidance at https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/practitioner-qualification-and-guidance , you can see two relevant items: - Reporting When Certain Criteria Not Applicable as Services Not Performed by CA - Disclosure of Changes in Scope or Roots with no Activity This makes it clear that auditors can report on the absence of activity. In an attestation engagement, the auditor can also provide an opinion on statements in the attestation that can be tested, regardless of whether they match a specific criteria in the audit criteria. Given this, I believe relying parties and root programs could determine there are sufficient controls via audit reporting. The CA can include statements in the assertion that (as applicable) the keys were not used to sign any OCSP responses or that the keys were not used to sign OCSP responses for certificates issued by CAs other than the CA identified as the subject of the CA certificate where key is bound to that subject. I think (but an auditor would need to confirm) that an auditor could be in a position to make statements about past periods based on the controls they observed at the time, as recorded in their work papers. For example, a CA might have controls that a given key is only used during specific ceremonies where all the ceremonies are known to not contain inappropriate OCSP response signing. Alternatively the configuration of the HSM and attached systems that the auditor validated at the time may clearly show that OCSP signing is not possible and the auditor may have observed controls that the key is restricted to only be used with the observed system configuration. I agree that we cannot make blanket statements that apply to all CAs, but these are some examples where it seems like there are alternatives to key destruction. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
