Re: Terms and Conditions that use technical measures to make it difficult to change CAs
On Thu, Apr 16, 2020 at 4:09 PM Tim Hollebeek wrote: > On the other hand, for example in Shanghai, some > have argued that there is nothing wrong with a CPS that does not disclose > anything > about how CAs implement any of the policy requirements. Understandably, it's a spectrum. For these sorts of implementation questions, I think this is really an area where the Detailed Control Reporting ( see https://cabforum.org/2020/03/20/minutes-for-ca-browser-forum-f2f-meeting-49-bratislava-19-20-february-2020/#WebTrust-Update for an example) would be helpful here. In the end, the transparency is about finding the right level of relevant information that's useful. Complete transparency can be useful, but can also hide shenanigans in the information overload. We see this regularly with CP/CPS reviews, in which dozens of CPSes may have subtle and ill-defined interactions that are only obvious after hundreds of pages of reading. Figuring out how to better surface these, through both normative requirements and standardized disclosures, is the approach. > I would personally find it very unfortunate if the trend continues, and we > have > increasingly vacuous CPSs that contain no relevant information. But in the > absence > of requirements to disclose relevant practices, I'm not surprised that that's > a trend > that has been embraced by some CAs. Figuring out the right transparency for the original problem on the thread is difficult. Do you think the steps I proposed work? I'm not confident they do, but I think they might be a useful stepping stone. Given DigiCert originally raised this, perhaps you have suggestions for possible means of unambiguously getting disclosure around revocation practices and policies? ___ 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
Generally, I'm in favor of transparency requirements, and many of Ryan's ideas would be useful or interesting to pursue. Transparency is often the first and best step towards improving business practices. And the entire purpose of a CPS is to disclose the business practices that implement a particular certificate policy (e.g. the Baseline Requirements). So I think it's entirely appropriate that Mozilla and other root policies consider and implement disclosure policies that mandate that certain security-relevant business practices be disclosed. Such requirements have even appeared in the Baseline Requirements from time to time, and should continue to do so. Unfortunately, some CAs have chosen to use CPSs that have very little content other than "we comply with the baseline requirements". Root programs have taken a variety of stances on this in the past. For example, Mozilla has required CAs to actually disclose which validation methods they use, as opposed to which they _might_ use (all of them!). On the other hand, for example in Shanghai, some have argued that there is nothing wrong with a CPS that does not disclose anything about how CAs implement any of the policy requirements. I personally find myself in the transparency camp, and would prefer that when the details of how a CA complies with a particular requirement is security relevant, it would be an improvement if those details were disclosed. But that's in conflict with the "Default Non-disclose" policy that many people, both on the root program and CA side, have advocated for. I would personally find it very unfortunate if the trend continues, and we have increasingly vacuous CPSs that contain no relevant information. But in the absence of requirements to disclose relevant practices, I'm not surprised that that's a trend that has been embraced by some CAs. -Tim > -Original Message- > From: dev-security-policy > On Behalf Of Robin Alden via dev-security-policy > Sent: Tuesday, April 14, 2020 8:13 PM > To: r...@sleevi.com > Cc: Mozilla > Subject: 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 implementatio
Re: GTS - OCSP serving issue 2020-04-09
On 16/04/2020 14:49, Kurt Roeckx via dev-security-policy wrote: On 2020-04-16 14:56, Neil Dunbar wrote: I would have thought that an OCSP-stapling implementation which got an OCSP status code 'successful' (0) with a 'revoked' status for the certificate would want to pass that on to the client, replacing any prior OCSP successful/status-good report, whether that prior report was still valid. As owner of the certificate, I think you actually don't want to do that, because things will stop working. If it's revoked you want to get a new certificate, and as long as you don't have the new one, you want to use the old certificate and staple the good OCSP response. Really? Continue to use a certificate in the (more recent) knowledge that the issuing CA has disavowed it? I know that will work from the perspective of the TLS protocol, but it might be the sort of thing which would run afoul of the owner's subscriber agreement. So, if the CA operated on a purely customer-enforced OCSP-stapling approach (ie, didn't publish the OCSP URI in the end certificate), that would mean the relying party would have no reasonable way to validate whether the certificate even _could_ be trusted. I mean - I see what you're saying: you have a website which you want to keep working until you replace your certificate and/or private key. But if I had signed knowledge from the issuing CA that (for instance) my private key was compromised, I don't think it would be terribly ethical to continue its use; depending on your subscriber agreement it might not even be lawful. It seems like you are materially misrepresenting the state of your certificate to the detriment of your relying parties. Regards, Neil ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: GTS - OCSP serving issue 2020-04-09
> As owner of the certificate, I think you actually don't want to do that, > because things will stop working. If it's revoked you want to get a new > certificate, and as long as you don't have the new one, you want to use the > old certificate and staple the good OCSP response. > That depends on what you're optimizing for. While your solution definitely helps with Availability, it deprioritizes Confidentiality and Integrity. For example, if your private key was compromised and your certificate subsequently revoked, your service would continue to be accessible (good availability) but all communications could be MITMed (bad for Confidentiality and Integrity). Thanks, Corey This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GTS - OCSP serving issue 2020-04-09
On 2020-04-16 14:56, Neil Dunbar wrote: I would have thought that an OCSP-stapling implementation which got an OCSP status code 'successful' (0) with a 'revoked' status for the certificate would want to pass that on to the client, replacing any prior OCSP successful/status-good report, whether that prior report was still valid. As owner of the certificate, I think you actually don't want to do that, because things will stop working. If it's revoked you want to get a new certificate, and as long as you don't have the new one, you want to use the old certificate and staple the good OCSP response. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GTS - OCSP serving issue 2020-04-09
On 16/04/2020 00:04, Nick Lamb via dev-security-policy wrote: Specifically: You should cache your stapled GOOD answers in durable storage if practical, and when periodically refreshing you should report non-GOOD answers to the operator (e.g. logging them as an ERROR condition) but always continue to present clients with the last GOOD answer until it actually expires even if you receive newer non-GOOD OCSP responses. For the avoidance of doubt (and my own poor brain) - does 'GOOD' here mean OCSP status code 'successful' (0) AND returning a 'good' status for the certificate, or does it just mean status code 'successful'? The GTS case here was returning OCSP exception status 'unauthorized' (6). I would have thought that an OCSP-stapling implementation which got an OCSP status code 'successful' (0) with a 'revoked' status for the certificate would want to pass that on to the client, replacing any prior OCSP successful/status-good report, whether that prior report was still valid. But I'm with you on the implementation retaining the last successful OCSP report until it expires (I'd go further: if I got a successful/revoked response, followed by a successful/good response later on, I'd be flagging that to the CA as a serious problem, and retaining the successful/revoked ones until _it_ expires) Cheers, Neil ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
