On 8/26/14, 4:14 PM, Kathleen Wilson wrote:
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).
Do you have recommendations about which BRs should be in this list?
i.e. the BRs that if not previously followed, the CA would have to
create a *new* root certificate to be considered for inclusion.
I do not have a list of such BRs, so I'm considering removing this part
(re requiring a new root cert) from the wiki page.
Also, I'm considering removing the part about the first audit needing to
be at least 3 months, because I'm not sure that adds value over the rest
of the things in the wiki page.
With the rest of the content in this wiki page, do any of you think that
the first BR audit must cover a period of time? (rather than being a
point in time readiness audit)
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.
Would it be OK to allow both Proposal #1 and Proposal #2? (i.e. the CA
gets to choose which of these paths to use to resolve the problems)
I'll take no response to mean everyone is OK with this, so I updated the
wiki page:
https://wiki.mozilla.org/CA:BaselineRequirements#Audit_Mistakes
"When egregious mistakes were overlooked by the auditor or there are a
significant number of oversights, then the CA must resolve the issues
and be re-audited. For the re-audit the CA can either get re-audited by
a different auditor, or have the current auditor provide an immediate
plan for correction and compliance, and then present a mid-term partial
audit following that plan. Non-compliance to the following policies are
examples of mistakes that auditors should not overlook. ..."
Please be sure to read through all of that section, and let me know if
you disagree with anything in it.
Thanks,
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
