[cabfpub] Ballot 193: Problem 1

[Ryan Sleevi]

On Wed, Mar 1, 2017 at 4:50 PM, Ryan Sleevi <sleevi at google.com> wrote:
>
> It's unclear whether you disagree with the substance of my analysis, and
> are thus stating it was intentional to weaken the Baseline Requirements, or
> if you're simply providing clarification for the intent, for which the
> weakening of the Baseline Requirements was unintentional?
>
> If this was unintentional, we can work to resolve this in a way that
> achieves the intended resolve. However, if this was intentional, we will
> continue to disagree, and thus will find it necessary to vote against this
> ballot. I can only hope that, like Ballot 188, this was merely an
> unintentional side-effect, and hopefully one we can resolve through
> collaboration.
>

It was pointed out that my description of the issues may not have been
clear for some members, so I'll try to restate the various ways in which
this proposal, whether intentional or not, weakens the current security
guarantees provided by the Baseline Requirements.

In the effort of providing greater clarity, I have created several new
threads to help inform this discussion.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170301/d608331c/attachment.html>