[cabfpub] Question around I&A information caching

[Ryan Sleevi]

On Fri, Apr 21, 2017 at 12:45 PM, Alex Wight (awight) <awight at cisco.com>
wrote:

> 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.
>

Correct. The reuse of data or documents is permitted, where the data or
documents obtained might be, for example, the contents of a file at
/.well-known/ that uses a random value.


> 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)
>

Right. Section 3.3.1 is an illustrative, non-exhaustive example. Section
4.2.1 sets the upper-bound, but I suppose some want to argue that even
4.2.1 doesn't apply to the reuse of completed confirmations (were that the
case, domain validation would only ever have to be performed once)


> 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)
>

I would say no, and so far, no one else has chimed up :P

https://cabforum.org/pipermail/public/2017-April/010539.html maybe helps
answer this?

You could use this to compare 3.2.2.4.6 vs 3.2.2.4.10, because they
actually provide different guidance:

3.2.2.4.6 - Allowed to use Required Website Content or a Request Token or
(Request/Random) Value.
  - RWC validity period: Bounded by 4.2.1 (it's "data")
  - RT validity period: Bounded by 4.2.1 (it's "data")
  - Random Value validity period: Bounded by 3.2.2.4.6, as the longer of 30
days or... the validity period of 4.2.1 (also referencing 3.3.1 as
illustrative, but non-exhaustive)

3.2.2.4.10 - Allowed to use TLS with a Random Value within a certificate
  - Random Value validity period: Not specified within 3.2.2.4.10, so
bounded to the bounds of 4.2.1 (it's "data")

However, both of these methods' restrictions are made moot by 3.2.2.4,
which allows "Completed confirmation" to be reused. However, there is
apparently some disagreement about whether or not the "Completed
Confirmations" must have been conducted in accordance with 3.2.2.4 at the
time it was issued, or whether it's valid to use a "completed confirmation"
obtained at any time, ever, in the past (... and whether or not that's
bounded by 4.2.1). That's the discussion Gerv and I have been having in
https://cabforum.org/pipermail/public/2017-April/010483.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170421/be9bf3a0/attachment-0003.html>