[Servercert-wg] Draft Ballot for Cleanups

[Ryan Sleevi]

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