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

[Wayne Thayer]

On Fri, Aug 31, 2018 at 9:21 AM Ryan Sleevi <sleevi at google.com> wrote:

>
>
> On Fri, Aug 31, 2018 at 12:10 PM Wayne Thayer <wthayer at mozilla.com> wrote:
>
>> But aren't these distinct organizations?
>>>
>> >
>> In what sense? Certainly in the physical world they are the same.
>>
>
> In the information being reported in the certificate. Obviously, this is
> more a matter of OV/EV than DV, but the argument here is that such
> information is meaningful and 'guaranteed' to refer to the correct legal
> entity, while at the same time, if the legal entity renames itself, the
> ability to determine 'which' legal entity is being referred to, at some
> later point, is no longer possible.
>
> This gets to the heart of the matter of certificates, though, and I'm
> willing to pass it to a second ballot, but I don't think I'm willing to let
> it go entirely. If a certificate is a statement that, "At this point in
> time, the entity named Go Daddy was affiliated with this key and this
> domain," then I agree, if the entity renames themselves "GoDaddy", there's
> no need to revoke the certificate - because it's a statement made at the
> time of issuance.
>
> However, if a certificate is a statement that "At this time, and for the
> remainder of the validity period, an entity named Go Daddy is affiliated
> with this key and this domain" (that is, changing the past-tense
> point-in-time statement to a present-tense, ongoing statement), then it's a
> material change if the entity has renamed themselves GoDaddy. That's
> because if I were to look for a business entity named Go Daddy at the point
> I'm relying on the certificate, I would not find it, or I would find a
> potentially different entity, because they've since renamed themselves
> GoDaddy.
>
> I'm much more a believer that a certificate is a statement about a point
> in time, but I realize the BRs try to argue both ways - by virtue of this
> section (and, seemingly, this section alone) - which is why it caught my
> attention when re-reviewing.
>
>
I agree that this is worthy of more discussion that can lead to
clarification in a future ballot.
>

>
> 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.
>>>>
>>>
>>> Although there's currently no trigger for the duration between the CA
>>> being made aware of such information and making a determination. For
>>> example, if a problem report arrives with inaccurate information, the CA
>>> may take two weeks to make such a determination, and upon making a
>>> determination, decide to revoke. They might, as part of both their
>>> preliminary and final report, note that they have not yet determined that
>>> the information is inaccurate.
>>>
>> >
>> I see your point, but it assumes that a CA can 'be made aware that any
>> of the information appearing in the Certificate is inaccurate' without
>> triggering reason #6 ('made aware of a material change in the
>> information contained in the Certificate'), which seems unlikely. My
>> concern with your proposal is that a CA could interpret "is made aware of"
>> as only applying when a 3rd party reports a problem. Would a change to
>> 'determines or is made aware of' resolve both concerns?
>>
>
> Sure. I think my concern with just a 'made aware of', in your example
> above, is that the CA would argue there hasn't been a material change in
> the information, because the information was always inaccurate (in the
> certificate). I realize that's a tortured reading, but the responses to CA
> post-mortems and CT log post-mortems suggest that we really do have to
> apply tortured readings to produce the desired result. The goal I think
> we're in agreement on - which is that if a CA makes a mistake, whether
> they're notified of it or they determine it themselves, they're obligated
> to act.
>
>
Here's the change:
https://github.com/wthayer/documents/commit/be38c68b71f8fd5b3a1ada11a463d55805d21b02

With this, I think your concerns have been addressed, so I'm going to go
ahead and publish version 3.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180831/845f488c/attachment-0002.html>