Confirmed users, Administrators
5,526
edits
CA/BR Audit Guidance: Difference between revisions
Jump to navigation
Jump to search
→A CA's First BR Audit
| Line 94: | Line 94: | ||
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. | 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. | ||
In general, there are 4 scenarios when a point-in-time BR audit may be used: | |||
# An organization is standing up a CA for the first time, wants to issue public SSL certs, so the first audit would be point in time, with all subsequent audits being period of time. | |||
# A private CA who has been issuing SSL certificates (for example, an internal Enterprise CA) wants to be included in a root programme (or be cross-certified to an existing public CA) would have a point in time BR audit as part of their preparation activities for ‘going public’ and subsequent audits as period of time. | |||
# A public CA who has never issued SSL certificates (and their Root CA certificate is not trusted for SSL) wants to build an SSL hierarchy and begin issuing SSL certs – the first audit can be point in time and all subsequent audits period of time | |||
# Any CA who has received a qualified BR audit opinion (i.e. failing criteria) for its regular period of time audit and then conducts remediation may want a point in time audit to demonstrate their remediation efforts | |||
When the root certificate '''is in production and has issued certificates to customers''' 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 root certificate '''is in production and has issued certificates to customers''' before the CA 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. | In the situation where a root certificate '''is in production and has issued certificates to customers''' before the CA 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. | ||