[cabf_validation] Ballot Proposal: Validation Method in certificatePolicies

[Ryan Sleevi]

On Fri, Jun 8, 2018 at 8:42 AM, Wayne Thayer via Validation <
validation at cabforum.org> wrote:

> I have drafted a ballot that reflects my understanding of the outcome of
> the discussion on disclosing validation methods during the WG meeting on
> Tuesday. I have not attempted to tackle the issue of encoding validation
> methods in CAA records. Please take a look and respond with your comments.
> I'm also seeking two endorsers.
>
> - Wayne
> ===========================
> Ballot 226: Validation Method in certificatePolicies
>
> Purpose of Ballot: The methods defined in BR section 3.2.2.4 and 3.2.2.5
> to confirm control or ownership of each domain name or IP address placed in
> a TLS certificate have varying security properties. This ballot proposes a
> standard format for expressing the method(s) the CA used to validate domain
> control or ownership of the Authorization Domain Name(s) placed in a
> certificate, and requires conforming CAs to include this information in
> certificates issued on or after April 1, 2019. This information is useful
> when vulnerabilities in specific methods are identified, and disclosing it
> will benefit the PKI ecosystem.
>
> The following motion has been proposed by Wayne Thayer of Mozilla and
> endorsed by XXX of YYY and XXX of YYY.
>
> — MOTION BEGINS –
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” as follows, based upon Version
> 1.5.7:
>
> Add the following definitions to section 1.2:
>
> {joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140)
> certificate‐policies(1) baseline‐ requirements(2)
> domain-validation-methods(4)} (2.23.140.1.2.4).
> {joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140)
> certificate‐policies(1) baseline‐ requirements(2)
> IP-address-validation-methods(5)} (2.23.140.1.2.5).
>
> Update section 7.1.2.3(a), as follows:
>
> This extension MUST be present and SHOULD NOT be marked critical.
> certificatePolicies:policyIdentifier (Required)
> A Policy Identifier, defined by the issuing CA, that indicates a
> Certificate Policy asserting the issuing CA's adherence to and compliance
> with these Requirements.
>
> Required on or after 1-April, 2019: One or more Policy Identifiers that
> assert every distinct method performed by the CA to validate domain control
> or ownership of each FQDN contained in the subjectAlternativeName, in the
> following format:
> * 2.23.140.1.2.4. concatenated with the subsection number of section
> 3.2.2.4 corresponding to the domain validation method that was used to
> validate one or more subjectAlternativeNames in this certificate (e.g.
> 2.23.140.1.2.4.2'); or,
> * 2.23.140.1.2.5 concatenated with the subsection number of section
> 3.2.2.5 corresponding to the IP address validation method that was used to
> validate one or more subjectAlternativeNames in the certificate (e.g.
> '2.23.140.1.2.5.1').
>
> The following extensions MAY be present: certificatePolicies:
> policyQualifiers:policyQualifierId (Recommended)
> id-qt 1 [RFC 5280]. certificatePolicies:policyQualifiers:qualifier:cPSuri
> (Optional)
> HTTP URL for the Subordinate CA's Certification Practice Statement,
> Relying Party Agreement or other pointer to online information provided by
> the CA.
>
> — MOTION ENDS –
>

Would it make sense to host this on GitHub to allow for more streamlined
feedback?

Concrete feedback:
* The particular method chosen - in the certificatePolicies - can
potentially cause issues with validation software if the issuing
intermediate lacks those policies (as, presumably, every extant
intermediate will) or the anyPolicy OID.
* April 2019 - Could you explain the thinking about how this date was
selected? Previously, Mozilla required that CAs maintain accurate records
of how they validate such information in order to appropriately streamline
such a ballot. I'm curious how this date was chosen, compared to, say,
October 2018?
* The selection of the OID seems to be OK, although while double-checking,
it looks like based on https://cabforum.org/object-registry/ that not all
of our OIDs have been appropriately reflected. For example, the
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-EV-Guidelines-v1.6.8.pdf
EVGs assign 2.23.140.1.42 to cabf-applicantSigningNonce (or at least, that
was the intent; the syntax is incomplete.) We should review all documents
to make sure no one has 'unintentionally' explored those OIDs, and to make
sure our documentation is up to date regarding their assignment and
hierarchy.
* We should similarly update that OID registry to explicitly list each of
these OIDs are assigned. I presume this will include reserving OIDs for the
placeholder/deprecated methods

There's one bit of ambiguity for relying parties worth considering, which
is the difficulty in understanding 'which' version of the BRs were in force
when the information was validated - that is, considering both cached
validations and validations that occurred over the duration of information
gathering to certificate issuance.

One way to resolve this is to ensure that each and every one of the 'fixes'
proposed in the VWG to strengthen the existing methods be themselves
renumbered methods. That is, any time there is a change, even minor, the
existing validation method is removed and a new validation method is
introduced. That is, if we resolve 3.2.2.4.6 to provide further guidance to
avoid common HTTP implementation pitfalls, then we would deprecate .6 and
introduce .14 (for example)

Another way to potentially resolve this is to simply indicate the earliest
domain validation that was performed, as a GeneralizedTime, which certainly
indicates the 'oldest' validation a given certificate has had. This would
allow us to preserve the existing numbering (e.g. .6) even as it's
incrementally improved.

Another way to potentially resolve this is to indicate the document version
used. This too would allow the preservation of the existing numbering, and
would allow specification by document rather than by validation date, which
I imagine some CAs would prefer.

Each of these methods represents possible paths to disambiguate the policy,
the latter two offering ways to preserve the existing numbering schemes.
Given the many excellent and necessary improvements that the VWG identified
during the Virginia validation summit, it seems we should at least
anticipate and prepare for this case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180608/37c344ee/attachment.html>