[Servercert-wg] Draft Ballot for Cleanups

[Ryan Sleevi]

https://github.com/sleevi/cabforum-docs/commit/6be18da957b6c26113179e0feef5fff4e1e09d29

On Thu, Oct 17, 2019 at 7:58 PM Ryan Sleevi <sleevi at google.com> wrote:

>
>
> On Thu, Oct 17, 2019 at 7:41 PM Wayne Thayer via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>> On Thu, Oct 17, 2019 at 4:34 PM Ryan Sleevi via Servercert-wg <
>> servercert-wg at cabforum.org> wrote:
>>
>>>
>>> On Thu, Oct 17, 2019 at 7:25 PM Wayne Thayer via Servercert-wg <
>>> servercert-wg at cabforum.org> wrote:
>>>
>>>> On Thu, Oct 17, 2019 at 4:10 PM Ryan Sleevi via Servercert-wg <
>>>> servercert-wg at cabforum.org> wrote:
>>>>
>>>>>
>>>>> On Thu, Oct 17, 2019 at 5:45 PM Wayne Thayer via Servercert-wg <
>>>>> servercert-wg at cabforum.org> wrote:
>>>>>
>>>>>> On this morning's call I volunteered to convert this into a ballot
>>>>>> and get the review period started. I am, however, concerned by the lack of
>>>>>> discussion on the questions posed by Ryan - my comments are below. Will
>>>>>> everyone please take a look at these this week? Some of these corrections
>>>>>> and clarifications are long overdue.
>>>>>>
>>>>>>
>>>>>> https://github.com/cabforum/documents/compare/master...sleevi:2019-07-Cleanups
>>>>>>
>>>>>>>
>>>>>>>    - Correct the authorized port descriptive label (http -> https)
>>>>>>>    - Correct a few typos (contract -> contact, assigns -> assignees)
>>>>>>>    - Clarify the Request Token should be documented in the CP/CPS
>>>>>>>    (or a document referenced from the CP/CPS)
>>>>>>>       - One potential area of confusion is if folks read it as
>>>>>>>       permitting a private/internal only document. I wanted to correct this to
>>>>>>>       say "publicly-available document", but thought it best to check in with
>>>>>>>       folks on this to see if there were objections. I'll take silence as assent
>>>>>>>
>>>>>>>
>>>>>> I believe that the code that creates a request token would meet the
>>>>>> current requirement, and most, if not all CAs will need to update their
>>>>>> CP/CPS to meet this requirement. This seems like more than a cleanup item
>>>>>> to me.
>>>>>>
>>>>>
>>>>> Note: This was a proposed change that was not included. It was
>>>>> highlighting a possible opportunity for clarity, but if folks felt that it
>>>>> was actually changing a requirement, we could defer it. That's why I didn't
>>>>> include it, but called attention to it here as a possible opportunity.
>>>>>
>>>>> The existing text, which is "The CA should define in its CPS (or in a
>>>>> document referenced from the CPS) the format of Request Tokens it accepts."
>>>>> is preserved - you can see in the diff it simply moved from 3.2.2.4.6 to
>>>>> the definition of Request Token itself.
>>>>>
>>>>>
>>>> The new language drops the "should" that, from spot checking a few
>>>> CP/CPS', looks to be rather important.
>>>>
>>>> I was highlighting the issue that it means a CA may publicly document
>>>>> (e.g. within the CPS), or they may fulfill the letter of the requirement
>>>>> ("a document clearly referenced from the CP/CPS") without the spirit (which
>>>>> is to ensure it's documented). If everyone is making use of the CPS
>>>>> approach, then this is not an issue. If people aren't documenting in their
>>>>> CP/CPS, then they're already non-compliant.
>>>>>
>>>>>
>>>> That's not how I read the "should".
>>>>
>>>
>>> Fair enough.
>>>
>>> Do you think the following edit would match the original language, while
>>> making it clearer (i.e. not buried in 3.2.2.4.6)?
>>>
>>> **Request Token**: A value derived in a method specified by the CA which
>>> binds this demonstration of control to the certificate request. The CA
>>> SHOULD define in its CPS (or a publicly-available document referenced from
>>> the CPS) the format of Request Tokens it accepts.
>>>
>>> This adds the 'publicly-available', and elevates it to a 2119-level
>>> SHOULD, but doesn't make it a normative requirement yet, which can be
>>> tackled in a separate ballot with a phase-in for CP/CPS updates or via root
>>> store communications (e.g. to have the CA document the format in answer to
>>> a question, much like we saw with problem-reporting information prior to
>>> being mandatory)
>>>
>>>
>> I'm satisfied with this change. It serves the purpose of this cleanup
>> ballot.
>>
>> In general, I don't think placing requirements in definitions improves
>> clarity.
>>
>
> Understood. While that snippet was only for the relevant text, note that
> the rest of the definition is already a long-list of requirements for a
> Request Token. The only substantive change that will result (after the
> above change) is that the illustrative example of what is an acceptable way
> of constructing a token, as well as the documentation requirement, are
> moved in line with the rest of the requirements, rather than split between
> definition and section.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191017/8e7756a1/attachment.html>