On Mon, Jul 6, 2020 at 1:22 PM Matthias van de Meent via dev-security-policy <dev-security-policy@lists.mozilla.org> 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
