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

[Ryan Sleevi]

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.

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