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

[Ryan Sleevi]

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/b1a4bfe1/attachment.html>