[cabf_validation] Ballot Proposal: Validation Method in certificatePolicies

[Ryan Sleevi]

On Sat, Jun 9, 2018 at 4:27 PM, Wayne Thayer <wthayer at mozilla.com> wrote:

> 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.
>

An alternative is to express it as an extension, with the syntax as
SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER

There are other alternatives as well in this space, but as our ETSI friends
can attest, can lead to rather 'bloaty' certificates. For example, an
additional PolicyQualifierId could be described to indicate the validation
methods used, and whose content would use the above syntax. That is, the CA
would express the BR OID, and within it, have a PolicyQualifierInfo that
had a BR-validation-method OID, and within that qualifier field, have the
above sequence of methods used.

Personally, I find the extension approach would be less work for relying
parties, as it's easier to extract extension OIDs than it is to parse each
of the policies and qualifiers - which is further compounded by not every
CA using the BR OID - but we can plumb either path. Perhaps its worth
gathering feedback from the CA software vendors - I suspect the extension
approach may be easier for them to support integrating (since, in the worst
case, the CA could express it as raw DER), whereas policy qualifiers tend
to be more complex.


> >
>
>> * 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.
>

Thanks. I thought we'd settled on 3-month precedent, but in either event, I
appreciate the reasoning, as it helps capture why 'no sooner than' to avoid
that bog down :)


> >
>
>> * 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.
>

Correct. This is just webpage maintenance based on the documents. In the
future, I think the "Forum Infrastructure WG" would take this on and help
maintain it, to avoid WGs 'stomping' on eachother in assigning numbering -
much like IANA functions for the IETF.


> >
>
>> 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?
>

If we wanted to explore this, it's a slight change to my proposed syntax
above (whether extension or policyQualifier, it works the same), then
instead of
BRValidationInfo ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER

it becomes
BRValidationInfo ::= SEQUENCE {
  validationMethods     SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER,
  validationDate           GeneralizedTime
}



> >
>
>> 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.
>

OK. I had missed that this was the agreed-upon approach, but given that, I
think it does indeed make it easier to choose the first option (which this
draft effectively does), and the VWG and Forum should consistently err on
the side of renumbering simply to avoid any confusion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180609/710b8265/attachment-0001.html>