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