[cabfpub] Question around I&A information caching

Fri Apr 21 16:45:42 UTC 2017

Yes, that is the path I'm heading down.

I also noticed that in section 3.2.2.4 (Validation of Domain Authorization or Control), it mentions…

"The CA SHALL confirm that, *as of the date the Certificate issues*, either the CA or a Delegated Third Party has validated each Fully‐Qualified Domain Name (FQDN) listed in the Certificate…"

…which seems to imply that every cert issuance needs to recheck domain authorization/control. But, it then goes on to say…

"Completed confirmations of Applicant authority may be valid for the issuance of multiple certificates over time. In all cases, the confirmation must have been initiated within the time period specified in the relevant requirement (such as Section 3.3.1 of this document) prior to certificate issuance."

…which seems to imply that domain authorization/control can be cached along with the rest of the I&A data and reused for subsequent issuance. (I'll leave aside the fact that Section 3.3.1 is completely blank, yet is being referenced here)

Am I correct to assume that the tasks performed to demonstrate domain authorization/control are considered part of the same set of cacheable subscriber identity information and can thus be reused without revalidation as long as it's within the cache window? (I'm pretty sure the answer is yes, but it's conveyed in a bit of a confusing way, in my opinion)

Thanks,

-Alex

From: Ryan Sleevi <sleevi at google.com>
Date: Friday, April 21, 2017 at 10:26 AM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Alex Wight <awight at cisco.com>
Subject: Re: [cabfpub] Question around I&A information caching

On Fri, Apr 21, 2017 at 12:14 PM, Alex Wight (awight) via Public <public at cabforum.org> wrote:

Hi all,

  Please forgive me if this question is a bit naïve and perhaps something I should know already; Am I correct in assuming the following scenario is valid under the current BRs?

1.     Day 1 - CA gathers Identification and Authentication (I&A) information for a particular subscriber

2.     Day 1 - CA issues a certificate valid for 825 days

3.     824 days later - CA issues a new certificate valid for 825 days using the I&A data cached from day 1

4.     …rinse, repeat.

  In short, we can certify ownership of a domain for 1649 days (over 4 and a half years) based on a single I&A verification event performed on Day 1, correct?

Now you understand our concerns regarding that reuse, and our desire to see Ballot 190 (and Ballot 186) address these concerns more meaningfully to the information they're attesting to, based on the risk and frequency of change.

Under the current BRs (1.4.2), Section 4.2.1 permits it for thirty-nine months. If we take the most absolutely liberal interpretation (which is difficult to justify, but easy to compute), of 39 months meaning 31-day months, for a total of 1209 days, then it means a CA only needs to validate an Applicant controls a domain once every 2,417 days.

Assuming 1.4.4 successfully is adopted, that will reduce to one DNS validation performed every 1,649 days.

We should aim to see that number, for domain validations, reduced to (max lifetime of cert), at worst.

Note that in theory, the Subscriber is contractually obligated to inform the CA when they lose the right to use the domain name. In doing so, this absolves the CA of the responsibility to ensure the information they've certified is correct, because it is the Subscriber that has failed to follow the TOU, not the CA's fault. This comes from Sections 9.6.1(1), 9.6.3(1), and 9.6.3(5).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170421/2bfb2d3a/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3229 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170421/2bfb2d3a/attachment-0001.p7s>