Re: Acceptable forms of evidence for key compromise
On Tue, Mar 17, 2020 at 03:51:13PM +, Tim Hollebeek wrote: > For what it's worth, while we generally try to accept any reasonable proof > of key compromise, we have seen quite a large variety of things sent to > us. This includes people actually sending us private keys in various > forms, which is completely unnecessary and something we'd like to avoid. You probably want to tell the people handling rev...@digicert.com to stop asking for them, then. I stopped counting after the first four instances I found in my archive of revocation-related communications of Digicert representatives asking for a copy of the private key. > When we are unable to verify a proof, we provide explicit instructions on > how to create a proof in a standardized form that's easy to very. I > believe it currently involves signing something with openssl, so it should > be easy to carry out for anyone who is involved in these sorts of > discussions and has access to the private key. There's "access", and then there's "immediate and easy access". I very deliberately don't keep the 1.3M keys I've collected just lying around to be poked at with openssl at a moment's notice. Dragging a key out of cold storage is deliberately not an easy operation. (Incidentally, that also makes ACME's revocation-by-private-key operation difficult when a cert is issued using a previously compromised key, but that's a separate discussion I need to have with the ACME WG). > I also think it's potentially useful to discuss standardizing lists of > known compromised keys, and how to check them before issuance. The > problem of revoking them could be avoided entirely if they were never > issued in the first place. I don't have conclusive data (yet), but the impression I'm getting so far is that most keys are, in fact, compromised after the certificate has been issued, because people put the key+cert into a public GitHub repo or other public online location (like pastebin), for use in their app. I'm yet to find the time to do an analysis of "certificates whose notBefore is later than when they were discovered by the keyfinder". Once that happens, I'll be able to give a better indication of how much value there is in strict pre-issuance checks for key compromise. - 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
This is an abusive practice that tends to injure the operation of the internet, particularly by encouraging victims to operate sites without authentication and encryption in the interregnum between revocation and the acquisition of a new cert. It also needlessly raises the cost to operate a site, and possibly violates antitrust and/or restraint-of-trade laws [1]. Mozilla should consider advocating the creation of an "abusive practices that could lead to distrust" section in the BRs, which should enumerate this practice. -R [1] Consult your lawyer for legal advice. On 3/16/2020 2: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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: About upcoming limits on trusted certificates
Yeah - I've wanted to do this for a long time. If the domain is only good for 30 days, why would we issue even a 1-year cert? If it's good for 13 months, why not tie the cert validity to that? I guess because they could have transferred the domain (which just means you need additional caps)? It's odd not to have the domain registration as the maximum cap on the range since that's when you know the domain is most at risk for transfer. Jeremy -Original Message- From: dev-security-policy On Behalf Of Tim Hollebeek via dev-security-policy Sent: Tuesday, March 17, 2020 10:00 AM To: Kathleen Wilson ; Mozilla Subject: RE: About upcoming limits on trusted certificates > On 3/11/20 3:51 PM, Paul Walsh wrote: > > Can you provide some insight to why you think a shorter frequency in > domain validation would be beneficial? > > To start with, it is common for a domain name to be purchased for one year. > A certificate owner that was able to prove ownership/control of the > domain name last year might not have renewed the domain name. So why > should they be able to get a renewal cert without having that re-checked? This has been a favorite point of Jeremy's for as long as I've been participating in the CA/Browser Forum and on this list. Tying certificate lifetimes more closely to the lifetime and validity of the domains they are protecting would actually make a lot of sense, and we'd support any efforts to do so. -Tim ___ 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
Yes - please share the details with me as I am very surprised to hear that. I know the DigiCert agreements I've seen don't permit revocation because of termination so whoever (if anyone) is saying that is contradicting the actual agreement. Threatening revocation because of termination or revoking upon termination also violates our internal policies - certs issued are good for the duration of the cert, even if the console agreement terminates. Since I'm sure we haven't actually revoked because of termination, please send me the details of the threats and I'll take care of them. -Original Message- From: dev-security-policy On Behalf Of Nick France via dev-security-policy Sent: Tuesday, March 17, 2020 11:27 AM To: Mozilla Subject: Re: Terms and Conditions that use technical measures to make it difficult to change CAs On Monday, March 16, 2020 at 9:06:33 PM UTC, Tim Hollebeek 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. > > > > -Tim Tim, Completely agree on your statement that it's a disturbing practice. We've sadly come across it several times in the past 12-18 months, leading to problems for the customer and of course lost business for us as they inevitably decide to remain with the incumbent CA when faced with a hard deadline for certificate revocation - regardless of the natural expiry dates. Your points about the impact and costs to the wider ecosystem ring true, as well. Revocation should not be used to punish those wishing to migrate CAs. We certainly don't do it. More troubling is that each time it's either been mentioned early in discussions or has caused a business discussion to cease at a late stage - it's been DigiCert that was the current CA and they/you participated in this practice of threatening revocation of certificates well before expiry due to contract termination. I have at least 5 major global enterprises that this has happened to recently. Am happy to share more details privately if you wish to discuss. Nick ___ 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: Audit Reminder Email Summary
Forwarded Message Subject: Summary of March 2020 Audit Reminder Emails Date: Tue, 17 Mar 2020 19:00:22 + (GMT) Mozilla: Audit Reminder CA Owner: Government of The Netherlands, PKIoverheid (Logius) Root Certificates: Staat der Nederlanden EV Root CA Staat der Nederlanden Root CA - G3 Staat der Nederlanden Root CA - G2 Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=224596 Standard Audit Period End Date: 2018-12-31 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=224597 BR Audit Period End Date: 2018-12-31 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9119053 BR Audit Period End Date: 2018-12-31 EV Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=224598 EV Audit Period End Date: 2018-12-31 CA Comments: null Mozilla: Audit Reminder CA Owner: Krajowa Izba Rozliczeniowa S.A. (KIR) Root Certificates: SZAFIR ROOT CA2 Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=226440 Standard Audit Period End Date: 2018-12-18 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=226441 BR Audit Period End Date: 2018-12-18 CA Comments: null Mozilla: Audit Reminder CA Owner: certSIGN Root Certificates: certSIGN ROOT CA Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229553 Standard Audit Period End Date: 2019-02-08 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=229551 BR Audit Period End Date: 2019-02-08 CA Comments: null Mozilla: Audit Reminder CA Owner: QuoVadis Root Certificates: QuoVadis Root CA 1 G3 QuoVadis Root CA 2 QuoVadis Root CA 2 G3 QuoVadis Root CA 3 QuoVadis Root CA 3 G3 QuoVadis Root Certification Authority Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=227627 Standard Audit Period End Date: 2018-12-31 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=227628 BR Audit Period End Date: 2018-12-31 EV Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=227629 EV Audit Period End Date: 2018-12-31 CA Comments: null Mozilla: Audit Reminder CA Owner: Taiwan-CA Inc. (TWCA) Root Certificates: TWCA Global Root CA** TWCA Root Certification Authority** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=225350 Standard Audit Period End Date: 2018-12-31 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=225502 BR Audit Period End Date: 2018-12-31 EV Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=225503 EV Audit Period End Date: 2018-12-31 CA Comments: null Mozilla: Audit Reminder CA Owner: Trustis Root Certificates: Trustis Limited - Trustis FPS Root CA** ** Audit Case in the Common CA Database is under review for this root certificate. Standard Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=9047305 Standard Audit Period End Date: 2019-01-15 BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=9047305 BR Audit Period End Date: 2019-01-15 CA Comments: null Mozilla: Audit Reminder CA Owner: Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) Root Certificates: FNMT-RCM - SHA256 Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9057798 Standard Audit Period End Date: 2019-01-12 BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=9057798 BR Audit Period End Date: 2019-01-12 CA Comments: null Mozilla: Audit Reminder CA Owner: Amazon Trust Services Root Certificates: Amazon Root CA 3 Amazon Root CA 2 Starfield Services Root Certificate Authority - G2 Amazon Root CA 1 Amazon Root CA 4 Standard Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=227776 Standard Audit Period End Date: 2019-01-15 BR Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=22 BR Audit Period End Date: 2019-01-15 EV Audit: https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=227778 EV Audit Period End Date: 2019-01-15 CA Comments: null ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: About upcoming limits on trusted certificates
Thanks to all of you who have participated in this discussion. We plan to begin work on a minor update (version 2.7.1) to Mozilla's Root Store Policy soon. In response to this discussion, the following two issues have been created and labelled for 2.7.1. Wayne filed https://github.com/mozilla/pkipolicy/issues/204 "Limit TLS Certificates to 398 day validity after Aug 31, 2020" And I filed https://github.com/mozilla/pkipolicy/issues/206 "Limit re-use of domain name verification to 395 days" which says: "When we update Mozilla's Root Store Policy to limit TLS certificate validity periods to 398 days, we should also update the policy to limit re-use of domain name verification results. I started discussion about this in m.d.s.p, and consensus appears to support the idea, with the two primary recommendations: - Change the effective date to April 2021 to give CAs time to update their processes. - Provide a Mozilla Security Blog explaining the reasons for making this change. The idea being to provide one place where people can go to read about why it is important to frequently re-verify domain name ownership and why it is important to reduce TLS cert validity periods." Thanks, Kathleen ___ 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 Monday, March 16, 2020 at 9:06:33 PM UTC, Tim Hollebeek 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. > > > > -Tim Tim, Completely agree on your statement that it's a disturbing practice. We've sadly come across it several times in the past 12-18 months, leading to problems for the customer and of course lost business for us as they inevitably decide to remain with the incumbent CA when faced with a hard deadline for certificate revocation - regardless of the natural expiry dates. Your points about the impact and costs to the wider ecosystem ring true, as well. Revocation should not be used to punish those wishing to migrate CAs. We certainly don't do it. More troubling is that each time it's either been mentioned early in discussions or has caused a business discussion to cease at a late stage - it's been DigiCert that was the current CA and they/you participated in this practice of threatening revocation of certificates well before expiry due to contract termination. I have at least 5 major global enterprises that this has happened to recently. Am happy to share more details privately if you wish to discuss. Nick ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: About upcoming limits on trusted certificates
> On 3/11/20 3:51 PM, Paul Walsh wrote: > > Can you provide some insight to why you think a shorter frequency in > domain validation would be beneficial? > > To start with, it is common for a domain name to be purchased for one year. > A certificate owner that was able to prove ownership/control of the domain > name last year might not have renewed the domain name. So why should > they be able to get a renewal cert without having that re-checked? This has been a favorite point of Jeremy's for as long as I've been participating in the CA/Browser Forum and on this list. Tying certificate lifetimes more closely to the lifetime and validity of the domains they are protecting would actually make a lot of sense, and we'd support any efforts to do so. -Tim smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Acceptable forms of evidence for key compromise
I agree with Corey on this. I was disappointed that the LAMPS discussion two years ago was not as helpful as it could have been. For what it's worth, while we generally try to accept any reasonable proof of key compromise, we have seen quite a large variety of things sent to us. This includes people actually sending us private keys in various forms, which is completely unnecessary and something we'd like to avoid. When we are unable to verify a proof, we provide explicit instructions on how to create a proof in a standardized form that's easy to very. I believe it currently involves signing something with openssl, so it should be easy to carry out for anyone who is involved in these sorts of discussions and has access to the private key. Standardized procedures (plural, I don't think a one size fits all solution would necessarily be good) would be very helpful for everyone, including mitigating the risk that some less sophisticated CAs accept proofs that are not valid, introducing a potential denial of service attack. The whole purpose of having minimum security requirements is to make sure important things like this are handled correctly, using procedures that have received appropriate scrutiny from individuals who understand the security implications. I also think it's potentially useful to discuss standardizing lists of known compromised keys, and how to check them before issuance. The problem of revoking them could be avoided entirely if they were never issued in the first place. BTW the same is currently true for proving domain control for the purposes of revocation ... existing practice for CAs is currently all over the map, and we've discussed it before without reaching a resolution. It would be useful if there were actual requirements for that, too. -Tim > -Original Message- > From: dev-security-policy > On Behalf Of Corey Bonnell via dev-security-policy > Sent: Monday, March 2, 2020 2:48 PM > To: Nick Lamb ; Mozilla pol...@lists.mozilla.org> > Cc: Matt Palmer > Subject: RE: Acceptable forms of evidence for key compromise > > There was quite a bit of discussion on the development of a standard > revocation request format on LAMPS WG mailing list two years ago in the > wake of the Trustico mass revocation: > https://mailarchive.ietf.org/arch/msg/spasm/qeVHLeG6- > Q_47QKNdyOOxsAT3Zk/. > Nothing was developed in terms of a concrete proposal specifying a > revocation request format/protocol, but the pros/cons of such were hashed > out pretty thoroughly. > > I do think there's value in developing some standard mechanism to request > revocation/demonstrate possession of the private key. The use of such a > mechanism would reduce the burden of work for those reporting key > compromises, as the reporter would not need to learn how to demonstrate > possession the private key 15 different ways to 15 different CAs. And CAs > would benefit from such a mechanism, as they wouldn't need to spend > support cycles working with the reporter to arrive at a suitable means to > demonstrate possession or have to learn some exoteric software tooling > that the reporter is using to prove possession. > > Thanks, > Corey > > -Original Message- > From: dev-security-policy > On > Behalf Of Nick Lamb via dev-security-policy > Sent: Monday, March 2, 2020 2:35 PM > To: dev-security-policy@lists.mozilla.org > Cc: Matt Palmer > Subject: Re: Acceptable forms of evidence for key compromise > > On Mon, 2 Mar 2020 13:48:55 +1100 > Matt Palmer via dev-security-policy > wrote: > > > In my specific case, I've been providing a JWS[1] signed by the > > compromised private key, and CAs are telling me that they can't (or > > won't) work with a JWS, and thus no revocation is going to happen. > > Is this a reasonable response? > > I don't hate JWS, but I can see Ryan's point of view on this. Not every > "proof" is easy to definitively assess, and a CA doesn't want to get into > the > game of doing detailed forensics on (perhaps) random unfounded claims. > > Maybe it makes sense for Mozilla to provide in its policy (without limiting > what else might be accepted) an example method of demonstrating Key > Compromise > which it considers definitely sufficient ? > > I'd also be comfortable with such an example in the BRs, if people think > that's the right place to do this. > > > Nick. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://scanmail.trustwave.com/?c=4062=- > d_d3pcpfBniFU3M4wE7RXWpZKF7oGE841cFGIoHqA=5=https%3a%2f% > 2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: About upcoming limits on trusted certificates
On Wed, 11 Mar 2020 15:39:34 -0700 Kathleen Wilson via dev-security-policy wrote: > What do you all think about also limiting the re-use of domain > validation? I'm strongly in favor of this change, and think domain validation reuse should eventually be limited to a period much shorter than one year (days or even hours), even if certificates lifetimes remain capped at one year. Others have already touched on the issue of domain ownership transfer (BygoneSSL), but I'd like to highlight a related issue: if a domain's DNS, email, or web infrastructure is ever compromised, even briefly, then the attacker can obtain two-year-long domain validation authorizations from any number of CAs. Then at any point in the next two years, the attacker can obtain a one-year certificate, and ask the CA not to log it to CT. Even if Firefox did enforce CT, the attacker could wait to log the certificate until right before using it in an attack. The consequence of the above is that even if a website suffers a fleeting compromise, they and their users are at risk of attack from an illegitimate certificate for three entire years. Anecdotally, I've found that website operators are surprised when they learn this. It's intuitive that the attack window would be lower-bounded by certificate lifetime, but the additional attack time from domain validation reuse comes as an unpleasant surprise. Therefore, Firefox should aim to make the attack window as close to the maximum certificate lifetime as possible, which requires reducing validation reuse time to the order of hours/days. Limiting to one year is a good first step. Regards, Andrew ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
