Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise
On Fri, Nov 13, 2020 at 6:11 PM Dimitris Zacharopoulos wrote: > > > On 2020-11-13 7:17 μ.μ., Ryan Sleevi wrote: > > > > On Fri, Nov 13, 2020 at 2:55 AM Dimitris Zacharopoulos > wrote: > >> There is transparency that the CA has evaluated some reporting >> mechanisms and these will be documented in the CPS. However, on an issue >> like compromised key reporting, there is no single recipe that covers >> all possible and secure ways for a third-part to report a key >> compromise. > > > Sure, and the original proposed language doesn't restrict this. > > The CA can still disclose "Email us, and we'll work it out with you", and > that's still better than the status quo today, and doesn't require the > CP/CPS update you speculate about. > > > I understand the proposal to describe a different thing. Your proposal to > accept an email, is a different requirement, which is "how to communicate". > I think the policy change proposal is to describe the details about what is > expected from third-parties to submit in order to report a key compromise. > Whether via email, web form or other means, I think this policy update > covers *what* is expected to be submitted (e.g. via CSR, signed plain text, > the actual private key). > Right, and that is what I meant as well. My point was the "we'll work it out with you" being about explicitly stating an *open-ended what*, while discouraging CAs, by making it detectable during CP/CPS reviews, of intentionally choosing to *reject* any what they don't like. If a CA doesn't state an open-ended what, it could mean that their plan is to do exactly that, which would be bad, or it could just mean they forgot, which is easily fixed, but also a warning sign. > > I addressed this in my reply to Nick, but for your benefit, the "bad" > thing here is a CA that lists, in their CP/CPS, "We will only accept using > our convoluted API that requires you to submit on the lunar equinox", and > then states "Well, that's just the minimum, we have this doc over here > saying we'll also consider X, Y, Z". > > The modified language fully allows that. The original language would see > methods X, Y, Z also added to the CP/CPS. > > > I think one of us has misunderstood the policy update proposal. I believe > that what you describe is already covered by the existing policy which > states that the CA must disclose *how* they accept requests (via email, > API, web form, etc), disclosed in CPS section 1.5.2. > No, I think like above, I may have chosen an unclear example, but I think we understand it the same. "Convoluted API ... at the lunar equinox" was trying to cover both the how it's delivered and the method of proving it, but I can totally see now that it might be perceived as just the how it's delivered, which wasn't the intent. I'm talking about the "what method of demonstrating proof is accepted". That covers both the how it's delivered and how it's demonstrated, and as I went into further with Nick, my goal is to make sure "X, Y, Z" are listed in the CPS, and not some side-doc that may or may not be audited and may or may not be disclosed. The problem with the "minimum" approach is that it doesn't adequately make clear that the "listed in a side doc" is one of the several problems to be solved, with the goal being to bring it into the CP/CPS. Having just the minimum required would still encourage CAs that go above and beyond the minimum to put it off in a side doc, when the goal is to get it into the CP/CPS, for reasons I expanded on to Nick. I think you took it as discouraging a CA to go "above and beyond the bare minimum", which I agree with you, that would be bad to discourage. But I want CAs to be clear when they do go above and beyond the minimum, and to be clear that they also recognize it's important to do so, since the minimum is just that: the minimum. The minimum isn't meant to be "This is how you should operate daily", but the "You should be better than this regularly, but you absolutely cannot regress this threshold", and having CAs explicitly state that they expect to constantly be improving (by accepting other methods), helps show they understand that, as I think you're arguing for here. > This makes no sense to me. We're not discussing secrets here. Say a >> third party reports a key compromise by sending a signed plaintext >> message, and the CA has only indicated as accepting a CSR with a >> specific string in the CN field. The updated proposal would allow the CA >> to evaluate this "undocumented" (in the CPS) reporting method, check for >> its credibility/accuracy and proceed with accepting it or not. >> > > The original proposal also allows this, by saying exactly what you stated > here, but within the CP/CPS. > The modified proposal, however, keeps secret whether or not the CA has a > policy to unconditionally reject such messages. > > You seem to be thinking the original proposal prevents any discretion; it > doesn't. I'm trying to argue that such discretion should be
Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise
Right, I can see by my failing to explicitly state you were misunderstanding my position in both parts of your previous mail, you may have believed you correctly understood it, and not picked up on all of my reply. To be very clear: "secret" document is not what you described, as a way for a CA to hide nefariousness. In the context of this issue, I'm talking about "secret" as in not part of the public commitments that can be examined via the CP/CPS, and that are visibility, transparently part of the audit. These are the "internal" documents that may or may not be audited (depending on the audit scheme and the auditor's interpretation; ETSI is less transparent here, but I'm sure they'll insist it's somehow the same). Think your training manuals, your internal policies for incident management, your policies on escalation or interpretations of the BRs (such as jurisdiction requirements), etc. They are things that are conceptually and logically part of a CA, and part of how a CA operates, but they aren't part of the externally documented set. Or, they might not be explicitly linked to some audit criterion that requires examining then; for example, change control management would be, but policies around lunch and break times are unlikely to be. My point is to bring them "into the CP/CPS". As I mentioned in my previous e-mail, although I can understand you might be confused because I did not clearly state I disagreed with you, the point is to make it explicit whether or not a CA is stating that they will *reject* anything they don't like. If a CA says "I accept X, Y, Z", and you send them "A", and they say "Sorry, we said we don't accept A, you decided to trust us anyway, boo hoo for you", they're not entirely wrong. That's exactly what audits and CP/CPSes are designed to make explicit. If the CA says "We accept X, Y, Z, and any other method", then if someone sends them "A", there's a presumption here of acceptance. If the CA decides to reject it then, they bear the burden and presumption of explaining their discretion, especially if it turns out to be a valid issue. Here, the presumption is on the CA to demonstrate why their judgement and discretion is trustworthy, knowing that if they rejected A without good cause, they will be viewed negatively. Equally, we can decide whether the new policy should ACTUALLY be "We accept X, Y, Z, A, and any other method" - making it clear the new minimum set. However, while you think it redundant, it actually provides a number of important details for CP/CPS reviews. For example, were a CA to omit "any method", it easily raises a red flag to ask a follow-up. We see these sorts of omissions all the time in CP/CPS reviews, particularly around domain validation methods (3.2.2.4). So we'll ask during the review, and the CA will say, "well, we go into more detail in this other document. Our auditors looked at it, and agreed it met the requirements, but we didn't put it in our CP/CPS". Now, the problem with accepting that answer is that you don't know whether or not they actually did go into that detail in the other document - we don't have it, and would have to ask for it. You can see this playing out in Incident Reports today, where we'll ask a CA to attach the old and new document (such as a training document, an architectural layout, a testing matrix), where we try to understand what's changing. However, we also don't know whether or not the auditor looked at that document as well; the CA's version of the audit report would show this, but the one we see does not. The benefit here is that by getting it into the CP/CPS, it clearly becomes part of the audit. It also becomes part of the CA's public commitments, and then we can see if they're changing operational behavior midstream. Either they updated their CP/CPS, and we see that they did in fact go through a change, or they changed behavior and didn't update their CP/CPS, which will get flagged in the audit. Both ways, we, the community, end up learning that something changed, and can review that change to make sure that change is aligned with what we want. Yes, you're absolutely correct that I want to make sure a CA says "any method at our discretion", but it's not about humiliation, nor is it redundant. It serves a valuable purpose for reducing the risk of arbitrary, undesirable rejections, while effectively improving transparency and auditability. On Fri, Nov 13, 2020 at 8:12 PM Nick Lamb wrote: > On Fri, 13 Nov 2020 12:11:57 -0500 > Ryan Sleevi via dev-security-policy > wrote: > > > I want it to be explicit whether or not a CA is making a restrictive > > set or not. That is, it should be clear if a CA is saying "We will > > only accept these specific methods" or if the CA is saying "We will > > accept these methods, plus any method at our discretion". > > I see this as essentially redundant. Any major CA which does not choose > "We will accept ... any method at our discretion" under your formulation > stands to be
Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise
On Fri, 13 Nov 2020 12:11:57 -0500 Ryan Sleevi via dev-security-policy wrote: > I want it to be explicit whether or not a CA is making a restrictive > set or not. That is, it should be clear if a CA is saying "We will > only accept these specific methods" or if the CA is saying "We will > accept these methods, plus any method at our discretion". I see this as essentially redundant. Any major CA which does not choose "We will accept ... any method at our discretion" under your formulation stands to be humiliated repeatedly until they revise their policies to say so as I explained previously. I guess the existence of resulting let's call it "Sleevi boilerplate" is harmless, but it seems foolish for Mozilla to demand people write boilerplate that doesn't achieve anything. > I encourage you to make use of PACER/RECAP then. I examined 7 pages of RECAP results for "Key Compromise". Most of them meant this phrase in the sense of "important settlement of differences" but some were cryptography related. Here is what I found: There were verbatim copies of RFCs 2459 and 3281 submitted as evidence to a patent case that ends up involving Acer, Microsoft and others. Another case submitted as evidence the ISRG CPS. It's a Lanham Act case roughly along lines Let's Encrypt followers will be familiar with, the plaintiff wants a certificate revoked, Let's Encrypt says they just issue certificates for DNS names, have the court take the DNS name away if that's the issue. Not relevant here. And finally there's an EFF Amicus briefing which says basically key compromise is bad, which everybody here already knew. I found no evidence that there are in fact such "secret documents" and no evidence there's a problem here that would or could be fixed by your preferred language for this Mozilla policy. If you have a _much_ more specific claim than just "Somebody has mentioned it in court at some point" then please make it. Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Apple OCSP Responder Issues Yesterday (2020-11-12)
Apple has filed a bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1677234. Please follow this for further updates. ___ 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-13 7:17 μ.μ., Ryan Sleevi wrote: On Fri, Nov 13, 2020 at 2:55 AM Dimitris Zacharopoulos mailto:ji...@it.auth.gr>> wrote: There is transparency that the CA has evaluated some reporting mechanisms and these will be documented in the CPS. However, on an issue like compromised key reporting, there is no single recipe that covers all possible and secure ways for a third-part to report a key compromise. Sure, and the original proposed language doesn't restrict this. The CA can still disclose "Email us, and we'll work it out with you", and that's still better than the status quo today, and doesn't require the CP/CPS update you speculate about. I understand the proposal to describe a different thing. Your proposal to accept an email, is a different requirement, which is "how to communicate". I think the policy change proposal is to describe the details about what is expected from third-parties to submit in order to report a key compromise. Whether via email, web form or other means, I think this policy update covers *what* is expected to be submitted (e.g. via CSR, signed plain text, the actual private key). 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. As above 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. I can't think of a bad scenario with this added language. I addressed this in my reply to Nick, but for your benefit, the "bad" thing here is a CA that lists, in their CP/CPS, "We will only accept using our convoluted API that requires you to submit on the lunar equinox", and then states "Well, that's just the minimum, we have this doc over here saying we'll also consider X, Y, Z". The modified language fully allows that. The original language would see methods X, Y, Z also added to the CP/CPS. I think one of us has misunderstood the policy update proposal. I believe that what you describe is already covered by the existing policy which states that the CA must disclose *how* they accept requests (via email, API, web form, etc), disclosed in CPS section 1.5.2. This makes no sense to me. We're not discussing secrets here. Say a third party reports a key compromise by sending a signed plaintext message, and the CA has only indicated as accepting a CSR with a specific string in the CN field. The updated proposal would allow the CA to evaluate this "undocumented" (in the CPS) reporting method, check for its credibility/accuracy and proceed with accepting it or not. The original proposal also allows this, by saying exactly what you stated here, but within the CP/CPS. The modified proposal, however, keeps secret whether or not the CA has a policy to unconditionally reject such messages. You seem to be thinking the original proposal prevents any discretion; it doesn't. I'm trying to argue that such discretion should be explicitly documented, rather than kept secret by the CA, or allowing the CA to give conflicting answers to different relying parties on whether or not they'll accept such messages. If people consider that the original language is unambiguous and will prevent an auditor to interpret this as "you have stated specific technical method(s) for a third-party to demonstrate a key compromise, therefore these are the only methods you must accept otherwise you are violating your CP/CPS", then I'm fine. Dimitris. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Apple OCSP Responder Issues Yesterday (2020-11-12)
I agree, from what I have seen online is that while Apple's OCSP responser was indeed soft-fail, it didn't have any short-term timeout so requests were left lingering. Due to it being soft-fail I've seen numerous posts detailing how to block the OCSP responder address either via DNS or via the terminal (not sure if you can disable revocation checking directly within settings). So this does seem to affect the industry as a whole. ‐‐‐ Original Message ‐‐‐ On Friday, November 13th, 2020 at 21:30, Matthew Hardeman via dev-security-policy wrote: > In as far as that part of Apple's CA hierarchy is publicly trusted and > participates in the Mozilla Root CA program and that there were apparent > performance issues with ocsp.apple.com yesterday, I'm writing to suggest that > I believe there may be cause to expect some transparency regarding recent > Apple OCSP responder performance issues, whether those issues impacted > responses over covered certificates, what failures led to those issues, and > what remediations have been taken. > > I haven't seen any other mention of this and whether it rises as to the level > of an incident as yet. > > I clarify that I do not personally allege that I experienced a timeout or > long delay querying an in-scope certificate, but rather that infrastructure > that seems to be shared with publicly trusted signers had externally > detectable issues related to OCSP performance. > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy signature.asc Description: OpenPGP digital signature ___ 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 #192: Require information about auditor qualifications in the audit report
On Thu, Nov 12, 2020 at 7:27 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I am very much in favor of increasing transparency about the > qualifications of the auditors providing audit statements for CAs in our > program. However, I think that we need to spend more time figuring out a > few things before adding such a requirement to our policy. Therefore, I > think we should add this to our list of things to spend some focused > time to figure out in early 2021, and move this item to the next version > of Mozilla’s root store policy. > I think that's a reasonable place, but I do worry that there's a risk that either progress won't be made until then, and we'll be in the similar situation of needing more time. Given that this relates to audits and audit statements, does it make sense to actually go forward with trying to find a narrowly banded approach, with a forward dated requirement, such as 12 months after 2.7.1? The benefit to this approach is that it allows the expectation to be factored into contractual agreements with auditors, which may be done several years in advance, as well as provides the necessary signals to audit firms, that this is a thing of real and concrete value that Mozilla is committed to. It also allows Mozilla to assess progress, throughout the year, on the full set of requirements. If we think about other changes that have required some degree of details to be worked out (e.g. the SHA-1 deprecation, RSA-1024 deprecation, certificate lifetimes), the benefit of setting a clear expectation ahead of time helps move the conversation from debating "if" to discussing "how", which can result in more productive engagement. Equally, I think there's a lot that can be borrowed from how approaches to transparency have been done in other regards. For example, with the introduction of CAA, there was "merely" a requirement to disclose, which later turned into more concrete criteria and objectives. Similarly, with respect to organizational validations, an approach being taken right now for the EV Guidelines is to disclose, with the intent of using such disclosures to better inform, analyze, and develop concrete requirements, based on those collective disclosures and interpretations. In this regard, the principles from Mozilla's 1.0 Certificate Policy provide a small minimum, along with some of the language from, say, the FPKI, regarding technical competencies. The basis here is simply for the auditor to *disclose* why they believe they meet the criteria or objectives set. This avoids the need to address part of your questions (e.g. "How do auditors apply to be considered qualified auditors"), because it leaves the current policies and presumptions in place, but introduces the disclosure requirement for why the auditor is relevant and reliable for the report. This is why I took exception to ETSI's approach, which I worry your questions jump to as well, which is the first step to answering those questions is understanding the existing set of qualifications and how those relate to Mozilla's goals and principles, without seeking to establish a full "qualification regime" out of the gate. By focusing on disclosure, it allows us to evaluate both "is this what we expect/want", as well as better address some of the issues (e.g. "We see auditors with skill X provide much better reports than skill Y; we should consider making X a required skill") As it relates to Ben's proposal, I think the language he's proposed largely works, and we can avoid the set of questions you're worried about, by removing the language "Mozilla will review each individual auditor's credentials and ensure that any Qualified Auditor has the collective set of skills required by Section 8.2 of the Baseline Requirements". Additionally, introducing a forward-dated requirement (e.g. 12 months) helps work through any of the delivery issues Jeff highlighted, in a way that's mutually workable. This ensures transparency, without adding a hurdle here. Issues related to auditors that Mozilla may lose trust in are already covered in Section 2.3 of the policy, with https://github.com/mozilla/pkipolicy/issues/146 existing to provide greater clarity, but I think this can be seen as a contingency. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Apple OCSP Responder Issues Yesterday (2020-11-12)
In as far as that part of Apple's CA hierarchy is publicly trusted and participates in the Mozilla Root CA program and that there were apparent performance issues with ocsp.apple.com yesterday, I'm writing to suggest that I believe there may be cause to expect some transparency regarding recent Apple OCSP responder performance issues, whether those issues impacted responses over covered certificates, what failures led to those issues, and what remediations have been taken. I haven't seen any other mention of this and whether it rises as to the level of an incident as yet. I clarify that I do not personally allege that I experienced a timeout or long delay querying an in-scope certificate, but rather that infrastructure that seems to be shared with publicly trusted signers had externally detectable issues related to OCSP performance. ___ 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 Fri, Nov 13, 2020 at 2:55 AM Dimitris Zacharopoulos wrote: > There is transparency that the CA has evaluated some reporting > mechanisms and these will be documented in the CPS. However, on an issue > like compromised key reporting, there is no single recipe that covers > all possible and secure ways for a third-part to report a key > compromise. Sure, and the original proposed language doesn't restrict this. The CA can still disclose "Email us, and we'll work it out with you", and that's still better than the status quo today, and doesn't require the CP/CPS update you speculate about. > 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. As above > 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. > > I can't think of a bad scenario with this added language. > I addressed this in my reply to Nick, but for your benefit, the "bad" thing here is a CA that lists, in their CP/CPS, "We will only accept using our convoluted API that requires you to submit on the lunar equinox", and then states "Well, that's just the minimum, we have this doc over here saying we'll also consider X, Y, Z". The modified language fully allows that. The original language would see methods X, Y, Z also added to the CP/CPS. > This makes no sense to me. We're not discussing secrets here. Say a > third party reports a key compromise by sending a signed plaintext > message, and the CA has only indicated as accepting a CSR with a > specific string in the CN field. The updated proposal would allow the CA > to evaluate this "undocumented" (in the CPS) reporting method, check for > its credibility/accuracy and proceed with accepting it or not. > The original proposal also allows this, by saying exactly what you stated here, but within the CP/CPS. The modified proposal, however, keeps secret whether or not the CA has a policy to unconditionally reject such messages. You seem to be thinking the original proposal prevents any discretion; it doesn't. I'm trying to argue that such discretion should be explicitly documented, rather than kept secret by the CA, or allowing the CA to give conflicting answers to different relying parties on whether or not they'll accept such messages. ___ 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 Thu, Nov 12, 2020 at 10:51 PM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, 12 Nov 2020 15:51:55 -0500 > Ryan Sleevi via dev-security-policy > wrote: > > > I would say the first goal is transparency, and I think that both > > proposals try to accomplish that baseline level of providing some > > transparency. Where I think it's different is that the concern > > Dimitris raised about "minimums", and the proposed language here, is > > that it discourages transparency. "We accept X or Y", and a secret > > document suggesting "We also accept Z", makes it difficult to > > evaluate a CA on principle. > > [...] > > > Yes, this does mean they would need to update their CP/CPS as they > > introduce new methods, but this seems a net-positive for everyone. > > I think the concern about defining these other than as minimums is > scenarios in which it's clear to us that key compromise has taken place > but your preferred policy forbids a CA from acting on that knowledge on > the grounds that doing so isn't "transparent" enough for your liking > because their policy documents did not spell out the method which > happened to be used. > I'm afraid this misunderstands things. I want it to be explicit whether or not a CA is making a restrictive set or not. That is, it should be clear if a CA is saying "We will only accept these specific methods" or if the CA is saying "We will accept these methods, plus any method at our discretion". It's very easy for a CA to be transparent about the latter, and is no different than the so-called "any other method" that was 3.2.2.4.10 in the BRs. The problem with the updated language from Ben is that it makes it indistinguishable whether or not the CP/CPS disclosed method is a complete set (i.e. that the CA will reject a reported compromise because it fails to meet their preferred method) or not. The fact that there can be "secret" documents which could say "We'll accept anything at our discretion" or that it could be empty is a problem. You seem to be taking it as if the CA has to provide exhaustive technical details for each method. That's not the case. They need to disclose the minimum (which might be "we accept anything at our discretion if e-mailed to us"), but with the original language, they would functionally need to disclose whether or not they will *reject* something not on that list, and the proposed revision removes that. > > You seem to anticipate a quite different environment in which "secret > documents" are used to justify revocations which you presumably see as > potentially illegitimate. I haven't seen any evidence of anything like > that happening, or of anybody seeking to make it happen - which surely > makes a Mozilla policy change to try to prevent it premature. I encourage you to make use of PACER/RECAP then. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
