[cabfpub] Ballot 194 – Effective Date of Ballot 193 Provisions

[Ryan Sleevi]

On Mon, Apr 10, 2017 at 8:05 PM, Peter Bowen <pzb at amzn.com> wrote:
>
> Ryan,
>
> The existing practices of many CAs that were intended to be codified into
> the BRs (at least as I understand it) include supporting the following
> workflow:
>

If the BRs were to have codified existing practices, we wouldn't have seen
so many BR violations, both in audits and in issuance ;-)

If those BRs were improper - e.g. didn't align with practice
_un_intentionally, we would have seen more proposals to change them.


> 1) Customer contracts with CA for certificates and to establish an
> Enterprise RA that is authorized to confirm authenticity of certificate
> requests
> 2) CA and customer negotiate authentication credentials for Enterprise RA
> (could be signatures using public key crypto, shared secret, etc)
> 3) CA obtains documents that cover evidence of identity (for OV/EV) and
> evidence of domain control/authorization for customer specified identities
> and domains
> 4) CA receives application for certificate from Enterprise RA,
> authentication based on #2
> 5) CA uses information collected in #3 to verify the information in the
> request
> 6) If verified, issues certificate
>
> This would appear to be compliant with the BRs.  The CA can “obtain[] the
> data or documentfrom a source specified under Section 3.2” ahead of the
> application. (see 4.2.1)  I read “provided” in that sentence to mean
> “presented” or “prescribed” in 3.2, not that they had to be obtained as
> part of the processing of an application for a certificate.
>

#1 - The relationship for designating an Enterprise RA comes from Section
1.3.2. It allows delegation of the performance of all, or any part, of
Section 3.2, provided the process as a whole fulfills all of the
requirements of Section 3.2.
#2 - An Enterprise RA is a Delegated Third Party (per 1.3.2). As such, the
Network Security Controls apply, which restricts the type of authentication
credentials for the Enterprise RA. That is, the Enterprise RA is fully
expected to perform the steps in Section 2 (Each CA or Delegated Third
Party SHALL). The only loosening of those requirements is in Secion 2, Item
(n) (ii), which allows technical controls to restrict the DTP's ability to
approve certificate issuance to a limited set of names in lieu of 2(n)(i),
which requires multi-factor authentication.

I think this is important to stress - an Enterprise RA is a Delegated Third
Party (this is entirely consistent with Section 8.4), and so each of these
"Enterprise RA" accounts you described are fully expected to abide by the
NSCs, and fully perform the duties of Section 3.2.

I don't think your read of provided in Section 4.2.1 is consistent with the
first paragraph, since it explicitly describes it as being included as part
of the certificate request. If you're going to make the argument that
information can be obtained prior to the request, then the phrase to hinge
on would be "the CA SHALL obtain the remaining information from the
Applicant or, having obtained it from a reliable, independent, third party
data source, confirm it with the Applicant." With that, you could at least
question whether "having obtained" allows for it to have been obtained
prior to the request (I don't think that'd be a consistent read, but hey,
at least it'd be an argument)

It seems there in not alignment on the acceptable processes for issuing
> certificates.  I wonder if it might be helpful for you to write up what
> Chrome sees as the acceptable processes (a straw man) and have CAs give
> customer cases where the described processes do not work.  The reverse
> (having CAs describe every possible process) doesn’t seem as useful, as
> there are many assumptions today about how things work that probably will
> get missed going that direction.
>

I disagree that it doesn't seem as useful. I think it remains incredibly
useful if CAs who believe they are affected negatively by this to explain
how. To date, I don't think there's been a good explanation, although
certainly, there have been attempts (and I'm greatly appreciative of them,
even if I disagree with them).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170412/cde0b5c2/attachment-0003.html>