Thanks Ryan. I think your analysis reflects my own thoughts. Particularly I appreciate you bringing up this point because it’s the crux of the argument:
- DTPs are defined in Section 1.6.1 - any function or requirement under the BRs that is performed by an entity not in scope of the CA's audit The difficulty is determining whether something is in the scope of the CA’s audit. For example, CAs generally fall along the following lines with respect to third party delegation: 1. No audit required of DTP because they audit criteria doesn’t exist (which is the argument below) 2. No audit required if the DTP provides the information to the CA in a repository because the information rests with the CA at this point. No requirement for the CA to review the documentation, but the document is available to the auditor. a. Relies on the interpretation that only certificates are covered by the audit, not the party gathering information or providing the services b. DTP is considered within the CA audit because the information is covered by the audit 3. No audit required if the DTP provides the information and the CA reviews the information a. Still ignores the DTP infrastructure b. CA is governing use of the data so the DTP is already in scope of the CA audit 4. No audit required if the DTP gathers information and the CA independently confirms the information or operates the service a. Full disclosure, this is where I’ve always thought the audit requirement stopped b. The CA is performing al operations. The DTP is just providing information related to the request. 5. Audits required of all DTPs if they are providing any information or services required under the BRs a. This one is more problematic as it starts to include data sources in the CA’s audit b. Could this also include the cert requester? Despite the argument I presented below, the entire question relies on underlying confusion in the DTP definition (Section 1.6.1) and when exactly a DTP applies because their activities are “within the scope of the CA audits”. From: Ryan Sleevi <[email protected]> Sent: Wednesday, November 7, 2018 11:54 AM To: Jeremy Rowley <[email protected]>; CABFPub <[email protected]> Subject: Re: [cabfpub] Audit of RAs On Wed, Nov 7, 2018 at 1:04 PM Jeremy Rowley via Public <[email protected] <mailto:[email protected]> > wrote: I would like to discuss whether unaudited Delegated Third Parties are permitted under the BRs. My reading of the BRs (combined with what happened to Symantec) is that unaudited RAs are, at least mildly, frowned upon by the browsers. However, I think the BRs may be unclear on this point which is leading to an increased delegation of responsibilities to unaudited third parties. If there is confusion, could we pass a ballot to rule one way or another? I think in order to get a ballot, we need to make sure we understand what is causing people's confusion - so this will presumably require those advocating such interpretations (whether CAs or auditors) to clarify their positions. Section 8.1 – Certificates Only “Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with section 7.1.5 and audited in line with section 8.7 only, or Unconstrained and fully audited in line with all remaining requirements from this section. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 basicConstraints extension, with the cA boolean set to true and is therefore by definition a Root CA Certificate or a Subordinate CA Certificate” Note that certificates all covered by the audit, not Delegated Third Parties. The audit for an R/A is “error: no such audit exists”. So, I think framing it like this naturally leads to confusion. Let's not speak about RAs yet - hopefully there's clear consensus that certificates (including roots) need to be audited or technically constrained. Audited includes all the performance of activities under the rest of the BRs. There's nothing in here to support 'excluding' any activities. This is just a basic statement about what's required. A CA issues certificates, everything that causes issuance must be audited - including that of third-parties. Section 8.4 – Inapplicable Audit Schemes “For Delegated Third Parties which are not Enterprise RAs,, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 8.1, that provides an opinion whether the Delegated Third Party’s performance complies with either the Delegated Third Party’s practice statement or the CA’s Certificate Policy and/or Certification Practice Statement. If the opinion is that the Delegated Third Party does not comply, then the CA SHALL not allow the Delegated Third Party to continue performing delegated functions.” Again, the issue is the lack of a audit of the RA, which amounts to the CA giving a statement to the auditor that the RA totally complies with the CA policies. No real check because the auditor is only looking at the CA, not the RA. Also, the section refers to 8.1 which covers certificates, not operations or process. See the previous argument that there is no audit for RAs, meaning the only check on the RA is the random sample of certificates reviewed by the auditor. This is also not a defensible interpretation. The requirement is that the CA shall obtain an audit report, for the DTP, using the same standards as the audit schemes from 8.1. There's no exceptions here in this 8.4. Through the reference to 8.1, it's also not defensible to suggest that the CA can produce the audit report themselves; they're required to get something using the same standards. Section 8.7 – Overriding the Audit This is where the primary main control and where the override comes from: Except for Delegated Third Parties that undergo an annual audit that meets the criteria specified in Section 8.1, the CA SHALL strictly control the service quality of Certificates issued or containing information verified by a Delegated Third Party by having a Validation Specialist employed by the CA perform ongoing quarterly audits against a randomly selected sample of at least the greater of one certificate or three percent of the Certificates verified by the Delegated Third Party in the period beginning immediately after the last sample was taken. The CA SHALL review each Delegated Third Party’s practices and procedures to ensure that the Delegated Third Party is in compliance with these Requirements and the relevant Certificate Policy and/or Certification Practice Statemen So there is a case where Delegated Third Parties are not audited under 8.1. What are these? The only thing that makes sense are RAs. This means the CA can take full ownership of all audit and communication to the RA as long as they look at 3% (and provide the certs to the auditor of they are included in the audit by the auditor) and review the practices and procedures. This places all trust in the CA to ensure these entities are compliance. No. This is not correct either. Enterprise RAs are the only DTPs that are not undergoing an annual audit under Section 8.1. Enterprise RAs are specifically defined to be technically constrained in their issuance. If they are not technically constrained, they are not Enterprise RAs. 1.3.2 – The Exception This is where the exception comes into play: With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2. Before the CA authorizes a Delegated Third Party to perform a delegated function, the CA SHALL contractually require the Delegated Third Party to: (1) Meet the qualification requirements of Section 5.3.1, when applicable to the delegated function; (2) Retain documentation in accordance with Section 5.5.2; (3) Abide by the other provisions of these Requirements that are applicable to the delegated function; and (4) Comply with (a) the CA’s Certificate Policy/Certification Practice Statement or (b) the Delegated Third Party’s practice statement that the CA has verified complies with these Requirements. Under this section, you can bind the RA by contract to meet the policies and procedures of the CA (which satisfies the CA’s requirements under 8.7 to ensure the delegated third party is operating in accordance with the CA’s CPS) No. This is not an alternative to or an exception - this is a set of *additional* requirements beyond the audit. This supplements the auditing process by ensuring that the activities of the DTP are consistent with the CA's CP/CPS, and separately, an audit to ensure they're being performed correctly. That’s the logic presented. Ie – 8.1 requires an audit, but the CA can perform the audit. The CA performs the audit by simply putting a contract in place that the RA will abide by all requirements. The CA still has to audit a random sample, but you can delegate that to the Delegated Third Party as well…. Thoughts? Can we create a clear statement on whether delegated third parties are audited or unaudited? I appreciate you raising this, because this would be a pretty irresponsible read. Let's set up a hierarchy of requirements. - DTPs are defined in Section 1.6.1 - any function or requirement under the BRs that is performed by an entity not in scope of the CA's audit - Enterprise RA - Defined in Section 1.6.1, an entity other than the CA that authorizes certificates. The ability to use such entities is constrained/defined in Section 1.3.2 in terms of when they can be used - CAs may use DTPs to perform Section 3.2 activities if-and-only-if they meet the requirements enumerated in Section 1.3.2. - CAs may use DTPs to perform (any function) if-and-only-if they meet the requirements enumerated in Section 1.3.2 - CAs using DTPs MUST ensure their DTPs comply with Section 4.2.1 if delegating part of 4.2.1. This requires the CA *also* validate consistency with part of 4.2.1; this does not replace, this is in addition to any other requirements. - CAs using DTPs MUST meet the requirements of Section 5.3.7. This is in addition to any other requirements. - Section 8.4 requires CAs using DTPs (except Enterprise RAs, which are only performing a single function, per above) to obtain audits consistent with Section 8.1 If I understand the argument "you" (really, others) are making, it's that Section 8.1 doesn't define audit schemes like ETSI or WebTrust, and only discusses CA certificates, therefore, Section 8.4 doesn't really require anything (because 8.1 is empty re: DTPs) This argument seems based on the references to Section 8.1. If we look through the document history, we can see this is an artifact of a bad translation to the RFC 3647 format; the version prior to this - https://cabforum.org/wp-content/uploads/BRv1.2.5.pdf - put the requirements differently. Namely, both referenced Section 17 (the overall section) rather than the specific section. Later on, the reference to schemes enumerated in 17.1 was accurate, as 17.1 contained what is now contained in Section 8.2 - that is, the specific enumeration of schemes. "Correcting" this mistake seems to be aligning the BRs with what they mandated prior to the 3647 conversion - that is, fixing the reference to "Section 8.1" to read either "Section 8" or "Section 8.2" as appropriate. However, getting to this point involves ignoring the language and how it came to be. Certainly, however, the intent - as captured from those very first versions of the BRs - seems to have been to ensure that DTPs - which includes any (non-Enterprise) RAs - and would include all information management specialists, document verifiers, or any other party for which controls are being delegated to - is being audited using the same standards. If they're not performing certain functions (e.g. an RA does not direct issuance or sign materials), such non-performance would be clearly indicated on the report, while all activities they did perform - and their other protections - would be assessed.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
