[cabfpub] How a Certificate Is Issued - the Baseline Requirements Version

[Ryan Sleevi]

Peter asked, in https://cabforum.org/pipermail/public/2017-April/010392.html
, that I write up how I believe the Baseline Requirements permit a
certificate to be issued.

I will attempt to explain, with supporting citations to the existing
Requirements, so that member CAs who disagree with this can provide the
relevant Baseline Requirements clauses that may exempt from this.


   1. A Certificate Request is received.
      1. There is no technical requirement as to the format of the request.
      It could be a CSR, potentially even one with an invalid
signature. It could
      be a call to an API. It could be a phone call requesting a certificate.
      2. The request, as used in the BRs, refers to the logical process
      that aggregates all of the information, and that information may be
      aggregated over a series of interactions or exchanges. At a minimum, a
      Request must include a public key, whether explicitly or implicitly
      (Section 6.1.1.3)
      3. The CA must archive the request, as well as all data supporting
      the request, for at least seven years after any certificate
issued expires
      (Section 5.5.2)
      4. The CA must record that the request was made, all information
      generated and documentation received in conjunction with the request
      (Section 5.4.1)
   2. The CA must ensure it has an executed Subscriber Agreement or Terms
   of Use (Section 4.1.2)
   3. The request does not need to contain all of the information related
   to the certificate (Section 4.2.1). If it does not, the CA shall obtain it
   either from the applicant or a reliable, independent third-party data
   source which is then confirmed with the applicant.
   4. The CA must verify every request independent of any past actions
   (Section 4.2.1, "The CA SHALL establish and follow a documented procedure
   for verifying all data requested for inclusion in the Certificate by the
   Applicant.", "The CA MAY use the documents and data provided in Section 3.2
   to verify certificate information" - note, active tense)
   5. The CA may use previously obtained information consistent with that
   validation, provided that it reverifies that data
      1. For example, if a certificate request includes the name or address
      of an organization (Section 3.2.2.1), then the CA may verify that request
      by using data previously obtained from one of the data sources enumerated
      therein. The CA MUST verify that the information in the request is
      consistent with that dataset. For a programmatic verification,
this may be
      as 'simple' as checking an equality check with the existing documents.
   6. The documents and data used MUST be consistent with the policies
   related to the certificate at the time of issuance.
   1. For example, if a domain was verified using 3.2.2.4.11, and the data
      and documents used to support that verification are no longer accepted by
      the in-force version of the Baseline Requirements, the CA MUST NOT issue
      the certificate. This is consistent with Section 4.2.1
enumerating that the
      CA MUST verify the information.
   7. The CA MAY designate a third party to do this verification. This is
   called a Delegated Third Party (Section 1.3.2)
      1. All Delegated Third Parties MUST meet the obligations stated
      within Section 1.3.2
         1. They must be qualified per Section 5.3.1
         2. They must retain all documentation per 5.5.2
         3. They must abide by the Baseline Requirements at all times
         4. They must comply either with the CA's CP/CPS or their CA/CPS,
         which must comply with the BRs
      2. An Enterprise RA is a Delegated Third Party (Section 8.4, "If a
      Delegated Third Party is not currently audited in accordance
with Section 8
      and is not an Enterprise RA", "and the Delegated Third Party is not an
      Enterprise RA")
      3. If an Enterprise RA is used, then in addition to the above
      stipulations, the CA must ALSO ensure
         1. The CA confirms that the FQDN is within the Enterprise RA's
         verified Domain Namespace
            1. While the use of the past-tense "verified" here may imply
            the use of a previous verification, this would not be
consistent with the
            application of Section 4.2.1 and Section 3.2. The
interpretation of this is
            that the CA must, for every certificate issued by the
Enterprise RA, verify
            that Enterprise RA's domain namespace using one of the
methods in Section
            3.2, using data and documents that may have been
previously obtained (Per
            Section 4.2.1). The Enterprise RA is thus responsible for
verifying the
            portion of the Domain Namespace beneath that.
         2. For every name in the Subject other than the FQDN, the CA MUST
         ensure, for every certificate, that the name is either that
of a delegated
         enterprise, or an affiliate of the delegated enterprise, or that the
         delegated enteprise is an agent of the named Subject.
            1. This verification may also be implemented via technical
            controls as an equality check. For example, that "Document
Foo" establishes
            that Applicant Bar (An Enterprise RA) is authorized for
"ABC Co.". Any
            subsequent certificate requests can compare if the name is
"ABC Co.", and
            if so, has met its obligations with respect to continuous
verification and
            the reuse of information
         4. Unless the Enterprise RA is audited, the CA must have a
      Validation Specialist employed by the CA perform ongoing quarterly audits
      of the greater of one certificate or three percent of certificates issued
      (Section 8.7)
         1. This means all Enterprise RAs should be undergoing an audit
         performed by the CA's Validation Specialist
      5. The CA must ensure that Delegated Third Parties, which includes
      Enterprise RAs, uses a process that provides at least the same level of
      assurance as the CA's own processes (Section 4.2.1)
         1. If a CA implements a domain blacklist, for example, it MUST
         ensure that Enterprise RAs implement the same domain blacklist
      8. For domain names, and domain names only, "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."
   (Section 3.2.2.4)
      1. "such as" is illustrative, not exhaustive. As such, despite the
      relevant section number being incorrect (It's 4.2.1 not 3.3.1), that does
      not normatively change the requirement
      2. Individual sections may specify more or less restrictive
      timelines. This is the discussion related to Ballot 186 in
conjunction with
      190. The proposed 190, for example, limits the use of a Random Value in
      3.2.2.4.4 to 30 days, which thus limits the use, even in the presence of
      Section 4.2.1
         1. Section 3.2.2.4.7 of Ballot 190 attempts to draw an equivalence
         to 30 days or that permitted by 4.2.1. While repeating the
same mistake as
         the existing text, of referencing Section 3.3.1, it is a
non-exhaustive
         example set, and thus accomplishes the intended goal, even if
referencing
         the wrong section as an example.

The combination of these means that an acceptable flow is as follows, using
Peter's example

   - Customer contracts with CA for certificates and to establish an
   Enterprise RA
   - Customer and CA negotiate credentials
      - The credentials used must conform with the NCSRs if the CA is
      audited to the NCSRs, because Enterprise RAs are DTPs, and thus the CA's
      relationship to them is subject to the NCSRs
   - CA obtains documents that cover evidence of identity (for OV/EV) and
   evidence of domain control/authorization for customer specified identities
   and domains
   - CA receives application for certificate from Enterprise RA,
   authentication based on #2
   - The CA uses information collection to verify the information in the
   request
      - The CA MUST verify the Enterprise RA is authorized for the Domain
      Namespace
         - This MAY use the previously obtained data and documents. In this
         case, the CA MUST verify that the requested name matches the data or
         document as defined in Section 3.2.2.4. This may simply be an equality
         check using information a Validation Specialist previously
entered as data
         to be associated with the document (Section 4.2.1). For some
methods,such
         as 3.2.2.4.5, the CA MUST ensure it meets the clauses of either (i) or
         (ii), which are more than 'simple' equality checks.
         - OR This MAY reuse a completed confirmation of applicant
         authority, provided if and only if the applicant authority is
consistent
         with the then-current Section 3.2.2.4 (Section 3.2.2.4), for
(at present),
         a period of up to 39 months, unless that period is reduced a specific
         clause within Section 3.2.2.4.*, such as 3.2.2.4.6 (Section 3.2.2.4,
         Section 4.2.1, Section 3.2.2.4.*)
      - The CA MUST verify domain name is within the authorized Domain
      Namespace (Section 1.3.2)
      - The CA MUST confirm that the Subject information, if any, meets the
      requirements of Enterprise RA authority (Section 1.3.2)
         - This MAY use previously obtained data and documents. In this
         case, the CA MUST verify the requested Subject name matches
the data or
         documents as defined in Section 3.2. This may simply be an
equality check
         using information a Validation Specialist previously entered
as data to be
         associated with the document (Section 4.2.1)
      - If verified, issues certificate
   - Every quarter, a Validation Specialist at the CA verifies the greater
   of one certificate or three percent of the certificates issued by the
   Enterprise RA to assess compliance with the contract and CP/CPS (Section
   8.7), including restrictions on identifying and verifying High Risk
   Requests (Section 4.2.1)
   - The Enterprise RA MUST maintain all documentation for a period of at
   least seven years since the last certificate expired (Section 1.3.2,
   Section 5.5.2)
   - The Enterprise RA MUST ensure all of its personnel involved in
   issuance have had their identity and trustworthiness verified (Section
   1.3.2, Section 5.3.1)


Here's the important takeaways:

   - There's nothing (that I can tell) to support the idea that a
   previously Completed Confirmation of Applicant Authority may be re-used if
   the previous method is no longer permitted under the current BRs
   - There's nothing (that I can tell) to support the idea that for
   non-domain related changes, you can 'reuse' the previous verification. You
   must reverify the information, however, the act of reverifying may simply
   be a programatic check of the Validation Data associated with a previous
   request
   - There's nothing (that I can tell) to support that you can obtain the
   data prior to an Applicant making a Certificate Request. The applicant may
   include that information in their request. Alternatively, the CA may get
   that information from a reliable, independent, third-party source after the
   Request is made, but must confirm that with the Applicant (per Section
   4.2.1). This implies that a CA who obtains the information before the
   Request is no longer obtaining it from a reliable, independent, third-party
   source, but from a first-party source. This is perhaps an area of
   disagreement regarding the agreement between "the CA SHALL, ... or, having
   obtained..." as to whether the 'obtained' is allowed to precede the
   application.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170414/24582c9a/attachment-0002.html>