[Servercert-wg] Draft Ballot for Cleanups

[Ryan Sleevi]

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.

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.

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