[cabfpub] Ballot 193: Problem 1

[Peter Bowen]

> On Mar 1, 2017, at 6:37 PM, Ryan Sleevi via Public <public at cabforum.org> wrote:

> Current Section 4.2.1
> "Section 6.3.2 limits the validity period of Subscriber Certificates.   The CA MAY use the documents and data 
> provided in Section 3.2 to verify certificate information, provided that the CA obtained the data or document 
> from a source specified under Section 3.2 no more than thirty‐nine (39) months prior to issuing the Certificate"
> 
> Proposed for Section 4.2.1
> Section 6.3.2 limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in Section 3.2 to verify certificate information, provided that (i) the CA obtained the data or document from a source specified under Section 3.2 no more than 825 days thirty‐nine (39) months prior to issuing the Certificate; and (ii) the method used to obtain the document or data was acceptable under Section 3.2 at the time the document or data was obtained.
> 
> Problem Summary: This allows CAs to bypass checking the accuracy of Subscriber information, including authorized domain names when reissuing certificates. While this may be desirable by CAs that wish to be lax in what they issue, it is not permitted under the current Baseline Requirements.
> 
> Explanation: The current Section 4.2.1 limits the reuse of information to "data or document from a source specified under Section 3.2". It appears that some CAs have interpreted this to describe both the data and the procedure of verifying that data, but that's not what is currently stated. That is, Section 4.2.1 only permits the reuse of information. In some cases, the mere existence of this data or documentation may be sufficient to constitute the verification process. For example, Section 3.2.2.2 regarding DBA/Tradenames describes that "the CA SHALL verify the Applicant's right to use the DBA/tradename using at least one of the following". In this case, the source of the data is equivalent to verifying the data, modulo the stipulations set forth in 3.2.2 regarding the CA's obligation to inspect any document for alteration or falsification.
> 
> However, in other cases, the act of obtaining data and documentation is distinct from that of verifying. For example, Section 3.2.2.4 notes that "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 using at least one of the methods listed below.". In this case, this poses a continual validation requirement - every certificate must be validated. In recognizing this, the immediate next paragraph of Section 3.2.2.4 notes "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."
> 
> The above highlights an example where obtaining data is distinct from the act of validating that data. This is further reaffirmed using 3.2.2.4.6 as an example, which provides a special proviso regarding Agreed-Upon Change to a Website, noting "If a Random Value is used, the CA or Delegated Third Party SHALL provide a Random Value unique to the  certificate request and SHALL not use the Random Value after the longer of (i) 30 days or **(ii) if the Applicant  submitted the certificate request, the timeframe permitted for reuse of validated information relevant to the  certificate (such as in Section 3.3.1 of these Guidelines or Section 11.14.3 of the EV Guidelines).** " (Emphasis in ** added)
> 
> Example: Imagine that the Baseline Requirements, version 1.0.0, Section 3.2.2.2, listed an additional method, "6. By obtaining an assertion from Ryan Sleevi that the information is correct". A certificate issued during the 'Effective' period of Version 1.0.0, with my explicit approval regarding the DBA/tradename, would this be compliant with the Baseline Requirements. Recognizing, however, that I am a flawed individual, imagine that the CA/B Forum adopts version 1.1.0 of the Baseline Requirements, which removes this method. At the time of certificate issuance, the CA MUST verify the Applicant's right to the DBA/tradename. Despite my previous approval, completed within the 39 month window, this method is no longer acceptable in version 1.1.0. Thus if a certificate is issued for a DBA/tradename, relying on my prior assertion, it would be in violation of the Baseline Requirements.

> Conclusion: The above demonstrates that the existing Baseline Requirements already require that, for each and every certificate issued, the CA follow the appropriate verification steps for each piece of presented information. Further, as discussed during rekey discussions, this applies for all issuance - as rekey is not a form of separate issuance. Finally, we have long recognized consensus that the act of issuing a certificate uses the current version of the Baseline Requirements - that is, there is only 'one' version in force at any given time. Recognizing the challenges this may present for rekey, CAs are allowed to reuse information obtained from previous issuances, if and only if the means of obtaining that information is defined in the 'current' Section 3.2. 
> 
> Suggestion: Remove this.

As a reminder, in the BRs section 3.2, the CA must verify

- Organization Identity  (if included in the certificate)
- DBA/Tradename (if included in the certificate)
- Country (if included in the certificate)
- Domain Authorization or Control (if cert has DNS names)
- IP Address Authorization or Control (if cert has IP addresses)
- Data sources
- Individual Identity  (if included in the certificate):
- Authority to issue certificate naming the organization in the subject (if org is in cert)

Each of these has specified methods to do the verification.  In the case of domain control, many of them involve ephemeral tests — for example, receiving a token sent to the customer via email or postal mail.  So the data or document is a record of receiving this token.  

It does make sense to allow reuse of this test result if the test process meets a revised requirement as well as the prior requirement.  For example, if we decide to remove admin@<domain> as an allowed validation email address, that should not invalidate all existing role email-based validations.  Similarly, if the old requirement was "Communicating directly” with an email address and the new requirement is to send a 112-bit or larger Random Value to the email address and receiving a confirming response utilizing the sent Random Value, it makes sense to allow CAs that followed this procedure to continue to use the resulting validation even if they previously logged it as being validated due to meeting the “communicating directly” requirement.

Therefore I think we need a clarification that reuse is permitted if the process used at to validation the data meets the current requirements, even if the full process is not repeated.  We don’t want to require resending emails for each certificate.

Thanks,
Peter