Confirmed users, Administrators
5,526
edits
Line 70: | Line 70: | ||
* http://portal.etsi.org/TBSiteMap/ESI/TrustServiceProviders.aspx | * http://portal.etsi.org/TBSiteMap/ESI/TrustServiceProviders.aspx | ||
== BR | == A CA's First BR Audit == | ||
We [[CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy | previously said]]: | We [[CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy | previously said]]: | ||
"Any Certificate Authority being considered for root inclusion after February 15, 2013 must comply with Version 2.1 or later of Mozilla's CA Certificate Policy. This includes having a Baseline Requirements audit performed if the websites trust bit is to be enabled. '''*Note that the CA's first Baseline Requirements audit may be a Point in Time audit.*'''" | "Any Certificate Authority being considered for root inclusion after February 15, 2013 must comply with Version 2.1 or later of Mozilla's CA Certificate Policy. This includes having a Baseline Requirements audit performed if the websites trust bit is to be enabled. '''*Note that the CA's first Baseline Requirements audit may be a Point in Time audit.*'''" | ||
To clarify, if the root certificate is '''not yet in production and is not yet issuing certificates to customers''', then a Point in Time Readiness Assessment of BR compliance (BR PITRA) may be used. In this case a BR PITRA prior to inclusion may be used, but the next annual audit after inclusion would need to be a full performance audit. Note: If the inclusion process spans more than one annual audit cycle, then more than one BR PITRA may be used, until the root certificate has been included or the root certificate is put into operation producing certificates for customers, whichever comes first. | |||
On the other hand, if the root certificate '''is in production and has issued certificates to customers''', then the first BR audit must be a full performance audit showing BR compliance over at least 60 days. This situation occurs when a CA applying for inclusion did not know about the BRs, so did not get audited according to the BRs during their previous audit cycle. However, the CA does have a current valid audit statement indicating compliance with WebTrust Principles and Criteria for Certification Authorities or ETSI TS 102 042. This shorter period-of-time audit is intended for CAs to use for their first BR audit, so they will not have to go through another full-year audit until their next regularly scheduled annual audit. | |||
In the situation where a CA has been issuing certificates to customers before they knew about the BRs, an untold number of the previously issued certificates might not conform to the BRs. This could be serious, depending on which BRs the CA did not previously comply with, the number of BRs the CA did not previously comply with, and the quantity of such certificates issued. Depending on the situation, the CA may be asked to create a new root certificate for inclusion. Therefore, the CA and/or auditor shall provide a list of the BRs that the previously issued certificates did not comply with. | |||
== Audit Mistakes == | == Audit Mistakes == |