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