[Servercert-wg] Draft Ballot for Cleanups

[Wayne Thayer]

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".

So I wasn't sure if there were any CAs that made use of 3.2.2.4.6,
> documented it in another document, clearly referenced that document in
> their CP/CPS, but did not make that clearly-referenced document publicly
> available. However, because they might exist, even though that's
> undesirable, I didn't include the change.
>
>
>>
>>
>>>
>>>    - Moved the construction examples of a Request Token to the
>>>    definition of a Request Token
>>>    - Removed the term Test Certificate, as it is no longer used in the
>>>    BRs
>>>       - I'm a little mixed on this change. It's a term no longer used
>>>       by the BRs, and so it makes sense to delete from the BRs. However, I worry
>>>       that it might lead CAs to inventing their own definition of what a "test
>>>       certificate" is (under the premise of Default-Allow vs Default-Deny).
>>>       - An alternative, which if we want to pursue I suspect would be a
>>>       separate ballot that aligns the BRs with existing Root Program requirements
>>>       (which I'll be sharing shortly), is to remove (i) which is forbidden by
>>>       Mozilla since 2016, and only leave the definition (ii) in.
>>>
>>>
>> I prefer the alternative of leaving (ii) so that Test Certificate is
>> defined as "A Certificate which is issued under a CA where there are no
>> certificate paths/chains to a root certificate subject to these
>> Requirements." I'd prefer to add "...a root certificate that is or will
>> someday be subject to these Requirements.", but I feel that would also go
>> beyond the scope of a "cleanup" ballot.
>>
>
> Sure. That's an easy change and I am more than happy to go edit that in.
>
> Happy to endorse a ballot here if you're able to shepherd it through the
> Bylaws process.
>
>
Thanks, I'll put you down as an endorser.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191017/f60a2d2b/attachment.html>