Maybe it would help that the spreadsheet also says what period is
covered, or when it's going to expire.

Certainly. Note that for some CAs, I have provided both the covered
periods and the date when the report was issued in my mail.


I have a column in the spreadsheet that I'll make public, called "Audit Statement Date". However, I have a couple of caveats to the current data:
1) I'm behind in updating the spreadsheet. I hope to get to it soon.
2) I used to record the audit period end date, so some of the dates will be inconsistent. This will get fixed as I update them.

Over time, my plan is to fix the dates in this column so that it will be more useable.


From the rules you quoted, each CA should have an audit report covering
an audit period ending not more than 15 months ago (12 months for the
audit period following the one on file, plus 3 months to deliver the
report), irrespective of the data when the report was issued.
(Alternatively, an explanatory letter.)

Correct.

Note that the spreadsheet may not be a good reflection of a CA's current audit status due to two things:

1) my own work load and priorities (I try to update the spreadsheet a few times per year)

2) CAs often email the statements to me before they are available on a website. I usually wait to update the spreadsheet until I get the corresponding link to the statement on a website (which sometimes adds another couple of months; e.g webtrust.org).


Notably, even if their self-audit report is for some reason considered
acceptable, IGC/A (ANSSI) ...



We are working on the ability to constrain root certificates to certain domains. https://bugzilla.mozilla.org/show_bug.cgi?id=743700

I think we should consider constraining CAs who:
1) Are not able to be audited by outside (3rd-party) organizations (such as some government CAs) 2) Are not able to promptly upgrade their PKIs to current standards/requirements like the BRs (as per previously published responses to CA communications, some government CAs have this problem).

Thanks,
Kathleen



_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to