Re: Terms and Conditions that use technical measures to make it difficult to change CAs
On Tue, Apr 14, 2020 at 8:13 PM Robin Alden wrote: > I am ambivalent to the idea of having a list of business practices, > presumably over and above those required in law, that CAs must publish to > the community. I know it was more an aside, but I’m not sure I follow what you mean by “over an above”. Was that meant to suggest those required in law need not be documented? I suppose that CAs' existing contractual terms, particularly for large > subscribers such as enterprise organizations, are negotiated between the > two parties and so are typically known only to the CA and to the > subscriber. For other individual subscribers a standard subscriber > agreement published in advance more likely applies. > I'm sure that some subscribers will be happy to have additional oversight > of contractual terms rather than rely on their own reading and > understanding of the contract they sign, while others would not choose it, > were that choice available to them. Indeed, there’s real trade-offs here. Browsers selection of which CAs to trust is based on how well those CAs align with the browsers’ goals and needs. This is why we don’t just trust every Average Joe who knows how to run openssl via the cmdline, and why the Mozilla policy exists. There are two main ways to ensure that CAs’ actions are aligned with browsers’ needs: requirements & prohibitions on certain actions (e.g. browser policies, audit criteria, guidelines like the Baseline Requirements) and transparency (via CT, via CP/CPS, etc) Paraphrasing Jeremy's answer, actions speak louder than words. > Are these things that have been done, or things that contracts permit? > Is it words or actions that you seek to restrict? Why does this distinction matter? The reality is outright restricting either and/or both is challenging on a number of dimensions, least of all being that we continue to have trouble capturing basic technical requirements clearly and unambiguously (or at least, creative interpretations about ambiguity). The first step is to transparency to try and quantify this problem. Simplistically, the life of a certificate today is either: > Issue - use - expire; or > Issue - use - revoke, > and in each case no further management of the certificate's state is > possible by either the CA or the subscriber after the terminal event. > However, if there are 'bad' revocations that will be ignored the life-cycle > gets another step under certain circumstances: > Issue - use - 'bad' revocation (ignored) - use - 'good' revocation. > This requires both that the user is able to request a second revocation > for a different reason after an earlier revocation, and also that the CA > has further obligations to take actions concerning this certificate after > it had been initially revoked, e.g. re-revoking if misissuance or > subscriber key compromise were detected. I mean, this is spot on the problem. The certificate lifecycle between different parties is misaligned, and this is an area where existing technologies don’t have easy answers. This isn’t a problem unique to CAs either; consider a Root Program A that explicitly requires revocation for Reason X, but a different Root Program B does not want to have certificates and sites stop working just Root Program A doesn’t like the certificate. Presumably, if a UA is going to define policies, such as around the reason codes to use and how and when they’re used, then it’s going to have to require that the CA be responsible for that certificate unless and until it hits one of those terminal reasons. These problems are “solvable”, but take time. Having more robust expressions for revocation is an approach worth exploring. Legacy clients would still treat them as absolutely rejected, but modern clients responding to modern problems can use these modern solutions. Regardless, starting work on a normative profile for CRL Reasons to reduce ambiguity seems... useful? If only to flesh out precisely the problem space involved where a CA has the near-universal power (when revocation checking is supported) to rescind a certificate arbitrarily, contrary to the browser, user, and site needs and desires. Having that sort of choke point, which spans a variety of software clients, and for which limited alternatives exist by necessity, seems bad for all. ___ 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
> .. There’s plenty of precedent in having Root Policy or the > Baseline Requirements require a CP/CPS explicitly state something; > examples such as the CAA domain name, the problem reporting mechanism > and contact address, and compliance to the latest version of the BRs. > > If we apply that idea here, it might make sense to require the CA’s > CP/CPS make a clear and unambiguous statement about whether or not > they engage in X as a practice. I’m not quite sure what X should say, > but the idea is that it would be transparent to Relying Parties > wanting to evaluate a CA, as well as to User Agents when evaluating > whether or not a given CA's practices provide a service relevant to > user's of that software product. While it's conceivable that sites are > already having these practices disclosed to them, having a consistent > and public disclosure would help bring transparency into what CAs are > engaging in this practice, and which have committed not to use > revocation in this way, which can help make it easier to compare the > trustworthiness of CAs up-front. I am ambivalent to the idea of having a list of business practices, presumably over and above those required in law, that CAs must publish to the community. I suppose that CAs' existing contractual terms, particularly for large subscribers such as enterprise organizations, are negotiated between the two parties and so are typically known only to the CA and to the subscriber. For other individual subscribers a standard subscriber agreement published in advance more likely applies. I'm sure that some subscribers will be happy to have additional oversight of contractual terms rather than rely on their own reading and understanding of the contract they sign, while others would not choose it, were that choice available to them. Paraphrasing Jeremy's answer, actions speak louder than words. Are these things that have been done, or things that contracts permit? Is it words or actions that you seek to restrict? Kathleen posted this on the Mozilla PKI Policy github. https://github.com/mozilla/pkipolicy/issues/208 saying > ".. some CAs have Terms and Conditions which say that if the customer > moves to (or even tries to use) another CA, all of their certificates > will be revoked. Enforcing all revocations (independent of reason) > supports this bad behavior by CAs, helping them to hold their > customers hostage. But if CAs always add the CRLReason for > revocations, we can selectively enforce revocation for certain reasons, > and have varying levels of enforcement (e.g. overridable versus > not-overridable) Enforcing or restricting some revocation reasons is an interesting idea but I think that selective implementation of revocation based on the concept of there being 'good' and 'bad' revocation reasons has an implicit challenge. It changes the certificate life-cycle. Simplistically, the life of a certificate today is either: Issue - use - expire; or Issue - use - revoke, and in each case no further management of the certificate's state is possible by either the CA or the subscriber after the terminal event. However, if there are 'bad' revocations that will be ignored the life-cycle gets another step under certain circumstances: Issue - use - 'bad' revocation (ignored) - use - 'good' revocation. This requires both that the user is able to request a second revocation for a different reason after an earlier revocation, and also that the CA has further obligations to take actions concerning this certificate after it had been initially revoked, e.g. re-revoking if misissuance or subscriber key compromise were detected. Regards Robin Alden Sectigo Limited 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
GTS - OCSP serving issue 2020-04-09
m.d.s.p community, Google Trust Services just filed https://bugzilla.mozilla.org/show_bug.cgi?id=1630040 which contains the same information as the report that follows. >From 2020-04-08 16:25 UTC to 2020-04-09 05:40 UTC, Google Trust Services' EJBCA based CAs (GIAG4, GIAG4ECC, GTSY1-4) served empty OCSP data which led the OCSP responders to return unauthorized. These CAs exist for issuance of custom certificate profiles and certificates for test sites for inactive roots. Our primary CAs (GTS CA 1O1 and GTS CA 1D2) were unaffected. The problem self-corrected, but we have added safeguards to prevent recurrence. 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. Monitoring detected the issue on 2020-04-08 at 16:35 UTC. The root cause was identified within hours. The issue was automatically remediated in the next generation and push to CDN cycle while debugging and fixes were ongoing. 2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. 2020-04-08, 11:29 UTC - Scheduled system update begins 2020-04-08, 14:00 UTC - Incorrect OCSP archives are generated 2020-04-08, 15:03 UTC - Scheduled system update concludes 2020-04-08, 16:20 UTC - Incorrect OCSP responses pushed to CDN 2020-04-08, 16:35 UTC - First production monitoring alert fires 2020-04-08, 22:00 UTC - Correct OCSP archives are generated automatically 2020-04-09, 00:20 UTC - Correct OCSP responses pushed to CDN 2020-04-09, 05:40 UTC - Monitoring confirms all probes are passing 3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. The affected CAs are only used for infrequent and manual custom certificate issuance. No certificate issuance aside from a manually issued post update test certificate to validate the upgrade to resolve the issue took place during this period. The issue in question also was specific to refreshing OCSP responses and not certificate issuance. 4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. No certificate issuance aside from a manually issued post update test certificate to validate the upgrade to resolve the issue took place during this period. The test certificate was a valid and fully compliant issuance. 5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. No certificate issuance aside from the manually issued post update test certificate to validate the the upgrade. 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. Our creation of OCSP responses and packaging them for serving is designed to fail if any sub-command fails using set -e. However, if the function call is part of an AND or OR sequence (ie. using '&&' or '||' control operators), the set -e is suppressed inside the function. The tool we use to fetch OCSP responses from EJBCA correctly returned a non-zero exit code (due to no OCSP responses being generated because EJBCA was not running), but because it was called inside a function with its own error handling (using && syntax), the script continued without handling the error properly and wrongly used empty tar.gz files with no responses in them. The bug had existed for multiple years as a potential race condition and we did not encounter it previously. Quality tests are executed before publication to the CDN, however, those tests accommodate empty responses as a valid condition because it is something that can and does happen. This condition did not repeat on the following update of the OCSP responses. As a result the next update resolved the issue. Our monitoring caught the issue enabling expedient root cause analysis and resolution. 7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. No certificate issuance aside from a valid manually issued post update test certificate to validate the upgrade took place during this period. The logic error that led to incorrect OCSP responses being served has been corrected, is checked in and in production. Additionally, checks have
Re: Welcome Ben Wilson to Mozilla!
On Monday, April 13, 2020 at 12:07:40 PM UTC-5, Kathleen Wilson wrote: > All, > > I am pleased to announce that Ben Wilson has joined Mozilla as a CA > Program Manager! > > Ben has worked in PKI security, compliance, and policy since 1998. > Previously, he worked at DigiCert in various roles, including VP of PKI > Operations, VP of Compliance, and Chair of DigiCert’s Policy Authority > team to develop and communicate policies and practices for internal and > external stakeholders. Ben has also been very involved in the CA/Browser > Forum. He is a former Chair of the CA/Browser Forum and of the American > Bar Association’s Information Security Committee. Over the years, Ben > has also participated in this mozilla.dev.security.policy forum. > > Here are some of the things that Ben will be responsible for: > + Steps 3 through 9 of Mozilla’s root inclusion process[1], which > includes the detailed CP/CPS reviews[2] and the public discussion phase[3] > + CA Incident Bugs[4] > + Updates to Mozilla’s Root Store Policy[5] and the Common CCADB > Policy[6], including prioritizing potential changes[7] and leading > discussions to determine the actual changes > + Represent Mozilla in the CA/Browser Forum, along with Wayne > > I have added Ben to the Policy_Participants wiki page[8], and updated > Wayne's entry. > > Welcome, Ben! > > Thanks, > Kathleen > > [1] https://wiki.mozilla.org/CA/Application_Process > [2] https://wiki.mozilla.org/CA/Application_Verification#Detailed_Review > [3] https://wiki.mozilla.org/CA/Application_Verification#Public_Discussion > [4] https://wiki.mozilla.org/CA/Incident_Dashboard > [5] > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ > [6] https://www.ccadb.org/policy > [7] https://github.com/mozilla/pkipolicy/issues > [8] https://wiki.mozilla.org/CA/Policy_Participants Thanks for sharing Kathleen and I am thrilled to hear this news. Ben, we certainly look forward to continuing working with you in this new role. Jeff ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
