[cabf_validation] Draft Ballot to Remove IP "Any Other Method" Validation (SC7)

Wayne Thayer wthayer at mozilla.com
Thu Jan 3 11:30:49 MST 2019


I've updated the draft ballot based on this morning's discussion. Please
review and comment here or in the doc:

https://docs.google.com/document/d/1rPXeT1XzviTHP9YrOwfBoYWIcE_dXUFoxI6yp6t9zjY/edit?usp=sharing

Thanks,

Wayne

On Wed, Jan 2, 2019 at 1:36 PM Wayne Thayer <wthayer at mozilla.com> wrote:

> Thanks Ryan. These seem like good topics for tomorrow's call.
>
> On Wed, Dec 26, 2018 at 8:32 AM Ryan Sleevi <sleevi at google.com> wrote:
>
>> Thanks Wayne,
>>
>> I added some comments to the doc, but since they might capture more than
>> just a thread-in-docs, I wanted to echo two thornier questions. I'm sorry
>> if I missed these being answered on the call, as I had a conflicting
>> appointment.
>>
>> 1) This proposal deviates from 3.2.2.4, in that as proposed, it does not
>> require validation of nameConstraints' permittedSubtrees for iPAddresses,
>> whereas 3.2.2.4 does require the validation for dNSName permittedSubtrees.
>> I think it's also attempting to provide a valuable clarification (namely,
>> just because it's nameConstrained doesn't mean it doesn't need to be
>> validated), but I'm curious the motivation to removing the validation
>> requirement for subCAs.
>>
>> As best I can tell this is an artifact of the original ballot that (I
> think) Jeremy drafted years ago. It may be that the 3.2.2.4 language was
> changed and this was never updated to mirror it. If we apply this language
> only to excludedSubtrees, then it's consistent with section 7.1.5.
>
> 2) An OV-level requirement was added, but without clear value or reason.
>> In particular, it seems to (intentionally?) preclude the use of contact
>> emails as provided by the RIR (with example given on the doc using 8.8.8.8
>> via ARIN)
>>
>> I think, for this second point, it would be a far stronger validation
>> requirement to entirely remove the notion of "OV-equivalent" vetting, and
>> instead require explicit use of contact information provided by the RIR,
>> given that the RIR doesn't provide unambiguous incorporation information
>> necessary to provide that presumed OV linkage. Concretely: Making 3.2.2.5.2
>> about contact to the RIR-provided details, rather than by saying "Eh, looks
>> close enough".
>>
>> Since this method appears to mirror the now-deprecated 3.2.2.4.1, I agree
> that we should update it rather than describing an existing insecure method
> in this ballot.
>
> On Fri, Dec 21, 2018 at 4:59 PM Wayne Thayer via Validation <
>> validation at cabforum.org> wrote:
>>
>>> As discussed on yesterday's call, I'd like to get ballot SC7 moving
>>> again. Here is a link to an updated draft of the ballot:
>>>
>>>
>>> https://docs.google.com/document/d/1rPXeT1XzviTHP9YrOwfBoYWIcE_dXUFoxI6yp6t9zjY/edit?usp=sharing
>>>
>>> There are a few comments there that we can discuss on the next call -
>>> feel free to add more.
>>>
>>> Thanks,
>>>
>>> Wayne
>>> _______________________________________________
>>> Validation mailing list
>>> Validation at cabforum.org
>>> https://cabforum.org/mailman/listinfo/validation
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190103/88560dfc/attachment.html>


More information about the Validation mailing list