On 9/3/2014 4:26 AM, Kathleen Wilson wrote: > I updated the wiki page some more, here's the text... > > https://wiki.mozilla.org/CA:BaselineRequirements#BR_Point_in_Time_Readiness_Assessment_.28BR_PITRA.29 > > == BR Point in Time Readiness Assessment (BR PITRA) == > > We 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.*" > > There are two cases when a Point in Time Readiness Assessment of BR > compliance (BR PITRA) may be used: > > 1. The CA has created a new root certificate, which is not yet in > operation producing real certificates. 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 real certificates, > whichever comes first. CAs should have their self-assessment on their readiness to comply with BRs before performing the BR PITRA. In fact, I will not surprise that you will only get "clean" report from those CAs. If not, why the CA bother to submit to Mozilla? Then I suppose that the root certificate should be included in trust store based on the "clean" PITRA report. Finally the CA put the root certificate into operation to produce real certificates. No "whichever comes first" because CA may not have real customers of certificates if the root certificate has not been included yet. Mozilla should then expect the first performance audit within 12 months. > > 2. The CA 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. > -- The BR PITRA option was initially provided for CAs to use > for their first BR audit, so they would not have to go through another > full audit until their next regularly scheduled annual audit. > -- The BR PITRA shall include a performance audit covering at > least one month, or more as determined by the auditor. If it is a performance audit, it is not a PITRA by definition. In some conversations with auditors, they are quite confused at this point. > -- However, it means that 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. Understood that's why you can expect a BR PITRA which may not be a "clean" report. > -- The CA and/or auditor shall provide a list of the BRs that > the previously issued certificates did not comply with. > -- The CA's next annual audit must include a full BR > performance audit. CAs usually perform annual audit over a 12 months period in the past. For example, an audit report dated in January 2015 shows the audit result of the period January - December 2014. If the first BR PITRA audit is performed now in 2014, which may contains a list of the BRs that yet to be complied with, CA must fix the issues on the list in 2015. If so, the first annual audit that include a full BR performance audit should be in January 2016. Is my understanding correct? > == > > As always, I will appreciate thoughtful and constructive feedback on > this. > > Kathleen > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
