[cabf_validation] Minutes from the meeting of 2 August 2018

[Wayne Thayer]

On Fri, Aug 10, 2018 at 7:35 AM Ryan Sleevi <sleevi at google.com> wrote:

>
> On Thu, Aug 9, 2018 at 5:28 PM Wayne Thayer <wthayer at mozilla.com> wrote:
>
>
>> Doug: I also agree, but we don’t know what browsers will do with this
>>>> information, so we have to assume that browsers will use it to make trust
>>>> decisions.
>>>> Wayne: I view this as information, not a way to enforce policies, and
>>>> this discussion makes the case for that.
>>>> Doug: Can the intent be part of the ballot?
>>>> Wayne: Requirements can’t really describe intent, but I’d be happy to
>>>> add that to the introductory language of the ballot.
>>>> Tim: Another question is the ability to describe which sub-methods were
>>>> used
>>>> Wayne: the ballot expresses the current scheme of describing methods,
>>>> so that scheme would need to change first. In the current scheme, we should
>>>> break a method with N sub methods into N new methods.
>>>> Tim: I agree. Another concern is with CAA, where constantly changing
>>>> method numbers could cause problems when certificates are renewed
>>>> Bruce: I don’t see method numbers constantly changing once we get
>>>> through our review of all the methods. Agree that method 2 should be 3
>>>> methods.
>>>> Doug: Method 2 could really be 9 methods. Or we could have one method
>>>> for all flavors of phone validation, for instance. We need to decide if we
>>>> want to make methods more granular. Not convinced it’s worth turning one
>>>> method into 9.
>>>> Corey: If we don’t make things more granular, there isn’t enough value
>>>> in encoding the method into the cert. The OID for the old and new method 10
>>>> would be the same.
>>>> Tim: Method 10 is a problem child. It needs to be fixed.
>>>>
>>>
>>> Aren't any issues with this resolved by indicating the earliest of the
>>> validation that occurred?
>>>
>>
>> I'm not following - please explain your thinking.
>>
>
> Sure. I think we have to work back to understand the goals. Certainly, a
> goal is to enable relying parties - not just browsers - to make effective
> trust decisions. This is the same argument that CAs make for adding OV/EV
> information, despite the fact that the rely on a human validating rather
> than a machine. If we accept that is at least one premise, then the
> argument for including the potential sub-methods of validating is because
> not all sub-methods provide the same level of assurance, and we believe
> that expressing those differing levels of assurance is worthwhile.
>
> One approach to acknowledging that a given method - say, phone - provides
> differing levels of assurance is, as noted, to break the given method into
> each method that provides a distinct and different level of assurance. We
> might have "phone to named officer" and "phone based on DNS" or some other
> arbitrary and made-up scheme where we think differing levels of assurance
> are provided.
>
> Another approach is to acknowledge that we don't really care about the
> incremental improvement to the levels of assurance between a given
> validation method, but what we do care is whether or not a given sub-method
> provides adequate assurance, for some value of adequate. In this approach,
> if a given sub-method no longer provides adequate levels of assurance, we'd
> expect to see it removed from the BRs as an option. Even if we kept the
> same numbering for the overall method (e.g. ".6"), whether or not the level
> of assurance was adequate can be determined based on whether it was "old
> .6" or "new .6", which can be evaluated based on when the validation itself
> was performed. Alternatively, of course, if we removed .6 sub-method 3
> (using made up numbers here), we might also decide that .6 is deprecated,
> and the new hotness is .16 (which is .6 with sub-methods 1 and 2). That
> equally helps determine where the 'floor' was for the level of assurance.
>

If I'm understanding you correctly, you're suggesting that the date a
domain/IP address validation is performed can be used as a versioning
mechanism and thus we should consider including that information in the
certificate. The question of how best to version validation methods keeps
coming up, and if we are going to change it from the status quo (new
version == new method number), then let's do it now before we begin
requiring this information be included in a certificate. Having said that,
I think the use of dates to identify versions of validation methods is a
poor approach. It's an assumption rather than an assertion. Assuming that
we end up using OIDs to encode the validation methods, I would recommend we
encode method versions in the OID as 'OID ARC'.'method number'.'version
number'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180810/1de5a2ba/attachment.html>