Re: CPS URLs

[Nick Lamb via dev-security-policy]

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

[Matthias van de Meent via dev-security-policy]

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

[Ryan Sleevi via dev-security-policy]

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