[cabfpub] Preballot - Revised Ballot 190

[Ryan Sleevi]

On Wed, May 17, 2017 at 12:17 PM, Kirk Hall via Public <public at cabforum.org>
wrote:

> Jeremy, Gerv, and I have worked on this revised version of Ballot 190, and
> offer it for comment as a preballot.
>
> A few points to highlight.
>
> -          There is now a new fifth paragraph in the introductory part of
> BR 3.2.2.4 that requires CAs to maintain a record of which domain
> validation method they use (including version number) for each validated
> domain.  This is to add more flexibility in the future if methods must be
> changed and existing domains revalidated for some reason.
>
> -          The new sixth paragraph clarifies that domains validated prior
> to the effective date of Ballot 190 are not required to be revalidated, but
> the validation data can be reused for the periods specified in BR 4.2.1 and
> EVGL 11.14.3.
>
> -          We also have added a line to each validation method indicating
> whether or not the validation method is suitable for wildcard certificates.
>
In most specifications, certainly the majority of those related to the Web
Platform, "notes" are non-normative 'suggestions'. That is, they're not
even "SHOULD" level, to use RFC 2119 terminology - they're non-binding
clarifications of intent.

As such, it's unclear what the intended outcome of this is. Is it meant to
be binding on CAs? If so, we should look to be more explicit.

It's also unclear whether the 'intent' of the wildcard certificate was also
to encompass the validation of subdomains, or their use in Authorization
Domain Names.

As much as I think this is an exciting and worthwhile contribution, similar
to my recent remarks to Jeremy, I think there's substantial technical
detail and nuance to merit splitting out those changes.


> 7) Edit Section 3.2.2.4.6:
>
> *3.2.2.4.6 Agreed-Upon Change to Website*
>
> Confirming the Applicant's control over the requested FQDN by confirming *the
> presence of a Request Token or Random Value contained in the content of a
> file or on a web page in the form of a meta tag* one of the following under
> the "/.well‐known/pki‐validation" directory, or another path registered
> with IANA for the purpose of Domain Validation, on the Authorization Domain
> Name that is accessible by the CA via HTTP/HTTPS over an Authorized Port*.
> The Request Token or Random Value MUST NOT appear in the request for the
> file or web-page. * :
>
> 1. The presence of Required Website Content contained in the content of a
> file or on a web page in the form of a meta tag. The entire Required
> Website Content MUST NOT appear in the request used to retrieve the file or
> web page, or
>
> 2. The presence of the Request Token or Request Value contained in the
> content of a file or on a webpage in the form of a meta tag where the
> Request Token or Random Value MUST NOT appear in the request.
>
> If a Random Value is used, the CA or Delegated Third Party SHALL provide a
> Random Value unique to the certificate request and SHALL not use the Random
> Value after the longer of (i) 30 days or (ii) if the Applicant submitted
> the certificate request, the timeframe permitted for reuse of validated
> information relevant to the certificate (such as in Section 3.3.1 of these
> Guidelines or Section 11.14.3 of the EV Guidelines).
>
> Note: Examples of Request Tokens include, but are not limited to: (i) a
> hash of the public key; (ii) a hash of the Subject Public Key Info [X.509];
> and (iii) a hash of a PKCS#10 CSR. A Request Token may also be concatenated
> with a timestamp or other data. If a CA wanted to always use a hash of a
> PKCS#10 CSR as a Request Token and did not want to incorporate a timestamp
> and did want to allow certificate key re‐use then the applicant might use
> the challenge password in the creation of a CSR with OpenSSL to ensure
> uniqueness even if the subject and key are identical between subsequent
> requests. This simplistic shell command produces a Request Token which has
> a timestamp and a hash of a CSR. E.g. echo `date -u +%Y%m%d%H%M`
> `sha256sum <r2.csr` | sed "s/[ -]//g". The script outputs:
> 201602251811c9c863405fe7675a3988b97664ea6baf442019e4e52fa335
> f406f7c5f26cf14f
>
> The CA should define in its CPS (or in a document referenced from the CPS)
> the format of Request Tokens it accepts.
>
> *Note*: This method is suitable for validating domains for wildcard
> issuance.
>

Why is this permitted for wildcard, but IP are not?

Speaking from a security perspective, it goes
3.2.2.4.6 (Website) < 3.2.2.4.10 (Random Value) < 3.2.2.4.9 (Test Cert) <
3.2.2.4.8 (IP) < [everything else that follows]

As such, it would seem that if 3.2.2.4.8 is prohibited from wildcards, .6,
.9 and .10 should also be prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170517/c14d334e/attachment-0003.html>