Thanks a ton Ryan for putting this together. This is great info.
I agree the BRs are missing a re-use of information section, which is odd because the section exists in the EV Guidelines (11.14.1 and 11.14.2). I was planning on circulating the following proposal to sync the two requirement docs once the number of pending ballots declined: Add the following to 3.3.1 (taken from 11.14.2 of the EV Guidelines): A CA may rely on a previously submitted certificate request to issue a new certificate if: (1) The expiration date of the replacement certificate is the same as the expiration date of the Certificate being replaced, and (2) The Subject Information of the Certificate is the same as the Subject in the Certificate that is being replaced. Add the following to 4.2.1 (sort of taken from 11.14.1) after the third paragraph: If an Applicant has a currently valid Certificate issued by the CA, a CA MAY rely on the prior authentication and verification of: (1) The Applicant's identity under Section 3.2.2.1; (2) The Applicant’s DBA under Section 3.2.2.2; (3) The countryName under Section 3.2.2.3; (4) The Applicant’s individual identity under Section 3.2.3; and (5) The Applicant’s authorization to issue the Certificate under Section 3.2.5, provided that the CA receives or confirms the request for a Certificate using a Reliable Method of Communication. Thoughts? Jeremy From: Public [mailto:[email protected]] On Behalf Of Ryan Sleevi via Public Sent: Friday, April 14, 2017 10:55 AM To: CABFPub <[email protected]> Cc: Ryan Sleevi <[email protected]> Subject: [cabfpub] How a Certificate Is Issued - the Baseline Requirements Version 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
