[Servercert-wg] [EXTERNAL] Ballot SC6 v2 - Revocation Timeline Extension

[Wayne Thayer]

On Thu, Aug 30, 2018 at 10:42 AM Ryan Sleevi <sleevi at google.com> wrote:

> Thanks Wayne.
>
> I know you're intentionally avoiding the controversial cleanups with this
> specific Ballot, so it will be good to have a follow-on discussion for
> those matters, as CAs will no doubt having to make only one update to their
> CP/CPS versus two. Or, differently stated, I'd hope that the argument for
> making two updates doesn't preclude discussion of those additional cleanups
> and ambiguities.
>
> In reviewing this language in full, a much needed cleanup, one area that
> stuck out to me, and which may not need to be resolved, but worth
> considering, are the requirements for revocation if the CA is "made aware
> of a material change in the information contained in the certificate" (#6
> in the 5 day range) and if the CA "determines that any of the information
> appearing in the Certificate is inaccurate"
>
> One thing that stuck out was "made aware" versus "determines" - and
> whether that distinction is significant (all of the other relevant language
> in this section uses "made aware"). This is, admittedly, a carry over, but
> I'm curious if there is any significance/impact to changing this to "made
> aware"
>
> The next thing that stuck out is determining whether "material change in
> the information" and "is inaccurate" are, in fact, different. Are there
> cases where the information is inaccurate due to an (immaterial) change?
> Are there material changes that don't result in inaccuracy? This couples
> with the above to leave it a bit messy and gray as to how the CA may
> classify things.
>
> In looking at Section 9.6.1, regarding the CA's warranties, it seems our
> goal is to provide relying parties both assertions on the correctness of
> the information at the time it was issued, as well as that the information
> is correct on an ongoing basis (c.f. 9.6.1 (8)). In terms of predictability
> and clear expectations for CAs, the determination of material/immaterial,
> and the flexibility for determination in general, seems to set up potential
> conflict with the needs of Relying Parties and Subscribers, and leave CAs
> in a bit of the messy place that some of this ballot tries to get them
> sorted out from.
>
>
> I hope this will prove to be uncontroversial, but the concrete suggestions
> I would have are:
> 1) Strike "material" from 4.9.1.1, p2, Item 6, to read "The CA is made
> aware of a change in the information contained in the certificate"
>
>
I suspect that this is controversial and am not sure that I agree with the
proposed change. For example, when GoDaddy removed the space from their
former name "Go Daddy", that would, in my opinion, have been an immaterial
change to the content of any certificate containing "Go Daddy" in the O
field. Other examples might include capitalization and punctuation. While I
dislike ambiguities and the abuse they invite, this is a case where I think
it is acceptable, if not necessary.
>

> 2) Change "determines" to "is made aware" in 4.9.1.1, p2, Item 8, to read
> "The CA is made aware that any of the information appearing in the
> Certificate is inaccurate."
>
>
I don't have strong feelings about this, but I do make some distinction
between "determining" (on its own) and "being made aware of" (by someone
else). I prefer the current language because it makes some admittedly minor
distinction between these two reasons.
>

>
> This leaves both 6 and 8, with the intent that Item 8 is meant to capture
> if the CA made a mistake "at time of issuance" (c.f. Section 9.6.1's
> warranties the CA makes "at the time of issuance"), and Item 6 is meant to
> convey the ongoing requirement for the accuracy of information (c.f.
> 9.6.1's Item 8 and the objective of 9.6.3's requirements on the Subscriber
> to request changes). That is, this Item 6 captures if the Subscriber fails
> to meet their ongoing obligations, and the Item 8 captures if the CA failed
> to meet their initial obligations.
>
> Does that sound like a reasonable (and hopefully uncontroversial) tweak?
> If not, then I think it may merit discussing in a separate follow-up
> ballot, to address the other areas of ambiguity, confusion, or
> arbitrariness :)
>
>
> On Wed, Aug 29, 2018 at 1:19 PM Wayne Thayer <wthayer at mozilla.com> wrote:
>
>>
>> On Wed, Aug 29, 2018 at 9:05 AM Ryan Sleevi <sleevi at google.com> wrote:
>>
>>>
>>>
>>> On Wed, Aug 29, 2018 at 11:53 AM Wayne Thayer <wthayer at mozilla.com>
>>> wrote:
>>>
>>>> On Wed, Aug 29, 2018 at 7:33 AM Bruce Morton <
>>>> Bruce.Morton at entrustdatacard.com> wrote:
>>>>
>>>>> Works for me.
>>>>>
>>>>> Bruce.
>>>>>
>>>>> On Aug 29, 2018, at 10:29 AM, Ryan Sleevi <sleevi at google.com> wrote:
>>>>>
>>>>> Just to confirm: Your concern is about the CA feeling that the
>>>>> evidence does not meet any of the requirements to revoke, and wanting it to
>>>>> be clear that that is a valid outcome of a problem report, correct?
>>>>>
>>>>> The problem with the suggested wording (and perhaps implicit in the
>>>>> existing wording) is that it suggests that the period to "work with the
>>>>> Subscriber and any entity" is unbounded, and once a determination is made,
>>>>> then it must be within the bounds of 4.9.1.1's time period. That is, say,
>>>>> 24 hours + as much "work with" time as you want. This is because the
>>>>> modified wording seemingly attaches the "which MUST not" to the date in
>>>>> which the CA will revoke, rather than the overall process.
>>>>>
>>>>> The CA SHALL work with the Subscriber and any entity reporting the
>>>>> Certificate Problem Report or other revocation-related notice to establish
>>>>> whether or not the certificate will be revoked, and if so, a date which the
>>>>> CA will revoke the certificate. The period from report to published
>>>>> revocation MUST NOT exceed the time frame set forth in Section 4.9.1.1.
>>>>>
>>>>> >
>>>> Does "report" here mean the preliminary report on its findings, or the
>>>> Certificate Problem Report? I am happy to accept this change once that is
>>>> clarified.
>>>>
>>>
>>> I was thinking about that on the drive in today :)
>>>
>>> "The period from receipt of report or notice to published revocation" ?
>>>
>>
>> I made it a bit more specific:
>> https://github.com/wthayer/documents/commit/570a80cc59cf8beb1b93ff817188f317ac2824c5
>>
>> The full set of proposed changes is still at
>> https://github.com/cabforum/documents/compare/master...wthayer:patch-1
>>
>> Looking to the current v1.9 of the bylaws for guidance, it appears that
>> the change to the discussion period approved in ballot 216 [1] was never
>> incorporated. The current bylaws state "The discussion period then shall
>> take place for at least seven but no more than 14 calendar days before
>> votes are cast. The proposer of the ballot will designate the length of the
>> discussion period, and each ballot shall clearly state the start and end
>> dates and times (including time zone) for both the discussion period and
>> the voting period." Based on this, I plan to redo this ballot.
>>
>> I'm assuming that the omission of the ballot 216 language in the new
>> bylaws was a mistake. I'll plan to submit a ballot to fix that.
>>
>> [1]
>> https://cabforum.org/2017/12/21/ballot-216-update-discussion-period-process/
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180830/161f9537/attachment.html>