[Servercert-wg] [EXTERNAL] Fwd: Data Reuse under BR 3.2.2.4.3 (Phone Contact with Domain Contact)

[Ben Wilson]

I guess there is no disagreement, it's just that you're focusing on the
time/duration that there is stale information for relying parties.  I'm
focusing on the cutoff date by which a CA could reuse the information. I
agree that for 1650 days  relying parties have stale information, but I was
focusing on when it would be bad for a CA to rely on that stale information
to issue a certificate, which is 825 days, and if I add 825 days to May 31,
2019, I arrive at a date around Aug. 20, 2021 +/- a day.

On Tue, Apr 21, 2020 at 3:13 PM Ryan Sleevi <sleevi at google.com> wrote:

> Ben: I'm not sure I understand your comment. It sounds like you're
> disagreeing with a statement either Bruce or I made, but it's not clear.
>
> If you're replying to
> https://cabforum.org/pipermail/servercert-wg/2020-April/001853.html ,
> then this is simple and has been plenty discussed in the past
>
> At T(ime)=0, a CA validates the cert. At T=825, they reuse that
> information and issue a cert whose L(ifetime) = 825. That means that, until
> T=1651, you cannot be sure that there are no certificates that don't reuse
> that information from T=0 exist and are still valid / unexpired. At a
> minimum, the time for which "information validated using a weak validation
> method" will exist in the ecosystem is (reuse period + maximum lifetime).
>
> This is, unfortunately for security, intentional to the BRs design, and
> which correcting has unfortunately faced opposition. The BRs treat "reuse"
> as a statement about issuance, rather than a statement about the
> information being asserted. Because of this, you will always have an
> asymmetry between "How long a CA uses the information" (825 days) and "How
> long a relying party is relying on this information" (825 + 825 = 1650
> days). So when you talk about "reuse", it's important to try and clarify
> which you're trying to address.
>
> SC22 would have fixed this, and tried to close these loopholes. It
> unfortunately failed.
>
> On Tue, Apr 21, 2020 at 12:30 PM Ben Wilson <bwilson at mozilla.com> wrote:
>
>> I still think that re-use time periods run from the time the information
>> is verified and not from the expiration of the certificate for which the
>> validation method was used.
>>
>>
>> On Tue, Apr 21, 2020 at 10:13 AM Ryan Sleevi <sleevi at google.com> wrote:
>>
>>>
>>>
>>> On Tue, Apr 21, 2020 at 11:59 AM Bruce Morton via Servercert-wg <
>>> servercert-wg at cabforum.org> wrote:
>>>
>>>> Ben,
>>>>
>>>>
>>>>
>>>> This be 825 days if used for OV/DV certificates and 13 months if used
>>>> for EV certificates. So the date for EV would be 30 June 2020.
>>>>
>>>
>>> Is that correct? I mean, I do appreciate the reading, but I'm concerned
>>> it overlooks many of the security holes that were unfortunately
>>> intentionally added to EV certificates and which CAs rejected fixing:
>>>
>>> The statement is in 11.14.3 (1) is:
>>> "Except for reissuance of an EV Certificate under Section 11.14.2 and
>>> except when permitted otherwise in Section 11.14.1, "
>>>
>>>  along with 11.14.3 (4):
>>>
>>> "(4) The CA MUST repeat the verification process required in these
>>> Guidelines for any information obtained outside the time limits specified
>>> above except when permitted otherwise under section 11.14.1."
>>>
>>> 11.14.1 permits the CA to continue to use a previous domain validation
>>> indefinitely, by virtue of 11.14.1 (7):
>>> "The Applicant's right to use the specified Domain Name under Section
>>> 11.7, provided that the CA verifies that the WHOIS record still shows the
>>> same registrant as when the CA verified the specified Domain Name for the
>>> initial EV Certificate."
>>>
>>> This would suggest (and some CAs have interpreted it) as allowing
>>> indefinite validation, by validating once and then simply relying on WHOIS
>>> not to change. This is not really compatible with the BRs, for sure, and
>>> the EVGs don't trump the BRs, but at least internally to the EVGs, these
>>> sections do trump the EVGs limits on data reuse, intentionally and
>>> explicitly, unfortunately.
>>>
>>> You might recall that this was something that Google tried to clarify in
>>> SC22, to reduce this conflict and confusion. We're happy to propose similar
>>> language now to address.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200421/5ff8beae/attachment.html>