[Servercert-wg] Discussion Begins: Ballot SC24: Fall Cleanup

[Ryan Sleevi]

On Thu, Oct 24, 2019 at 2:43 PM Wayne Thayer <wthayer at mozilla.com> wrote:

> On Thu, Oct 24, 2019 at 8:23 AM Ryan Sleevi <sleevi at google.com> wrote:
>
>> Wayne, do these work for you? I'll happily make the change (and also open
>> a proper PR for the draft ballot, into the CABF repo, to make sure it's got
>> a stable ID)
>>
>> On Thu, Oct 24, 2019 at 10:47 AM Tim Hollebeek <
>> tim.hollebeek at digicert.com> wrote:
>>
>>> Yes, I’m fine with:
>>>
>>> “Test Certificate: This term is no longer used in these Baseline
>>> Requirements.”
>>>
>>
>> This works for me.
>>
>> Wayne, does this meet your goal of providing a sign-post? Did you want to
>> suggest something stronger?
>>
>
> I disagree, for the reasons stated earlier, that my proposed language for
> Test Certificate goes beyond the scope of a cleanup ballot. I also feel
> that it provides better guidance to CAs. However, for the sake of getting
> this ballot done I'll accept Tim's proposal.
>

Agreed on the disagreement with Tim, but the interest in being done with
this :)


> On the SHA-1 requirement in 7.1.3, let me propose some text which might
>>> make the issue clearer:
>>>
>>> “CAs MUST NOT issue any Subscriber certificates or new Subordinate CA
>>> certificates using the SHA-1 hash algorithm.  This Section 7.1.3 does not
>>> apply to Root CA or CA cross certificates. CAs MAY continue to use their
>>> existing SHA-1 Root Certificates. Subscriber certificates SHOULD NOT chain
>>> up to a SHA-1 Subordinate CA Certificate.”
>>>
>>
>> As noted on today's validation call, I think we're in agreement that this
>> opens the door for possible messiness (c.f. the recent discussions around
>> what a "cross certificate" is - both in the BR sense and the 5280 sense),
>> but it sounds like the plan is to have a separate ballot to close that.
>> While I'm not thrilled (since the cleanup ballot does include other
>> normative changes that better clarify intent, which I think this would be),
>> I'm on board with tackling this as a ballot immediately after. In terms of
>> sequencing/timing, and in deference to Jos' hard work on a markdown
>> cleanup, I think we could sequence such a follow-up ballot to be based on
>> his work, so that he doesn't have to account for it in his ballot.
>>
>> Wayne, Jacob: Are you OK with adopting the above language? If so, I can
>> make the change.
>>
>
> Yes, I accept this change.
>

In writing this up, I realized the potential confusion that can result from
Tim's wording here. I attempted a slight adjustment in
https://github.com/sleevi/cabforum-docs/compare/2019-07-Cleanups...sleevi:2019-07-TimsConcerns
-
again, not happy with it, but trying to make progress and appease the
concerns. If that looks right to folks, I'll merge it.

Here's the "unreasonable" loophole that I think fits within the scope of a
cleanup ballot, which the above tries to close, and I hope to all that is
holy no CA would try to argue is a normative change:
- A CA may read this as "IF I have a Cross Certificate issued, THEN I MAY
issue SHA-1 Subscriber certificates".

The 'intent', however unfortunate, of the existing 7.1.3 was that the "This
section" means that Root CAs may issue Subordinate CA Certificates that are
Cross Certificates using SHA-1. That is "This prohibition on issuing
Subordinate CA Certificates does not apply if the Subordinate CA
Certificate is a Cross Certificate". That's what the above language is
trying to preserve, while avoiding ambiguity that it might be seen as a
blanket allowance for SHA-1 issuance (which multiple root programs
categorically forbid), by reading it as "There are no restrictions on SHA-1
issuance, if your issuing CA is a cross certificate"

Hopefully this still works for everyone. If there's still concerns, my
suggestion is we simply restore the original, blanket prohibition, which
aligns with Root Program requirements, and let voting sort it out. The fact
that it is forbidden by multiple root programs means there's clearly no
need for a phase out of that language, which is the only reason someone
should object.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191024/dd3aa513/attachment.html>