Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
Hello all, My colleague Andre and I recently became aware of this problem and we explored a new solution to it. Please find our analysis below. For a formatted version of this message with images inline, please find it available at: https://research.kudelskisecurity.com/2020/11/16/a-solution-to-the-dangerous-delegated-responder-certificate-problem/ === Issue of the Dangerous Delegated OCSP Responder Certificate 1. Introduction In this memo, we address the issue of the "Dangerous Delegated OCSP Responder Certificate" [1]. We propose a new solution, different from the original solution suggested in the Mozilla Dev Security Policy (mdsp) mailing list. This proposed solution addresses compliance issues, security risks, feasibility, time to implement and practicability (e.g. operational aspects) as well as negative financial consequences. For the feasibility, please consider the Proof of Concept provided in [2]. This memo is structured as follows. First, section 2 below describes and compares the two solutions. Then, section 3 analyzes them by providing an extensive list of potential concerns and discussing each of them in detail. To illustrate the analysis further, a complete set of diagrams is available at [3]. 2. Description of the initial situation and the two solutions 2.1. Initial situation Image: https://raw.githubusercontent.com/kudelskisecurity/dangerous-ocsp-delegated-responder-cert-poc/master/img/initial_situation_diagram.jpg Figure 1: Initial situation - 4-level hierarchy In Figure 1, SICA contains the problematic id-kp-ocspSigning Extended Key Usage (EKU). The goal is to reach a situation where the EE certificate can be verified up to the root CA in a chain where this EKU extension is not present anymore. Indeed, the mere presence of this EKU makes SICA a delegated OCSP responder on behalf of ICA. If SICA was intended to be an issuing CA and not an OCSP responder, there is the security risk that SICA signs an OCSP response for any sibling certificate on behalf of ICA. This is a huge security concern if siblings are not operated by the same company/entity. This risk can impact all the Sub-CA companies having certificates under ICA. Hence, it is important that all the direct children certificates of ICA that have this problem are neutralized. In addition to the security risk, there is also a compliance issue that is introduced because the Baseline Requirements [4] state that OCSP responders must also have the id-pkix-ocsp-nocheck extension in addition to the EKU. 2.2. Original solution Image: https://raw.githubusercontent.com/kudelskisecurity/dangerous-ocsp-delegated-responder-cert-poc/master/img/original_solution_diagram.jpg Figure 2: Original solution - 4-level hierarchy The original solution addresses the issue in the following way (see Figure 2): (i) a new SICA2 certificate is issued. It is signed by ICA and is based on a new key pair; (ii) the old SICA certificate is revoked and, very importantly for security reasons, its associated private key is destroyed during an audited ceremony; (iii) new EE2 certificates are issued by SICA2. 2.3. New solution Image: https://raw.githubusercontent.com/kudelskisecurity/dangerous-ocsp-delegated-responder-cert-poc/master/img/new_solution_diagram.jpg Figure 3: New solution - 4-level hierarchy The new solution addresses the issue as illustrated in Figure 3, which can be summarized as follows: (i) RCA issues a new ICA2 certificate, using a new DN and a new key pair; (ii) RCA revokes the old ICA; (iii) ICA2 issues a new SICA2 certificate, which reuses the same SICA DN and key pair but does not contain the OCSP problematic EKU; (iv) SICA is also revoked. Since the same DN and key pair are reused for SICA2, the EE certificate is still valid. Also, the new SICA2 cannot be involved in any OCSP response, in any context at all (removal of the problematic EKU). The old SICA cannot be involved in any OCSP response either, in any context at all (it does not validate with regard to the new ICA2 and ICA is revoked). Finally, no third party, which would not have properly done the job of properly renewing a problematic SICA certificate, can do any harm to any other company (the old validation branch is not available anymore by the revocation of ICA). 2.4. Differences between the 2 solutions 2.4.1. 3-level vs 4-level hierarchy The original solution works in both a 3-level hierarchy and 4-level hierarchy. The new solution works only in a 4-level (or more) hierarchy because that hierarchy allows for the parent of the affected certificate to be revoked because it is not a trust anchor. Therefore, no third party can be affected because nobody trusts that chain anymore. This is impossible to achieve in the 3-level hierarchy because the parent of the affected certificate is a trust anchor and cannot be revoked. 2.4.2. Risk surface However, each solution induces a different risk surface. On the one hand, the new solution involves only one
Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise
On Mon, 16 Nov 2020 10:13:16 +1100 Matt Palmer via dev-security-policy wrote: > I doubt it. So far, every CA that's decided to come up with their own > method of proving key compromise has produced something entirely > proprietary to themselves. At least two CAs (and from what I can tell likely more) offer ACME APIs and thus ACME key compromise revocation (RFC 8555 section 7.6) The server MUST also consider a revocation request valid if it is signed with the private key corresponding to the public key in the certificate. I appreciate that this is less convenient to your preferred method of working, but it doesn't seem proprietary to agree on a standard way to do something and my impression was that you could talk to ACME now? > I have no reason to believe that, absent > method stipulation from a trust store, that we won't end up with > different, mutually-incompatible, unworkable methods for > demonstrating key compromise equal to (or, just as likely, exceeding) > the number of participating CA organisations. OK, so in your opinion the way forward on #205 is for Mozilla policy to mandate acceptance of specific methods rather than allowing the CA to pick? Or at least, to require them to pick from a small set? > Of course, the current way in which key compromise evidence is > fracturing into teeny-tiny incompatible shards is, for my purposes, a > significant *regression* from the current state of the art. > Currently, I can e-mail a (link to a) generic but > obviously-not-for-a-certificate CSR containing and signed by the > compromised key, and it gets revoked. No CA has yet to come back to > me and say "we can't accept this as evidence of key compromise". But your earlier postings on this subject suggest that this is far from the whole story on what happens, not least because you sometimes weren't immediately able to figure out where to email that CSR to anyway or the responses, though not "we can't accept this" were... far from ideal. > This format allows the pre-generation of compromise attestations, so > that I don't need to keep a couple of million (ayup, there's a lot of > keys out there) private keys online-accessible 24x7 to generate a > real-time compromise attestation in whatever hare-brained scheme the > affected CA has come up with -- not to mention the entertainment > value of writing code to generate the compromise attestations for > each of those schemes. Experience with other elements of CA operations suggests that CAs don't like writing the other side of the code either, and so tend to coalesce on a smaller number of implementations especially when there's no opportunity to differentiate their product. > In an attempt to keep the madness under some sort of control, I've > tried to codify my thoughts around best practices in a pre-draft RFC > (https://github.com/pwnedkeys/key-compromise-attestation-rfc) but so > far it doesn't look like anyone's interested in it, and every time I > think "oh, I should probably just go and submit it as an Experiment > through the IETF individual stream and see what happens" the > datatracker's not accepting submissions. Well, it is IETF 109 now so yes, this isn't the right moment for new drafts. My guess is that the closest match in terms of existing working groups is probably either LAMPS - but that is only really chartered to fix existing stuff, not explore new territory; or ACME - but ACME already solved the key compromise revocation problem as far as they're concerned. So, yes, individual submission is likely the way to go if you want this published. If expressions of interest are worth anything I can offer to read an Internet Draft and provide feedback but you might not like my feedback. For example the current text says: "Given a valid signature, the subjectPKInfo in the CSR MUST be compared against the subjectPublicKey info of the key(s) which are to be checked for compromise." But formats I've seen for keys (as opposed to certificates) do not contain a "subjectPublicKey info" and so I guess what you actually want to do here is compare the entire key. Explaining how to do that exactly while being neutral about how that key might be stored will be difficult, you might have to just pick a format. Also is RFC 7169 really the best available poison extension for this purpose? You understand it was intentionally published on April 1st right? Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise
On Sun, Nov 15, 2020 at 04:52:38AM +, Nick Lamb via dev-security-policy wrote: > This makes clear that the CA must have at least one of these "clearly > specified" accepted methods which ought to actually help Matt get some > traction. I doubt it. So far, every CA that's decided to come up with their own method of proving key compromise has produced something entirely proprietary to themselves. I have no reason to believe that, absent method stipulation from a trust store, that we won't end up with different, mutually-incompatible, unworkable methods for demonstrating key compromise equal to (or, just as likely, exceeding) the number of participating CA organisations. Of course, the current way in which key compromise evidence is fracturing into teeny-tiny incompatible shards is, for my purposes, a significant *regression* from the current state of the art. Currently, I can e-mail a (link to a) generic but obviously-not-for-a-certificate CSR containing and signed by the compromised key, and it gets revoked. No CA has yet to come back to me and say "we can't accept this as evidence of key compromise". This format allows the pre-generation of compromise attestations, so that I don't need to keep a couple of million (ayup, there's a lot of keys out there) private keys online-accessible 24x7 to generate a real-time compromise attestation in whatever hare-brained scheme the affected CA has come up with -- not to mention the entertainment value of writing code to generate the compromise attestations for each of those schemes. In an attempt to keep the madness under some sort of control, I've tried to codify my thoughts around best practices in a pre-draft RFC (https://github.com/pwnedkeys/key-compromise-attestation-rfc) but so far it doesn't look like anyone's interested in it, and every time I think "oh, I should probably just go and submit it as an Experiment through the IETF individual stream and see what happens" the datatracker's not accepting submissions. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise
On Sun, Nov 15, 2020 at 6:02 AM Dimitris Zacharopoulos wrote: > > > On 2020-11-15 1:04 π.μ., Peter Bowen via dev-security-policy wrote: > > On Sat, Nov 14, 2020 at 2:05 PM Ryan Sleevi via dev-security-policy > > wrote: > >> So, perhaps now that we've had this conversation, and you've learned > about > >> potentially illegitimate revocations are a thing, but that they were not > >> the thing I was worrying about and that you'd misunderstood, perhaps we > can > >> move back to the substantive discussion? > > Going back to earlier posts, it seems like CAs could include a > > statement in their CPS separate from key compromise that they may > > revoke a certificate at any time for any reason or no reason at their > > sole discretion. That would allow the CA to choose to accept proofs > > of key compromise that are not listed in the CPS based on their > > internal risk methodologies, correct? It does still have the "secret > > document" issue, but moves it away from key compromise and makes it > > clear and transparent to subscribers and relying parties. This means > > the CA could revoke the subscriber certificate because they have an > > internal procedure that they roll a bunch of D16 and revoke any > > certificate with a serial number that matches the result. Or the CA > > could revoke the certificate because they got a claim that the key in > > the certificate is compromised but it came in a form not explicitly > > called out, so they had to use their own judgement on whether to > > revoke. > > > > Thanks, > > Peter > > Thanks for chiming-in Peter, > > I have always considered this revocation reason as the absolutely "last > resort" for CAs when it comes to revocation of Certificates. Especially > for the revocation of end-entity Certificates for which there is a > Subscriber Agreement attached, if the CA cannot properly justify the > revocation based on other documented reasons that Subscribers can > understand and be prepared for, it seems like a process failure and a > possible reason for Subscribers to move against the CA. Much like the > invocation of 9.16.3 should be avoided as much as possible, I believe > the same applies for relying on such very wide unbound CPS statements. > Isn't this the "different problem" that Nick was raising concerns about? That is, your reply here, talking about revocation for reasons outside of the Subscriber Agreement, sounds even further afield than Issue 205. Am I missing something on how it connects here? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise
On Sat, Nov 14, 2020 at 11:52 PM Nick Lamb wrote: > On Sat, 14 Nov 2020 17:05:26 -0500 > Ryan Sleevi wrote: > > > I don't entirely appreciate being told that I don't know what I'm > > talking about, which is how this reply comes across, but as I've > > stated several times, the _original_ language is sufficient here, > > it's the modified language that's problematic. > > That part of my statement was erroneous - of the actual texts I've seen > proposed so far I prefer this amended proposal from Ben: > > "Section 4.9.12 of a CA's CP/CPS MUST clearly specify its accepted > methods that Subscribers, Relying Parties, Application Software > Suppliers, and other third parties may use to demonstrate private key > compromise. A CA MAY allow additional, alternative methods that do not > appear in section 4.9.12 of its CP/CPS." > > I can't tell from here whether you know what you're talking about, only > whether I know what you're talking about, and I confess after some > effort I don't believe I was getting any closer. > > Still, I believe this language can be further improved to achieve the > goals of #205. How about: > > "Section 4.9.12 of a CA's CP/CPS MUST clearly specify one or more > accepted methods that Subscribers, Relying Parties, Application Software > Suppliers, and other third parties may use to demonstrate private key > compromise. A CA MAY allow additional, alternative methods that do not > appear in section 4.9.12 of its CP/CPS." > > > This makes clear that the CA must have at least one of these "clearly > specified" accepted methods which ought to actually help Matt get some > traction. > I can tell we're not making any progress here, as this doesn't really address the concerns I've highlighted twice. This would be a regression from the proposed language, and would be a further regression from the original language here. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise
On 2020-11-15 1:04 π.μ., Peter Bowen via dev-security-policy wrote: On Sat, Nov 14, 2020 at 2:05 PM Ryan Sleevi via dev-security-policy wrote: So, perhaps now that we've had this conversation, and you've learned about potentially illegitimate revocations are a thing, but that they were not the thing I was worrying about and that you'd misunderstood, perhaps we can move back to the substantive discussion? Going back to earlier posts, it seems like CAs could include a statement in their CPS separate from key compromise that they may revoke a certificate at any time for any reason or no reason at their sole discretion. That would allow the CA to choose to accept proofs of key compromise that are not listed in the CPS based on their internal risk methodologies, correct? It does still have the "secret document" issue, but moves it away from key compromise and makes it clear and transparent to subscribers and relying parties. This means the CA could revoke the subscriber certificate because they have an internal procedure that they roll a bunch of D16 and revoke any certificate with a serial number that matches the result. Or the CA could revoke the certificate because they got a claim that the key in the certificate is compromised but it came in a form not explicitly called out, so they had to use their own judgement on whether to revoke. Thanks, Peter Thanks for chiming-in Peter, I have always considered this revocation reason as the absolutely "last resort" for CAs when it comes to revocation of Certificates. Especially for the revocation of end-entity Certificates for which there is a Subscriber Agreement attached, if the CA cannot properly justify the revocation based on other documented reasons that Subscribers can understand and be prepared for, it seems like a process failure and a possible reason for Subscribers to move against the CA. Much like the invocation of 9.16.3 should be avoided as much as possible, I believe the same applies for relying on such very wide unbound CPS statements. Dimitris. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise
On 2020-11-14 5:01 π.μ., Ryan Sleevi wrote: I believe it's possible to do, with the original language, but this requires the CA to proactively take steps to address that in their CP/CPS. That is, I think it'd be reasonable for an auditor to conclude that, if a CA stated "We do X, Y, Z" in our CP/CPS, then doing "A, B, or C" without it being listed in their CP/CPS first would be an issue. I believe that is the concern you're raising, if I understood you correctly. Exactly, and the first proposed language by Ben, doesn't seem to allow the CA to include language to support "and any other method". This is not like the Domain or IP Address Validation methods where "any other method" was considered a bad thing. This is a case where we should welcome additional acceptable methods for third-parties to demonstrate their control of compromised keys. The way to address that, and what I think is a good goal, is to get it to be "We do X, Y, Z, and any other method", ideally, when CAs make the update in response to the new policy. As situations come up on a case by case basis, the CA can deal with the issue without any update required first. If any CA updates their CP/CPS without also adding "and any other method" in response to the new policy, we can then clarify whether they're intentionally stating they'll reject anything, or whether it was an oversight, and like you, they want extra flexibility because they want to go "above and beyond" as needed. However, I also want to make sure that any formally accepted method of proof is documented in the CP/CPS. So if the CA formalizes A and B as routine operations, they will update their CP/CPS to state "We do X, Y, Z, A, B, and any other method". This makes it clear which are the guaranteed methods they promise to accept, as well as that exceptions are recognized as necessary, and they will be accepted and dealt with. I think we're in agreement here, and I already stated that in a previous reply. "For CAs that want to do the right thing with this flexibility, the original language Ben proposed seems to be problematic, which is why I highlighted it in the discussion. The updated language keeps all the "good" things from the original language, and allows the CA to accept a reporting method that they may have not considered. Obviously, the logical thing is that once this new method is accepted, the CPS should be updated to include that additional method but that might take place later, after the report was accepted and certificates revoked." We could make the language even stricter so that if a CA accepts new methods to demonstrate key compromise not mentioned in their CPS, they should include the details of these new methods in an upcoming CPS update (although I consider this redundant because this is IMO the normal way of doing things). Since CAs are required to perform this update task at least once a year, this information will eventually end up in their CPS. I will reply to Peter's post separately why I think invoking that particular revocation reason is IMO not such a good idea. Dimitris. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
