Some comparisons, from the Browser/Root Program Alignment proposal
circulated at
https://github.com/cabforum/documents/compare/master...sleevi:2019-10-Browser_Alignment

On Wed, Oct 30, 2019 at 1:52 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> All,
>
> I will greatly appreciate your thoughtful and constructive feedback on
> the following proposal to add a section to the Common CCADB Policy,
> https://www.ccadb.org/policy
>
> Proposal: Add section 5.1 to the Common CCADB Policy, as follows.
> ~~
> 5.1 Audit Statement Content
>
> CCADB uses an Audit Letter Validation (ALV) tool to automatically parse
> and validate audit statements. This system eliminates manual processing,
> but it requires audit statements to follow some basic rules in order to
> function properly. If the audit statement fails to meet any of the
> following requirements, the CA will be asked to work with their auditor
> to provide an audit statement that passes ALV.
>
> Audit statements listed in the CCADB must contain at least the following
> clearly-labelled information in English:
>
> 1. Name of the organization performing the audit;
>

Suggestion: name /and address/ of the organization performing the audit


> 2. Full name of the CA that was audited;
> 3. SHA-256 fingerprint of each root and intermediate certificate that
> was in scope of the audit (see format specifications below);
>

Microsoft policy actually requires the disclosure of the full hierarchy
(c.f.
https://docs.microsoft.com/en-us/security/trusted-root/program-requirements
 3.4)

This may help, or harm, the approach used with ALV. There is benefit in
disclosing what is known-and-out-of-scope, but this may cause ALV to
believe that it was in-scope. I've seen CAs disclose explicitly what's out
of scope (e.g. Amazon), and I find this hugely valuable. You can see the
proposed wording from the BR is actually more explicit:

"""the full PKI hierarchy of all certificates that are capable of being
used to issue new certificates, identified by Distinguished Name and the
SHA-256 fingerprint of each and every certificate, and including all Roots,
Subordinate CA Certificates, and Cross Certificates, clearly identifying
which were certificates (and associated keys) were in-scope and
out-of-scope of the audit;"""


> 4. List of the CA policy documents (with version numbers) referenced
> during the audit;
> 5. Whether the audit is for a period of time or a point in time;
> 6. Date the audit statement was written (see date format specifications
> below);
>

The existing Mozilla policy is slightly clearer that this date will always
be after the start/end date for the period, which helps resolve some of the
confusion for period of time.

e.g.
"9. the date the report was issued, which will necessarily be after the end
date or point in time date; and"


> 7. Start date and end date of the period that was audited, for those
> that cover a period of time (this is not the period the auditor was
> on-site);
> 8. Point-in-time date, for those that are for a point in time;
> 9. Full names and version numbers of the audit standards that were used
> during the audit; and
> 10. For ETSI, a statement to indicate if the audit was a full audit, and
> which parts of the criteria were applied, e.g. DVCP, OVCP, NCP, NCP+,
> LCP, EVCP, EVCP+, QCP-w, Part1 (General Requirements), and/or Part 2
> (Requirements for trust service providers).


> ETSI Audits: Audits conducted by certified ETSI auditors must have their
> audit statement uploaded to their auditor’s website. CAs provide the URL
> to the audit statements on the auditor’s website, and ALV will verify
> those URLs against a known list of audit locations.
>
> WebTrust Audits: Audits conducted by certified WebTrust auditors must
> have a WebTrust Seal. CAs enter the URL to the WebTrust Seal into the
> CCADB, and upon saving of the record, the CCADB automatically converts
> the URL to point to the corresponding PDF file via integration with CPA
> Canada.
> - For qualified WebTrust audits, CAs may attach the audit statement to a
> Bugzilla Bug and provide that URL. Additionally, the CA needs to provide
> an explanation about the findings and timeframe for resolution of the
> findings.
>

Erm, is CCADB supposed to adopt Bugzilla? I just wasn't sure if this was a
carryover from Mozilla Policy that may not generalize?

Any expectations on authoritative English version? Is that to be left to
root policy?


>
> Format Specifications for SHA-256 Fingerprints:
> - MUST: No colons, no spaces, and no linefeeds
> - MUST: Uppercase letters
> - SHOULD: be encoded in the document (PDF) as “selectable” text, not an
> image
>
> Format Specifications for Dates: The following formats are accepted by ALV
> - Month DD, YYYY example: May 7, 2016
> - DD Month YYYY example: 7 May 2016
> - YYYY-MM-DD example: 2016-05-07
> - Month names in English
> - No extra text within the date, such as “7th” or “the”
>
> ~~
>
> Thanks,
> Kathleen
>
> Relevant links:
> - https://github.com/mozilla/www.ccadb.org/issues/33
> -
>
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#314-public-audit-information
> -
>
> https://social.technet.microsoft.com/wiki/contents/articles/31635.microsoft-trusted-root-certificate-program-audit-requirements.aspx#E_Audit_Attestation
> - https://www.ccadb.org/cas/fields#uploading-documents
>
>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to