On Wed, Mar 8, 2017 at 5:08 AM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Wed, Mar 8, 2017 at 12:57 AM, Peter Bowen via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: >> >> If the DTP is only performing the functions that Jakob lists, then >> they only need an auditor's opinion covering those functions. In fact >> there is no way for an auditor to audit functions that don't exist. >> For example, consider the WebTrust for CA criteria called "Subordinate >> CA Certificate Life Cycle Management". If the only CA in scope for >> the audit does not issue Subordinate CA Certificates, then that >> criteria is not applicable. Depending on the auditor, it might be >> that the CA needs to write in some policy (public or private) "the CA >> does not issue Subordinate CA Certificates." >> >> Many auditors vary how much they charge for their work based on the >> expected effort required to compete the work. I believe Jakob's point >> is that an audit where all the criteria are just "we do not do X" is >> very quick -- for example a DTP that does not have a HSM and does not >> digitally sign things is going to be a much cheaper audit than one >> that does have a HSM and signs things under multi-person control. > > > So I agree with this - namely, that a DTP audit does not include the > Principles and/or Criteria relevant for the operational aspects they don't > control, because the auditor neither forms an opinion about the third-party > operation. I think a good example, to continue with yours, if the issuing CA > handles the HSM, and is already audited as such, then the auditor will not > opine on another auditors work. > > So the scope of a DTP audit will be limited to the functions provided by the > DTP. > > But the same is true for an externally operated sub-CA, for which the > majority of services are provided for by the "issuing" CA, and the DTP > performs the validation functions for this sub-CA.
Ah, but it is not true. I had a very enlightening discussion with representatives from the WebTrust Task Force at the CA/Browser Forum meeting in Redmond. CAs must be evaluated on all the WebTrust criteria that are not marked optional in order to get a WebTrust seal and the same auditor must do the whole audit. So, sub-CA Foo contracts with Bar to host the HSM for the sub-CA and handle the issuing functions (and probably the revocation functions) and if Bar is also a CA, Bar gets audited twice. One time by Bar's auditor at Bar's cost and then again by Foo's auditor at Foo's cost. Note that WebTrust for CA criteria 6 says: "The Certification Authority maintains effective controls to provide reasonable assurance that Subscriber information was properly authenticated (for the registration activities performed by ABC-CA)." Given this criteria, the auditor does not have to inspect each RA themselves. Also note that the only optional criteria are: 2.1 Certificate Policy Management (if applicable) 2.3 CP and CPS Consistency (if applicable) 4.8 CA Key Escrow (if applicable) 5.1 CA-Provided Subscriber Key Generation Services (if supported) 5.2 CA-Provided Subscriber Key Storage and Recovery Services (if supported) 5.3 Integrated Circuit Card (ICC) Life Cycle Management (if supported) 6.2 Certificate Renewal (if supported) 6.7 Certificate Suspension (if supported) The CA Key Lifecycle controls, including storage and usage, are not optional, so each sub-CA must be audited on them. > This is why I'm suggesting, from an audit scope, they're functionally > equivalent approach, except one avoids the whole complexity of identifying > where or not a DTP is something different-than a sub-CA, since the _intent_ > is true in both, which is that 100% of the capabilities related to issuance > are appropriately audited - either by the DTP/sub-CA or by the issuing > CA/managed CA provided > > Does this make it clearer the point I was trying to make, which is that > they're functionally equivalent - due to the fact that both DTPs and sub-CAs > have the issue of multi-party audit scopes? I agree that you suggest an approach that is probably functionally equivalent, but what you describe is not how WebTrust audits work. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
