[Servercert-wg] Draft Ballot for Cleanups

[Wayne Thayer]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191017/79bd0f70/attachment.html>