On 8/20/14, 5:30 PM, kirk_h...@trendmicro.com wrote:
Sorry for this late response, but Peter Bowen's post below in subpart 2) is
exactly correct - FF needs to accept PITRAs from new CA roots, or else you will
never have any new CA roots.
I updated the wiki page to make it more clear that I am concerned about
the case where the CA did not know about the BRs, so there are an
unknown number of certs in that CA hierarchy that do not conform to the BRs.
https://wiki.mozilla.org/CA:BaselineRequirements#Point_in_Time_Readiness_Assessment_.28PITRA.29
Perhaps we should list the types of problems that are not allowed in
previously issued certs. If previously issued certs had those problems,
then a new root cert would have to be created and considered for
inclusion (instead of the old root cert).
Another post suggested when flaws are found in certs that maybe the CA should
be forced to change auditors; someone responded that would likely be very
expensive (true). A better plan may be to require the current auditor to come
up with an immediate plan for correction and compliance, and then present a
mid-term partial audit following that plan... Probably more meaningful and
effective.
I updated
https://wiki.mozilla.org/CA:BaselineRequirements#Audit_Mistakes
to note that two proposals are under discussion
Proposal #1: When egregious mistakes were overlooked by the auditor,
then require a re-audit by a different auditor.
Proposal #2: For certain types of mistakes that were overlooked by the
auditor, require the current auditor to come up with an immediate plan
for correction and compliance, and then present a mid-term partial audit
following that plan.
The benefit of Proposal #2 is that the auditor is already familiar with
that CA's operations, and the auditor will learn what to watch out for
in future audits.
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
