Re: CPS URLs
On Mon, 6 Jul 2020 19:22:22 +0200 Matthias van de Meent via dev-security-policy wrote: > I notice that a lot of Subscriber Certificates contain https-based > URLs (e.g. PKIOverheid/KPN, Sectigo, DigiCert), and that other > http-based urls redirect directly to an https-based website (e.g. > LetsEncrypt, GoDaddy). A piece of good news in this space is that these documents are generally intended to be accessed with a web browser, as a result the browser gets to interpret the URL and may choose to upgrade to HTTPS based on considerations including: * Policy of the host, or any parent domain (even a few TLDs are HSTS preloaded meaning any HTTP URL in those domains will be treated as if it was HTTPS by a web browser) * Policy of the user (e.g. HTTPS-Everywhere) can arbitrarily upgrade URLs regardless of where they come from. Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CPS URLs
On Mon, 6 Jul 2020 at 19:30, Ryan Sleevi wrote: > > On Mon, Jul 6, 2020 at 1:22 PM Matthias van de Meent via dev-security-policy > wrote: >> >> ... >> >> 1.) What was the reasoning behind not (also / specifically) allowing >> an HTTPS url? Was there specific reasoning reasoning? > > > Nope, no specific reasoning. The ambiguity here is whether it's resources > dereferenced via an HTTP protocol (which would include HTTP over TLS) or > whether it's HTTP schemed resources (which would not). The meaningful > distinction was to exclude other forms of scheme/protocols, such as LDAP > (inc. LDAPS) and FTP (inc. FTPS) > >> >> 2.) Should this be fixed, or should the batch of certificates with an >> http `certificatePolicies:policyQualifiers:qualifier:cPSuri` be >> revoked as misissued? > > > Yeah, this is something that was already flagged as part of the validation WG > work to clean up certificate profiles, in that there's other forms of > ambiguity here. For example, if one includes an HTTP(S) URL, can they also > include one of the undesirable schemes? How many CPS URIs can they include? > etc. > Great, thanks for the reply, and thanks for the concise information. Then I shall await such update to the BR. -Matthias ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CPS URLs
On Mon, Jul 6, 2020 at 1:22 PM Matthias van de Meent via dev-security-policy wrote: > Hi, > > As per BR v1.7.0, section 7.1.2.3, a Subscriber Certificate MAY > include `certificatePolicies:policyQualifiers:qualifier:cPSuri`, which > must then contain: > > > HTTP URL for the Subordinate CA's Certification Practice Statement, > Relying Party Agreement or other pointer to online information provided by > the CA > > (this section has existed as such since at least BR v1.3.0 as such, > and can be traced back all the way to BR v1.0) > > I notice that a lot of Subscriber Certificates contain https-based > URLs (e.g. PKIOverheid/KPN, Sectigo, DigiCert), and that other > http-based urls redirect directly to an https-based website (e.g. > LetsEncrypt, GoDaddy). > > As I am not part of the CA/B Forum, and could not find open (draft) > ballots in the cabforum/docs repository about updating this section; > I'll ask this: > > 1.) What was the reasoning behind not (also / specifically) allowing > an HTTPS url? Was there specific reasoning reasoning? > Nope, no specific reasoning. The ambiguity here is whether it's resources dereferenced via an HTTP protocol (which would include HTTP over TLS) or whether it's HTTP schemed resources (which would not). The meaningful distinction was to exclude other forms of scheme/protocols, such as LDAP (inc. LDAPS) and FTP (inc. FTPS) > 2.) Should this be fixed, or should the batch of certificates with an > http `certificatePolicies:policyQualifiers:qualifier:cPSuri` be > revoked as misissued? > Yeah, this is something that was already flagged as part of the validation WG work to clean up certificate profiles, in that there's other forms of ambiguity here. For example, if one includes an HTTP(S) URL, can they also include one of the undesirable schemes? How many CPS URIs can they include? etc. > 3.) If HTTPS is disallowed for a good reason, then should redirecting > to HTTPS also be disallowed? > > Note: In other sections (e.g. 3.2.2.4.18) https is specifically called > out as an allowed protocol. > > My personal answer regarding 2. is 'yes, this should be fixed in the > BR', unless there is solid reasoning behind 1. > > > With regards, > > Matthias > ___ > 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
CPS URLs
Hi, As per BR v1.7.0, section 7.1.2.3, a Subscriber Certificate MAY include `certificatePolicies:policyQualifiers:qualifier:cPSuri`, which must then contain: > HTTP URL for the Subordinate CA's Certification Practice Statement, Relying > Party Agreement or other pointer to online information provided by the CA (this section has existed as such since at least BR v1.3.0 as such, and can be traced back all the way to BR v1.0) I notice that a lot of Subscriber Certificates contain https-based URLs (e.g. PKIOverheid/KPN, Sectigo, DigiCert), and that other http-based urls redirect directly to an https-based website (e.g. LetsEncrypt, GoDaddy). As I am not part of the CA/B Forum, and could not find open (draft) ballots in the cabforum/docs repository about updating this section; I'll ask this: 1.) What was the reasoning behind not (also / specifically) allowing an HTTPS url? Was there specific reasoning reasoning? 2.) Should this be fixed, or should the batch of certificates with an http `certificatePolicies:policyQualifiers:qualifier:cPSuri` be revoked as misissued? 3.) If HTTPS is disallowed for a good reason, then should redirecting to HTTPS also be disallowed? Note: In other sections (e.g. 3.2.2.4.18) https is specifically called out as an allowed protocol. My personal answer regarding 2. is 'yes, this should be fixed in the BR', unless there is solid reasoning behind 1. With regards, Matthias ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
398 Cert Life span 1Sep2020
Hi All, How will internal CA's be affected. If I issue or have issued 2 years certificates, how will the browsers treat these certificates ? Just after guidance .. M ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On 06/07/2020 12:47, Rob Stradling via dev-security-policy wrote: On 06/07/2020 06:11, Dimitris Zacharopoulos via dev-security-policy wrote: IETF made an attempt to set an extention for EKU constraints (https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/) where Rob Stradling made an indirect reference in https://groups.google.com/d/msg/mozilla.dev.security.policy/f5-URPoNarI/yf2YLpKJAQAJ (Rob, please correct me if I'm wrong). There was a follow-up discussion in IETF that resulted that noone should deal with this issue (https://mailarchive.ietf.org/arch/msg/spasm/3zZzKa2lcT3gGJOskVrnODPBgM0/). A day later, all attempts died off because noone would actually implement this(?) https://mailarchive.ietf.org/arch/msg/spasm/_gJTeUjxc2kmDcRyWPb9slUF47o/. If this extension was standardized, we would probably not be having this issue right now. However, this entire topic demonstrates the necessity to standardize the EKU existence in CA Certificates as constraints for EKUs of leaf certificates. Oh, I misread. Standardizing the use of the existing EKU extension in CA certificates as a constraint for permitted EKUs in leaf certificates has been proposed at IETF before. Probably many times before. However, plenty of people take the (correct, IMHO) view that the EKU extension was not intended to be (ab)used in this way, and so the chances of getting "rough consensus" for a Standards Track RFC to specify this seems rather remote. I suppose it might be worth drafting an Informational RFC that explains how the EKU extension is used in practice, what the footguns are and how to avoid them, what the security implications are of doing EKU wrong, etc. If only we could edit RFC2459 so that it (1) defined an "EKU constraints" extension and (2) said that the EKU extension MUST NOT appear in CA certificates... Unfortunately, we're more than 20 years too late to do that. And whilst it completely sucks that real-world use of the EKU extension comes with some nasty footguns, I just don't see how you'd ever persuade the WebPKI ecosystem to adopt a new "EKU Constraints" extension at this point in history. -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On 06/07/2020 06:11, Dimitris Zacharopoulos via dev-security-policy wrote: IETF made an attempt to set an extention for EKU constraints (https://datatracker.ietf.org/doc/draft-housley-spasm-eku-constraints/) where Rob Stradling made an indirect reference in https://groups.google.com/d/msg/mozilla.dev.security.policy/f5-URPoNarI/yf2YLpKJAQAJ (Rob, please correct me if I'm wrong). There was a follow-up discussion in IETF that resulted that noone should deal with this issue (https://mailarchive.ietf.org/arch/msg/spasm/3zZzKa2lcT3gGJOskVrnODPBgM0/). A day later, all attempts died off because noone would actually implement this(?) https://mailarchive.ietf.org/arch/msg/spasm/_gJTeUjxc2kmDcRyWPb9slUF47o/. If this extension was standardized, we would probably not be having this issue right now. However, this entire topic demonstrates the necessity to standardize the EKU existence in CA Certificates as constraints for EKUs of leaf certificates. If only we could edit RFC2459 so that it (1) defined an "EKU constraints" extension and (2) said that the EKU extension MUST NOT appear in CA certificates... Unfortunately, we're more than 20 years too late to do that. And whilst it completely sucks that real-world use of the EKU extension comes with some nasty footguns, I just don't see how you'd ever persuade the WebPKI ecosystem to adopt a new "EKU Constraints" extension at this point in history. -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
Summary of some OCSP client tests: - `Root` is self signed, and does not have any EKU's - 'ICA' is signed by 'Root' with the EKU ServerAuth and ClientAuth - 'ICA 2' is signed by 'Root' with the EKU ServerAuth, ClientAuth and OCSPSigning - 'Server certificate' is signed by `ICA` with the EKU ServerAuth and ClientAuth - Both `ICA 2` and `ICA` have their own delegated OCSP responder certificate. - `ICA 2` signs an OCSP response for `ICA` and overrules the response created by the delegated responder. certutil (Windows): Recognizes but rejects the revoked response openssl (Ubuntu & MacOS): Accepts the response ocspcheck (MacOS): Accepts the response Output and script located on: https://gist.github.com/vanbroup/84859cd10479ed95c64abe6fcdbdf83d On Mon, 6 Jul 2020 at 12:09, Dimitris Zacharopoulos wrote: > On 6/7/2020 11:39 π.μ., Paul van Brouwershaven via dev-security-policy > wrote: > > As follow up to Dimitris comments I tested the scenario where a > > sibling issuing CA [ICA 2] with the OCSP signing EKU (but without > > digitalSignature KU) under [ROOT] would sign a revoked OCSP response for > > [ICA] also under [ROOT] > > https://gist.github.com/vanbroup/84859cd10479ed95c64abe6fcdbdf83d > > > > I was actually surprised to see that certutil fails to validate decode > the > > OCSP response in this scenario. But this doesn't say it's not a problem > as > > other responders or versions might accept the response. > > > > I will try to perform the same test on Mac in a moment. > > Thank you very much Paul, this is really helpful. > > Dimitris. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On 6/7/2020 11:39 π.μ., Paul van Brouwershaven via dev-security-policy wrote: As follow up to Dimitris comments I tested the scenario where a sibling issuing CA [ICA 2] with the OCSP signing EKU (but without digitalSignature KU) under [ROOT] would sign a revoked OCSP response for [ICA] also under [ROOT] https://gist.github.com/vanbroup/84859cd10479ed95c64abe6fcdbdf83d I was actually surprised to see that certutil fails to validate decode the OCSP response in this scenario. But this doesn't say it's not a problem as other responders or versions might accept the response. I will try to perform the same test on Mac in a moment. Thank you very much Paul, this is really helpful. Dimitris. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On 6/7/2020 11:03 π.μ., Ryan Sleevi via dev-security-policy wrote: Yep. You have dismissed it but others may have not. If no other voices are raised, then your argument prevails:) I mean, it’s not a popularity contest:) As others have highlighted already, there are times where people get confused by you posting by default in a personal capacity. It is easy to confuse readers when using the word "I" in your emails. Even if you use your "Google Chrome hat" to make a statement, there might be a different opinion or interpretation from the Mozilla Module owner where this Forum is mainly for. There's more agreement than disagreement between Mozilla and Google when it comes to policy so I hope my statement was not taken the wrong way as an attempt to "push" for a disagreement. I have already asked for the Mozilla CA Certificate Policy owner's opinion regarding separate hierarchies for Mozilla Root program in https://groups.google.com/d/msg/mozilla.dev.security.policy/EzjIkNGfVEE/jOO2NhKAAwAJ, highlighting your already clearly stated opinion on behalf of Google, because I am interested to hear their opinion as well. I hope I'm not accused of doing something wrong by asking for more "voices", if there are any. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
> > Some tests were performed by Paul van Brouwershaven > > https://gist.github.com/vanbroup/84859cd10479ed95c64abe6fcdbdf83d. > > As mentioned, those tests weren’t correct. I’ve provided sample test cases > to several other browser vendors, and heard back or demonstrated that > they’re vulnerable. As are the majority of open-source TLS libraries with > support for OCSP. Ryan, you made a statement about a bug in Golang, the test case linked by Dimitris was about the follow-up tests I did with certutil and Test-Certificate in powershell. As follow up to Dimitris comments I tested the scenario where a sibling issuing CA [ICA 2] with the OCSP signing EKU (but without digitalSignature KU) under [ROOT] would sign a revoked OCSP response for [ICA] also under [ROOT] https://gist.github.com/vanbroup/84859cd10479ed95c64abe6fcdbdf83d I was actually surprised to see that certutil fails to validate decode the OCSP response in this scenario. But this doesn't say it's not a problem as other responders or versions might accept the response. I will try to perform the same test on Mac in a moment. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Mon, Jul 6, 2020 at 3:38 AM Dimitris Zacharopoulos wrote: > On 6/7/2020 9:47 π.μ., Ryan Sleevi wrote: > > I can understand wanting to wait to see what others do first, but that’s > not leadership. > > > This is a security community, and it is expected to see and learn from > others, which is equally good of proposing new things. I'm not sure what > you mean by "leadership". Leadership for who? > Leadership as a CA affected by this, taking steps to follow through on their commitments and operate beyond reproach, suspicion, or doubt. As a CA, the business is built on trust, and that is the most essential asset. Trust takes years to build and seconds to lose. Incidents, beyond being an opportunity to share lessons learned and mitigations applied, provide an opportunity for a CA to earn trust (by taking steps that are disadvantageous for their short-term interests but which prioritize being irreproachable) or lose trust (by taking steps that appear to minimize or dismiss concerns or fail to take appropriate action). Tim’s remarks on behalf of DigiCert, if followed through on, stand in stark contrast to remarks by others. And that’s encouraging, in that it seems that past incidents at DigiCert have given rise to a stronger focus on security and compliance than May have existed there in the past, and which there were concerns about with the Symantec PKI acquisition/integration. Ostensibly, that is an example of leadership: making difficult choices to prioritize relying parties over subscribers, and to focus on removing any/all doubt. You mean when I dismissed this line of argument? :) > > > Yep. You have dismissed it but others may have not. If no other voices are > raised, then your argument prevails :) > I mean, it’s not a popularity contest :) It’s a question of what information is available to the folks ultimately deciding things. If there is information being overlooked, if there are facts worth considering, this is the time to bring it up. Conclusions will ultimately be decided by those trusting these certificates, but that’s why it’s important to introduce any new information that may have been overlooked. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On 6/7/2020 9:47 π.μ., Ryan Sleevi wrote: I can understand wanting to wait to see what others do first, but that’s not leadership. This is a security community, and it is expected to see and learn from others, which is equally good of proposing new things. I'm not sure what you mean by "leadership". Leadership for who? We Who is we here? HARICA? The CA Security Council? The affected CAs in private collaboration? It’s unclear which of the discussions taking place are being referenced here. HARICA. There was also an interesting observation that came up during a recent discussion. You mean when I dismissed this line of argument? :) Yep. You have dismissed it but others may have not. If no other voices are raised, then your argument prevails :) Dimitris. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Mon, Jul 6, 2020 at 1:12 AM Dimitris Zacharopoulos via dev-security-policy wrote: > Ryan's response on > https://bugzilla.mozilla.org/show_bug.cgi?id=1649939#c8 seems > unreasonably harsh (too much "bad faith" in affected CAs, even of these > CA Certificates were operated by the Root Operator). Then revoke within 7 days, as required. That’s a discussion with WISeKey, not HARIC, and HARICA needs to have its own incident report and be judged on it. I can understand wanting to wait to see what others do first, but that’s not leadership. The duty is on the CA to demonstrate nothing can go wrong and nothing has gone wrong. Unlike a certificate the CA “intended” as a responder, there is zero guarantee about the controls, unless and until the CA establishes the facts around such controls. The response to Pedro is based on Peter Bowen’s suggestion that controls are available, and uses those controls. As an ETSI-audited CA, I can understand why you might balk, because the same WebTrust controls aren’t available and the same assurance isn’t possible. The baseline assurance expectation is you will revoke in 7 days. That’s not unreasonable, that’s the promise you made the community you would do. It’s understandable that it turns out to be more difficult than you thought. You want more time to mitigate, to avoid disruption. As expected, you’re expected to file an incident report on that revocation delay, in addition to an incident report on the certificate profile issue that was already filed, that examines why you’re delaying, what you’re doing to correct that going forward, and your risk analysis. You need to establish that why and how nothing can go wrong: simply saying “it’s a CA key” or “trust us” surely can’t be seen as sufficient. There are auditable > events that auditors could check and attest to, if needed, for example > OCSP responder configuration changes or key signing operations, and > these events are kept/archived according to the Baseline Requirements > and the CA's CP/CPS. This attestation could be done during a "special > audit" (as described in the ETSI terminology) and possibly a > Point-In-Time audit (under WebTrust). This demonstrates a failed understanding about the level of assurance these audits provide. A Point in Time Audit doesn’t establish that nothing has gone wrong or will go wrong; just at a single instant, the configuration looks good enough. The very moment the auditors leave the CA can configure things to go wrong, and that assurance lost. I further believe you’re confusing this with an Agreed Upon Procedures report. In any event, the response to WISeKey is acknowledging a path forward relying on audits. The Relying Party bears all the risk in accepting such audits. The path you describe above, without any further modification, is just changing “trust us (to do it right)” to “trust our auditor”, which is just as risky. I outlined a path to “trust, but verify,” to allow some objective evaluation. Now it just seems like “we don’t like that either,” and this just recycled old proposals that are insufficient. Look, the burden is on the CA to demonstrate how nothing can go wrong or has gone wrong. This isn’t a one size fits all solution. If you have a specific proposal from HARICA, filing it, before the revocation deadline, where you show your work and describe your plan and timeline, is what’s expected. It’s the same expectation as before this incident and consistent with Ben’s message. But you have to demonstrate why, given the security concerns, this is acceptable, and “just trust us” can’t be remotely seen as reasonable. We Who is we here? HARICA? The CA Security Council? The affected CAs in private collaboration? It’s unclear which of the discussions taking place are being referenced here. If this extension was standardized, we would probably not be having this > issue right now. However, this entire topic demonstrates the necessity > to standardize the EKU existence in CA Certificates as constraints for > EKUs of leaf certificates. This is completely the *wrong* takeaway. Solving this, at the CABF level via profiles, would clearly resolve this. If the OCSPSigning EKU was prohibited from appearing with other EKUs, as proposed, this would have resolved it. There’s no guarantee that a hypothetical specification would have resolved this, since the ambiguity/issue is not with respect to the EKU in a CA cert, it’s whether or not the profile for an OCSP Responder is allowed to assert the CA bit. This *same* ambiguity also exists for TLS certs, and Mozilla has similar non-standard behavior here that prevents a CA cert from being a server cert unless it’s also self-signed. There was also an interesting observation that came up during a recent > discussion. You mean when I dismissed this line of argument? :) As mandated by RFC 5280 (4.2.1.12), EKUs are supposed to be > normative constrains to *end-entity Certificates*, not CA Certificates. > Should RFC 6960 need to
