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.
"need" isn't an explicitly spelled out requirement, I agree, but falls from
the logical consequences of designing such a system and ensuring equivalent
security properties. For example, consider 4.9.10's requirement that OCSP
responses for subordinate CA certificates not have a validity greater than
1 year (!!). We know that's a clear security goal, and so a CA needs to
ensure they can meet that property. If issuing a Delegated Responder, it
logically follows that its validity period should be a year or less,
because if that Delegated Responder is compromised, the objective of 4.9.10
can't be fulfilled. I agree that a CA might argue "well, we published a new
response, and 4.9.10 doesn't say anything about having to result, just
perform the action", but I think we can agree that such an approach, even
if technically precise, calls into question much of their overall
interpretation of the BRs.
> > 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).
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?
> 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"
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"
> 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.
> This situation does suggest that root programs should consider adding
> public requirements around:
> 1) Delegation of OCSP response generation to third parties
> 2) Maximum validity period of OCSP responder certificates
> 3) Use of CA private keys, specifically requirements for data they sign
>
Whole heartedly agree that this reveals greater clarity of profiles are
needed, and will be working on resurrecting/rebasing
https://github.com/sleevi/cabforum-docs/pull/2 to try and account for some
of this. Those are "prevent" solutions, and we're focused here on "detect
and mitigate" solutions.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
