Re: Sectigo: Failure to revoke certificate with previously-compromised key within 24 hours
I've created a bug to track this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1625715 - Wayne On Thu, Mar 26, 2020 at 11:33 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > At 2020-03-20 03:02:43 UTC, I sent a notification to sslab...@sectigo.com > that certificate https://crt.sh/?id=1659219230 was using a private key > with > SPKI fingerprint > 4c67cc2eb491585488bab29a89899e4e997648c7047c59e99a67c6123434f1eb, which was > compromised due to being publicly disclosed. My e-mail included a link to > a > PKCS#10 attestation of compromise, signed by the key at issue. An MX > server > for sectigo.com accepted this e-mail at 2020-03-20 03:02:50 UTC. > > This certificate was revoked by Sectigo, with a revocation timestamp of > 2020-03-20 19:37:48 UTC. > > Subsequently, certificate https://crt.sh/?id=2614798141 was issued by > Sectigo, and uses a private key with the same SPKI as that previously > reported. This certificate has a notBefore of Mar 23 00:00:00 2020 GMT, > and > embeds two SCTs issued at 2020-03-23 05:55:53 UTC. At the time of writing, > the crt.sh revocation table does not show this certificate as revoked > either > via CRL or OCSP: > > Mechanism ProviderStatus Revocation Date Last > Observed in CRLLast Checked (Error) > OCSPThe CA Goodn/a n/a > 2020-03-27 06:27:23 UTC > CRL The CA Not Revoked n/a n/a > 2020-03-27 04:44:26 UTC > > Based on previous discussions on m.d.s.p, I believe Sectigo's failure to > revoke this certificate within 24 hours of its issuance is a violation of > the BRs, and hence Mozilla policy. > > - Matt > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation as an independent user agent decision
On Sat, Mar 28, 2020 at 6:39 PM Ian Carroll via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan, > > I don't see a reason why any obligation in 9.6.3 is not fulfillable by > changing the obligation from a subscriber's notification to revoke to the > CA, to an obligation for the subscriber to notify appropriate user-agents > for revocation. It is intentional (and rather the entire point) that this > proposal does not allow the CA to act unilaterally for the subscriber. I see. - Who do you see the user agents that hundreds of millions of subscribers should notify? - What do you do for a new user agent entering the market? - How should a user agent respond if some user agents are notified, and they aren’t? - How does the user agent know that the Subscriber is authorized? - What legal remedies exist if the Subscriber fails to do so? I can understand and appreciate your desire to remove the CA from the equation. If issuance was not tied to CAs performing validation, this would make sense. However, attempting to decouple issuance from revocation is well known to create a large host of problems. It doesn’t seem the proposal is fleshed out to think about those second order effects, let alone the first order effects. Do you plan on writing it up more? Have you spent much time analyzing where it might fall apart? There are, admittedly, potential problems to this sort of revocation method > at scale, as it would be unfortunate to require an enterprise to put all of > their private keys into a single database, rather than just directing the > CA to perform the revocation based on their prior trust relationship. > However, one could imagine many reasonable solutions to this, i.e. > embedding a "revocation key" in certificates, or proving domain ownership > as an alternative proof method. And what happens if you lose the revocation key? This idea bears remarkable semblance (and weaknesses) to other key-based naming schemes, which is that loss of private key (not loss of control; loss) is incredibly common. Proof of domain ownership was addressed extensively during CT redaction discussions, as previously mentioned. Among other things, it seems like it makes it incredibly easy to exercise a DDOS at scale, by causing revocation of a Subscriber’s certificates, rather than misissuance. Is the assumption that this idea only works when all certificates are automated and all issuance is instantaneous (rather than distributed out of band, even when automated)? Can you expand on why you believe this sort of technical-oriented proposal > might introduce more risks? If anything, I would say we would significantly > reduce risk by consolidating part of a fragmented ecosystem into the > clients the user trusts for their browsing. I can totally understand and appreciate the appeal. It seems like it might benefit from doing some basic threat modeling of your modest proposal, and continuing to work until you’ve fleshed it out into something more cohesive and comprehensive. Hopefully, the above questions help highlight some of the challenges and limitations. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation as an independent user agent decision
On Thursday, March 26, 2020 at 2:23:11 PM UTC-7, Ryan Sleevi wrote: > On Thu, Mar 26, 2020 at 4:45 PM Ian Carroll via dev-security-policy > wrote: > > > > Hi all, > > > > A recent thread on CAs using contractual terms to revoke certificates has > > made me want to bring up a topic that I am surprised does not come up more: > > removing the control of revocation from CAs and moving it to the user > > agent. While this is an idea that requires the backing of a user agent (for > > which I have none), I think it's worthwhile to float as a future prospect. > > You only focused on keyCompromise. Was that intentional? > > If it was, it seems like it might be missing the other scenarios > captured in the Baseline Requirements. CAs are required to have > legally enforceable Subscriber Agreements / Terms of Use with their > Subscribers (certificate holders), as a condition to issuing a > certificate. This is covered in 9.6.3 of the Baseline Requirements. > > That places certain obligations upon the Subscriber (certificate > holder). That's a risk tradeoff, and relies on the legal system rather > than a technical system, to enforce certain expectations. If it was > intentional to omit that, it's unclear if you're proposing to > deprecate it or replace it with some other mechanism, such as the CA > requiring that the Subscriber execute legally enforcable agreements > with all possible Relying Parties beforehand. If it was unintentional, > working through the design more is worthwhile. > > Some of this was already plumbed in the past, related to Certificate > Transparency and name redaction, in the context of "hostile redaction" > and "hostile unredaction". In effect, transitions of that mechanism to > purely technical come with it new risks for hijinks and shenanigans. Hi Ryan, I don't see a reason why any obligation in 9.6.3 is not fulfillable by changing the obligation from a subscriber's notification to revoke to the CA, to an obligation for the subscriber to notify appropriate user-agents for revocation. It is intentional (and rather the entire point) that this proposal does not allow the CA to act unilaterally for the subscriber. I also don't see a reason why my proposal is limited to key compromise; while I did indeed focus on it for much of the post, all CRL revocation reasons can be encompassed by using either (a) the proof of possession of a key or (b) a CA issuing an incident report to user agents to trigger the revocation manually. There are, admittedly, potential problems to this sort of revocation method at scale, as it would be unfortunate to require an enterprise to put all of their private keys into a single database, rather than just directing the CA to perform the revocation based on their prior trust relationship. However, one could imagine many reasonable solutions to this, i.e. embedding a "revocation key" in certificates, or proving domain ownership as an alternative proof method. Can you expand on why you believe this sort of technical-oriented proposal might introduce more risks? If anything, I would say we would significantly reduce risk by consolidating part of a fragmented ecosystem into the clients the user trusts for their browsing. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Musings on mass key-compromise revocations
Thank you Matt. I really appreciate the detailed summary and look forward to your specific improvement proposals. - Wayne On Sat, Mar 28, 2020 at 1:12 AM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I've been asked to provide some "big-picture" thoughts on how the process > for key compromise revocations works, doesn't work, and could be improved. > This is based on the work that I've done over the past month or so, > requesting revocation of certificates which have had their private keys > disclosed by being posted to some public location. > > This e-mail is intended to provide a summary of what I did and how it all > went, with a summary of the things that I came across which I feel could > stand to be improved. Most of these improvements will likely come through > changes to the Mozilla or CCADB policies, or via changes to the BRs. A > couple are things that CAs themselves need to take on board, as they aren't > "policy" matters as such, but are still issues of concern. > > As the exact nature of how a problem may be solved will, no doubt, engender > no small amount of debate, I intend (unless someone tells me I'm once again > being a goose), to provide separate e-mail thread-starters on the details > of the issues I found, along with my proposals for how the issues might be > solved. I will be providing a summary of the issues I found, but all the > gory minutiae will be provided in later e-mail threads. > > One final thing before I get started: I'd like to give a big shout-out to > Rob Stradling and anyone else who is involved in making crt.sh happen, and > Sectigo for sponsoring its existence. Everything I've done here would have > been a zillion times harder if there wasn't already a database of every > CT-logged certificate available for me to hammer on. It is an Internet > Treasure. > > So to kick things off, let's have some stats. > > In the past month, I've requested revocation of over 2,800 certificates and > pre-certs[1], across 11 different "CA organisations" (I'm counting one "CA > organisation" as any number of issuing CAs that share a common problem > reporting address). These certificates were using a total of 1,217 > distinct > private keys. These keys come from multiple sources, but based on an > analysis of a sample of around 3% of those keys, the overwhelming majority > come from GitHub repositories which were at one time -- and in many cases > still are -- publicly available. > > As a bit of an aside, at the time of writing, there are a further 52 SPKIs, > representing an unknown number of certificates, for which I have yet to > request revocation from the relevant CAs. These are keys which have > entered > the pwnedkeys database since around the 23rd March. In addition, since the > 23rd, I've automatically requested revocation of 17 certificates (from 16 > SPKIs) through Let's Encrypt's automated ACME-based revocation API (and > also > deactivated about eight Let's Encrypt accounts whose private keys were > posted > publicly...) > > An interesting thing to do is to compare "issuance volume" against > "disclosed keys". This isn't a reflection of the CAs themselves, because a > CA can't control what their customers do with their keys. Given the > differences in issuance methodologies, target markets, and business > practices between CAs, it's worth taking a look at different CAs' > "disclosure rate", I guess you'd call it, and consider what impact, if any, > tho differences between CAs' operations might have on the likelihood of > their customers disclosing their keys. > > I've taken issuance volume as being the total number of unexpired > certificates (as of a few days ago) issued by a "CA organisation" (again, > all the issuing CAs that share a common problem reporting address). > Pre-certs get in the way, unfortunately, but it's not trivial to say "only > count a pre-cert if there isn't a corresponding cert" in crt.sh, so we have > what we have. > > Of the 11 CA orgs that I sent at least one revocation request to, here are > their numbers: > > CA org SPKIs Issued Issued / SPKI > > Digicert832 3402992040901 > QuoVadis23 73184 3181 > GlobalSign 47 1650873 35124 > DFN-Verein 3 52945 17648 > GoDaddy 38 4264928 112234 > Sectigo 128 41718165325923 > Entrust 6 576093 96015 > SECOM 1 118748 118748 > Certum 5 329047 65809 > Let's Encrypt 133 122438321 920588 > > I took the opportunity, also, to look at a couple of larger CAs (by > issuance > volume) which have had zero certificates with keys I found: pki.goog > (issued > 1284676), and Amazon (issued 2308004). Clearly, the best approach to > avoiding key disclosure is never giv
Musings on mass key-compromise revocations
I've been asked to provide some "big-picture" thoughts on how the process for key compromise revocations works, doesn't work, and could be improved. This is based on the work that I've done over the past month or so, requesting revocation of certificates which have had their private keys disclosed by being posted to some public location. This e-mail is intended to provide a summary of what I did and how it all went, with a summary of the things that I came across which I feel could stand to be improved. Most of these improvements will likely come through changes to the Mozilla or CCADB policies, or via changes to the BRs. A couple are things that CAs themselves need to take on board, as they aren't "policy" matters as such, but are still issues of concern. As the exact nature of how a problem may be solved will, no doubt, engender no small amount of debate, I intend (unless someone tells me I'm once again being a goose), to provide separate e-mail thread-starters on the details of the issues I found, along with my proposals for how the issues might be solved. I will be providing a summary of the issues I found, but all the gory minutiae will be provided in later e-mail threads. One final thing before I get started: I'd like to give a big shout-out to Rob Stradling and anyone else who is involved in making crt.sh happen, and Sectigo for sponsoring its existence. Everything I've done here would have been a zillion times harder if there wasn't already a database of every CT-logged certificate available for me to hammer on. It is an Internet Treasure. So to kick things off, let's have some stats. In the past month, I've requested revocation of over 2,800 certificates and pre-certs[1], across 11 different "CA organisations" (I'm counting one "CA organisation" as any number of issuing CAs that share a common problem reporting address). These certificates were using a total of 1,217 distinct private keys. These keys come from multiple sources, but based on an analysis of a sample of around 3% of those keys, the overwhelming majority come from GitHub repositories which were at one time -- and in many cases still are -- publicly available. As a bit of an aside, at the time of writing, there are a further 52 SPKIs, representing an unknown number of certificates, for which I have yet to request revocation from the relevant CAs. These are keys which have entered the pwnedkeys database since around the 23rd March. In addition, since the 23rd, I've automatically requested revocation of 17 certificates (from 16 SPKIs) through Let's Encrypt's automated ACME-based revocation API (and also deactivated about eight Let's Encrypt accounts whose private keys were posted publicly...) An interesting thing to do is to compare "issuance volume" against "disclosed keys". This isn't a reflection of the CAs themselves, because a CA can't control what their customers do with their keys. Given the differences in issuance methodologies, target markets, and business practices between CAs, it's worth taking a look at different CAs' "disclosure rate", I guess you'd call it, and consider what impact, if any, tho differences between CAs' operations might have on the likelihood of their customers disclosing their keys. I've taken issuance volume as being the total number of unexpired certificates (as of a few days ago) issued by a "CA organisation" (again, all the issuing CAs that share a common problem reporting address). Pre-certs get in the way, unfortunately, but it's not trivial to say "only count a pre-cert if there isn't a corresponding cert" in crt.sh, so we have what we have. Of the 11 CA orgs that I sent at least one revocation request to, here are their numbers: CA org SPKIs Issued Issued / SPKI Digicert832 3402992040901 QuoVadis23 73184 3181 GlobalSign 47 1650873 35124 DFN-Verein 3 52945 17648 GoDaddy 38 4264928 112234 Sectigo 128 41718165325923 Entrust 6 576093 96015 SECOM 1 118748 118748 Certum 5 329047 65809 Let's Encrypt 133 122438321 920588 I took the opportunity, also, to look at a couple of larger CAs (by issuance volume) which have had zero certificates with keys I found: pki.goog (issued 1284676), and Amazon (issued 2308004). Clearly, the best approach to avoiding key disclosure is never giving the subscriber the key in the first place... Finally, I thought it worth checking as to how many certificates were issued after the private key was already known to have been compromised by being included in the pwnedkeys database. Based on the apparently common behaviour of "request cert, then stick cert+key into a public GitHub repo", I didn't think there would be many of these. Turns out I wa
