Thanks everyone for your input on this topic. I'm hearing consensus that we should not require a newly issued subordinate CA certificate to appear on an audit statement prior to being used to sign end-entity certificates. This is something that could be clarified in our policy with a statement such as "Newly issued subordinate CA certificates MUST appear on the CAs next period-of-time audit statements" in section 5.3.2.
It's not yet clear to me if we should require something more than disclosure of the actual certificate because: * All end-entity certificates are already required to contain "A Policy Identifier, defined by the issuing CA, that indicates a Certificate Policy asserting the issuing CA's adherence to and compliance with these Requirements" (BR 7.1.2.3). Isn't this enough to assert the controls applied to the subCA certificate? * I'm not opposed to explicitly stating that any newly issued subCA certificate MUST appear in the appropriate CP/CPS before being used, but isn't that obvious? * The amount of effort needed to verify compliance with a new requirement for a management assertion (option #2) is significant and could outweigh the benefit we receive from those documents. * Peter's sample assertion letter [1] includes a link to an auditor's key generation ceremony report. Can this type of audit report be shared publicly? If so, those might be a reasonable thing to require via a new field in CCADB. - Wayne [1] https://cabforum.org/pipermail/public/attachments/20160923/3da206b8/attachment-0001.bin On Wed, Mar 28, 2018 at 10:32 PM, Buschart, Rufus via dev-security-policy < [email protected]> wrote: > Operating a technically unconstrained issuing CA, Siemens CA (aka TSP) > does something very similar in case a new CA is necessary: > > * In an audited ceremony based on the operational and technical controls > audited in the last annual audit a key pair is generated on one of the HSMs > * A CSR is constructed and sent to our cross signing partner, together > with the witness report of the auditor, filled with all the information > required by Microsoft in the Audit Cover Letter Template > * The cross signing partner checks the report and creates the certificate > for the issuing CA After receiving the new certificate we update our CPS > Only after the new CPS is published certificates are issued > > In the next annual audit the new CA is part of the normal audit. > > So I would recommend to choose a combination of options #1 and #2. > > With best regards, > Rufus Buschart > > Siemens AG > GS IT HR 7 4 > Hugo-Junkers-Str. 9 > 90411 Nuernberg, Germany > Tel.: +49 1522 2894134 > mailto:[email protected] > > www.siemens.com/ingenuityforlife > > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > [email protected]] On Behalf Of Bruce > via dev-security-policy > Sent: Mittwoch, 28. März 2018 23:38 > To: [email protected] > Subject: Re: Audits for new subCAs > > Entrust does the following: > - Each subCA certificate is created through a audited ceremony. The > auditor creates a report indicating the key ID and the CPS which was used > for key generation. > - When it is time for the subCA to go into production, an intermediate > certificate is issued from a root. The intermediate certificate will meet > the requirements of the CPS and the BRs if applicable. > - The subCA can now issue certificates. The end entity certificates will > have a certificate policy which is stated in the CPS. As such, issuing a > certificate is an assertion that the subCA is issuing in accordance with > the certificate policy and CPS. > - The new subCA is compliance audited at the next time in our annual audit > cycle. Note the new subCA is operated the same as all other CAs meeting the > same certificate policy. > > I would note that if there was a significant change such as data center > location or new certificate policy, then we may want to consider a > point-in-time readiness assessment. I think that all CAs required a > point-in-time readiness assessment, before we started to issue EV > certificates. > > I suppose that I am stating that I support option 1 as I think the option > 2 attestments are already covered. However, option 3 may be required for a > new data center or a policy which has not been previously audited. > > Thanks, Bruce. > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
