[Servercert-wg] Draft Ballot for Cleanups

[Ryan Sleevi]

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/e7dcabf7/attachment.html>