Re: Proposal: prohibit issuance of new certificates with known-compromised keys, and for related purposes
On Mon, Apr 06, 2020 at 12:56:02PM -0400, Ryan Sleevi wrote: > On Mon, Mar 30, 2020 at 5:32 PM Matt Palmer via dev-security-policy > wrote: > > Righto, the goals are: > > > > * Make it a policy violation for CAs to issue a certificate using a public > > key they've revoked before. > > > > * Clarify the language around key compromise revocation to make it obvious > > that CAs have to revoke everything with a given private key. > > > > * Clarify the language around revocation time limits to make it obvious that > > the time period starts when the communication leaves the reporter. > > I've attempted the first two points with > https://github.com/sleevi/cabforum-docs/pull/12 . You can seem some of > the discussion at > https://github.com/sleevi/cabforum-docs/pull/12/files#r401919547 and > https://github.com/sleevi/cabforum-docs/pull/12/files#diff-7f6d14a20e7f3beb696b45e1bf8196f2R1425 Thanks, I've made a comment on part of that change. > > I, personally, do not have a problem with mandating that CAs keep records of > > compromised keys in perpetuity. > > I've not yet addressed this part in the above PR, because I think > there's still work to sort out the objectives and goals. We've seen > some CAs express concerns (not unreasonably) at the potential of an > unbounded growth of key sizes creating a disproportionate load on CAs. > I think more napkin math is needed here in terms of load and lookups. Well, I can say that indexing 1.3M private keys, at least, isn't a particular challenge, even comparing that against the entire corpus of known certificates. I don't know how many private keys CAs' customers are planning on dumping onto the public Internet, though... > It's not as easy as saying "use a bloom filter" if a bloom filter > takes X amount of time to generate. A bloom filter could potentially be a *part* of an approach, but it certainly can't be the entire solution (for a great many reasons). As an aside, if anyone wants to try out a bloom filter, I've generated one containing all the Debian weak keys I've generated so far: https://assets.pwnedkeys.com/public/debian-weak-keys.pkf (file format documented at https://pwnedkeys.com/filter.html). > > > While I appreciate the suggestion, I'm worried this does more to sow > > > confusion rather than bring clarity. As you note, 4.9.1.1 is liked to > > > evidence about the Private Key, not the Certificate, so this is > > > already a "clear" requirement. > > > > What about it sows (additional) confusion? > > Every time we've seen an existing requirement stated in two places, > CAs have tried to argue they're disjoint requirements OR they become > disjoint requirements through a lack of consistent updating. If a CA > can't read 4.9.1.1 and reach the conclusion, I've got worries, but if > a CA has reached that, they should be offering suggestions here as to > why. Yes, well, I suppose we should ask the CAs that have come to that conclusion as to how they managed that. I'm not hopeful, however; whenever I've asked questions about how a CA came to a particular conclusion, the best I've gotten back is "lol we dunno". The most common response is radio silence. > Unfortunately, I think that's where we might disagree. More words > often creates more opportunity here for getting creative, so I want to > figure out how to tighten up or entirely reframe requirements, rather > than merely state them multiple times in slightly-different ways that > might be seen as offering slightly different requirements. In short, > I'd like to avoid the CA-equivalent of the Genesis creation narrative > debate :) I see your point. > > > > Step 3: Insert a new paragraph at the end of section 4.9.1.1, with the > > > > following contents (or a reasonable facsimile thereof): > > > > > > This isn't where the suggested requirements go. That's covered in 4.9.5 > > > > I'm not sure what you mean by this. Could you expand a little? > > Yeah, 4.9.5 is the "Time within which CA must process the revocation > request" - that's where requirements for timeliness go. Hmm, I think the cat's nose is poking out of the bag on that one, because of all the mentions of timeframes for different sorts of revocation already in 4.9.1.1. I don't have a problem with a clarification of exactly what "receipt" means into 4.9.5, though, if it works better there. The important thing is that there *is* a clear definition of such things, because there are CAs who aren't clear on what that means. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Terms and Conditions that use technical measures to make it difficult to change CAs
On Mon, Mar 16, 2020 at 5:06 PM Tim Hollebeek via dev-security-policy wrote: > > > > Hello, > > > > I'd like to start a discussion about some practices among other commercial > CAs that have recently come to my attention, which I personally find > disturbing. While it's perfectly appropriate to have Terms and Conditions > associated with digital certificates, in some circumstances, those Terms and > Conditions seem explicitly designed to prevent or hinder customers who wish > to switch to a different certificate authority. Some of the most disturbing > practices include the revocation of existing certificates if a customer does > not renew an agreement, which can really hinder a smooth transition to a new > provider of digital certificates, especially since the customer may not have > anticipated the potential impact of such a clause when they first signed the > agreement. I'm particularly concerned about this behavior because it seems > to be an abuse of the revocation system, and imposes costs on everyone who > is trying to generate accurate and efficient lists of revoked certificates > (e.g. Firefox). > > > > I'm wondering what the Mozilla community thinks about such practices. Thanks for raising this issue! At the core, it seems like the concern being raised is about policies that might limit certificate or ecosystem agility. From discussions around certificate lifetimes, and from CA distrust, we know that agility is one of the most important things to keeping users secure, so it's understandable to be concerned if agility is jeopardized. Such policies have material impact on end-users. As the number of revoked certificates grow, this requires larger CRLs (for systems that use CRLs), or larger databases/updates for browser-provided systems, like Mozilla's CRLLite or Apple's valid. For end-users, because revocation is treated equally, it runs the risk that potential contract or payment disputes become highly visible as revocations, rather than revocations reflecting signals of the site or the CA's trustworthiness. Overall, that seems harmful to users' security and the ecosystem. These policies only seem to matter because of revocation. If user agents did not check revocation, then CAs revoking these certificates would be a non-issue, because there would be no disruption. However, because some user agents check revocation, they end up giving the CA even more control over the end-user experience, and this allows CAs to cause disruptions that the user agents and end-users are harmed by, rather than benefit from. Perhaps it makes sense to take the approach of the Baseline Requirements and Root Store Policies. The BRs disclose a number of situations where the CA MUST NOT issue a certificate, such as not having validated a domain correctly, as well as define a limited subset of what a CA MAY issue, such as particular optional extensions or name fields. Anything not in those lists are also expected as MUST NOT. It may make sense to take the same approach with revocation, such as by describing a set of policies where a CA MUST revoke a certificate (as is done in 4.9.1.1), a set of scenarios where a CA MAY revoke a certificate, and any reason not on those lists are a MUST NOT. One of the challenges with this is that the BRs require the CA MUST revoke if a Subscriber violates their Subscriber Agreement / Terms of Use. It sounds like CAs are bundling such terms of sale into those Agreements / Terms of Use, so an approach like I just described would not be sufficient. It would be indistinguishable to users / relying parties as a Subscriber who posted their private key publicly (also a violation of the Agreement). In order to deal with this, it's probably necessary to go further: to describe the CRL/OCSP reason codes that MUST or MAY be used, and revocations that don't fall into those enumerated lists MUST NOT use those reason codes. This would allow user agents/relying parties to be more selective when they honor CA-indicated revocation data. For example, if it was possible for user agents to distinguish when the Subscriber violated one of the BR-defined portions of the Subscriber Agreement, versus the CA-defined portion of the Subscriber Agreement, they might choose to only respect the BR-defined reasons. This would also provide tools to limit how much data needs to be sent to all of a browser’s users, when using browser-distributed revocation mechanisms, by allowing the browser to focus on the revocations it’s most concerned about. These ideas are far from perfect, but try to address the challenge the same way that many of the PKI problems have been tackled: trying to bring transparency into CAs’ practices, and through that, greater security and accountability. These ideas are intentionally simple, and avoid unnecessarily complex schemes like revocation transparency. Such systems would only be needed if we expect CAs to be intentionally misleading in revocations, and if that was the case, that seems mu
Re: Proposal: prohibit issuance of new certificates with known-compromised keys, and for related purposes
On Mon, Mar 30, 2020 at 5:32 PM Matt Palmer via dev-security-policy wrote: > Righto, the goals are: > > * Make it a policy violation for CAs to issue a certificate using a public > key they've revoked before. > > * Clarify the language around key compromise revocation to make it obvious > that CAs have to revoke everything with a given private key. > > * Clarify the language around revocation time limits to make it obvious that > the time period starts when the communication leaves the reporter. I've attempted the first two points with https://github.com/sleevi/cabforum-docs/pull/12 . You can seem some of the discussion at https://github.com/sleevi/cabforum-docs/pull/12/files#r401919547 and https://github.com/sleevi/cabforum-docs/pull/12/files#diff-7f6d14a20e7f3beb696b45e1bf8196f2R1425 > I, personally, do not have a problem with mandating that CAs keep records of > compromised keys in perpetuity. I've not yet addressed this part in the above PR, because I think there's still work to sort out the objectives and goals. We've seen some CAs express concerns (not unreasonably) at the potential of an unbounded growth of key sizes creating a disproportionate load on CAs. I think more napkin math is needed here in terms of load and lookups. It's not as easy as saying "use a bloom filter" if a bloom filter takes X amount of time to generate. I'd love to see more thoughts in this space before trying to nail down the precise language here, although I do agree with the spirit here of being something that 'seems' like it should be indefinitely maintainable. That said, there are obvious edge cases to think through, such as: - If CA Foo purchases CA Bar, what happens with Foo's database of compromised keys? - Scenarios: Foo ends up using Bar's database (Foo is transitioned to Bar's infrastructure), Bar ends up using Foo's database (Bar is 'reverse-transitioned' onto Foo's infrastructure), the database becomes Foo+Bar, etc - What happens if Foo's the crappy CA and their database doesn't record enough info for Bar to be able to reliably/safely implement? > > While I appreciate the suggestion, I'm worried this does more to sow > > confusion rather than bring clarity. As you note, 4.9.1.1 is liked to > > evidence about the Private Key, not the Certificate, so this is > > already a "clear" requirement. > > What about it sows (additional) confusion? Every time we've seen an existing requirement stated in two places, CAs have tried to argue they're disjoint requirements OR they become disjoint requirements through a lack of consistent updating. If a CA can't read 4.9.1.1 and reach the conclusion, I've got worries, but if a CA has reached that, they should be offering suggestions here as to why. > > I think we'd want to understand why/how CAs are misinterpreting this. > > I think we've seen a common thread, which is CAs thinking about > > systems in terms of Certificates, rather than thinking about Keys and > > Issuers. We've seen that problem systemically come up in other areas, > > such as OCSP, Precertificates, and SHA-1. > > > > Does that seem to track with the root cause of the problem? That is, > > that this is an existing requirement, but CAs aren't recognizing it as > > such? > > Yes, I certainly believe that you and I are in agreement that this is an > existing requirement. However, CA interpretations appear to diverge from > ours, and the easiest way to re-align CA interpretations would seem to be to > add more words to the BRs. Unfortunately, I think that's where we might disagree. More words often creates more opportunity here for getting creative, so I want to figure out how to tighten up or entirely reframe requirements, rather than merely state them multiple times in slightly-different ways that might be seen as offering slightly different requirements. In short, I'd like to avoid the CA-equivalent of the Genesis creation narrative debate :) > > > > Step 3: Insert a new paragraph at the end of section 4.9.1.1, with the > > > following contents (or a reasonable facsimile thereof): > > > > This isn't where the suggested requirements go. That's covered in 4.9.5 > > I'm not sure what you mean by this. Could you expand a little? Yeah, 4.9.5 is the "Time within which CA must process the revocation request" - that's where requirements for timeliness go. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
