[cabf_validation] Ballot Proposal: Validation Method in certificatePolicies

[Wayne Thayer]

On Fri, Jun 8, 2018 at 1:12 PM Ryan Sleevi <sleevi at google.com> wrote:

>
> Would it make sense to host this on GitHub to allow for more streamlined
> feedback?
>
>
https://github.com/wthayer/documents/blob/Ballot226/docs/BR.md
>

> 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.
>
>
Given your experience with this type of issue, do you have a sense for how
practical this concern is? Any thoughts on how to address it? If it's an
RFC violation and validation software is/will enforce having all of those
policies listed in the intermediate (or anyPolicy), then I don't think this
proposal is viable.
>

> * 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?
>
>
You are aware of the 6-month precedent for changes of this nature that
requires CA software updates (and possible updated from CA software
vendors). Should this ballot proceed, 6 months would be roughly Jan 1,
2019, but there is also precedent for moving changes away from end-of-year
to April 1st. As the proposer, I would rather see this ballot move forward
than get bogged down in debates over timing.
>

> * 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
>
>
This is a good point. Please correct me on this, but I don't believe that
updating the OID registry needs to be done via ballot.
>

> 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)
>
>
There may be some disagreement over which changes are significant enough to
trigger a new version number, but otherwise I believe this is the agreed
upon approach. I would expect .6 to be renumbered in the example you
described.
>

> 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.
>
>
How would this approach work under the current proposal for using the
certificatePolicies extension?
>

> 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.
>
>
As discussed before requiring CAs to log validation method used, this
approach suffers from a number of practical challenges.
>

> 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.
>
>
We've had a fair amount of debate on this and settled on the approach of
changing the method number when any material modifications are made to a
validation method. I would prefer a different approach, but that is what we
chose, so this proposal adopts it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180609/9abb33f6/attachment.html>