Audit Letter Validation (ALV) on intermediate certs in CCADB

[Kathleen Wilson]

CAs,

There is now an "Audit Letter Validation (ALV)" button on intermediate
certificate records in the CCADB. There is also a new task list item on
your home page. In the summary section you will see a line item like the
following.
"Intermediate Certs with Failed ALV Results: 8"
When that is non-zero, you will see a section that can be opened called
"Check failed Audit Letter Validation (ALV) results"

Instructions for the new task list item:
The intermediate certificates listed below have a failed Audit Letter
Validation (ALV) result. Please check the intermediate certificate to
make sure its SHA-256 Fingerprint is correctly listed in the
corresponding audit statements. If you do not agree with the ALV
results, add comments to the ‘Standard Audit ALV Comments’ or ‘BR Audit
ALV Comments’ fields in the intermediate certificate record.

If you find that the SHA-256 fingerprint of an intermediate certificate
is indeed missing from the applicable audit statement(s) and the
certificate chains to a root that is trusted by Mozilla, then create a
Bugzilla bug to provide an incident report along with your plan and
timing to resolve the problem, as described here:
https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report
Then add the link to the Bugzilla Bug to the ‘Standard Audit ALV
Comments’ or ‘BR Audit ALV Comments’ field for that certificate.

ALV will sometimes report that it was unable to find the SHA-256
fingerprint of the certificate even though it is in the audit statement.
When you find this to be the situation, please add a comment to the
‘Standard Audit ALV Comments’ or ‘BR Audit ALV Comments’ field in the
record to state that the SHA-256 fingerprint for that cert is in the
audit statement.

To help improve accuracy of ALV finding SHA-256 fingerprints have your
auditors follow these guidelines for the SHA-256 fingerprints that are
listed in the audit statements as being in scope of the audits:
- MUST: No colons, no spaces, and no linefeeds
- MUST: Uppercase letters
- SHOULD: be encoded in the document (PDF) as “selectable” text, not an
image

Note, the new task list item focuses on the SHA-256 Fingerprints that
are not found in the audit statements, but there are also many failures
regarding dates that we would like resolved in future audit statements.
So please have your auditors use the following date format guidelines in
all future audit statements.
Accepted date formats (month names in English):
- Month DD, YYYY example: May 7, 2016
- DD Month YYYY example: 7 May 2016
- YYYY-MM-DD example: 2016-05-07
- No extra text within the date, such as “7th” or “the”

-- Implementation Details Below --

The new task list item is filtered as follows.
CA Owner/Certificate Record Type equals Intermediate Certificate
AND Technically Constrained equals False
AND Revocation Status equals Not Revoked
AND OneCRL Status not equal to Added to OneCRL
AND Valid To (GMT) greater than TODAY
AND ((Mozilla Root Status equals Included or Change Requested)
OR (Microsoft Root Status equals Included or Change Requested))
AND ((Standard Audit ALV Found Cert equals FAIL)
OR (BR Audit ALV Found Cert equals FAIL))

The "Standard Audit ALV Found Cert" and "BR Audit ALV Found Cert" are
set according to the ALV result AllThumbprintsListed, which looks for
the cert's SHA-256 fingerprint in the corresponding audit statement.

There is a "Derived Trust Bits" field in the "Certificate Data [Fields
NOT editable; extracted from PEM]" section. Very high level logic: If
the cert has EKU in it, then that will be used. Otherwise see which root
store it's parent root cert is in. If in both Mozilla and Microsoft then
create union of the trust bits that the parent/root cert is trusted for.

When "Derived Trust Bits" contains 'Server Authentication', then ALV is
run on the BR audit. Currently, for intermediate certs, we are only
processing the standard and BR audit statements.

When "Audits Same as Parent" is checked, CCADB will look up the parent
chain until audit statements are found, and run ALV using those audit
statements. When "Audits Same as Parent" is not checked, then CCADB will
just pass the audit statements in the intermediate cert record into ALV.

As always, I will appreciate thoughtful and constructive feedback on
this, especially as you try out the new functionality.

Thanks,
Kathleen

[Kathleen Wilson]

All,

I would like to remind everyone about when these requirements for
non-technically-constrained intermediate certificates came into effect
for CAs in Mozilla’s program according to previous versions of Mozilla’s
Root Store Policy[1] and previous CA Communications[2].

February 2013: Mozilla published version 2.1 of its CA Certificate
Inclusion Policy[3], which introduced clauses #8, 9, and 10 requiring
that intermediate certificates must either be technically constrained or
be audited and publicly disclosed. Clause 11 added the requirement for
BR audits (ETSI: DVCP and OVCP certificate policies for publicly trusted
certificates - baseline requirements, WebTrust: and "SSL Baseline
Requirements Audit Criteria V1.1" (as applicable to SSL certificate
issuance)).

June 2017: Mozilla published version 2.5 of its Root Store Policy[4],
which specified in section 3.1.4 that audit statements must contain the
SHA256 fingerprint of each root and intermediate certificate that was in
scope of the audit. The pre-existing requirement for public-facing audit
statements (including BR audits) for non-technically-constrained
intermediate certs continued to remain in effect as described in
sections 3.1.2 and 5.3.

April 2017: Mozilla sent a CA Communication requiring response from all
CAs[5] that stated that all audit statements submitted to Mozilla must
be public-facing (not confidential), provided in English, and must
include the SHA1 or SHA256 fingerprint of each certificate issuer
covered by the audit scope.

November 2017: Mozilla sent a CA Communication requiring response from
all CAs[6] that had action items to review and confirm compliance with
version 2.5 of Mozilla's Root Store Policy and clarified that each audit
statement must include the SHA-256 fingerprint for each root and
intermediate certificate in scope of the audit.

September 2018: : Mozilla sent a CA Communication requiring response
from all CAs[7] that stated that Mozilla would start rejecting audit
statements that did not contain the required information. The
communication also noted that version 2.6.1 of Mozilla’s Root Store
policy added clarification to section 5.3.2 that newly-issued
intermediates that are not technically constrained that have a currently
valid audit report at the time of creation of the certificate, must
appear on the CA's next periodic audit reports.

Thanks,
Kathleen

[1] https://wiki.mozilla.org/CA/Root_Store_Policy_Archive
[2] https://wiki.mozilla.org/CA/Communications
[3] https://wiki.mozilla.org/CA:CertInclusionPolicyV2.1
[4] https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
[5] https://wiki.mozilla.org/CA/Communications#April_2017
[6]
https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication
[7]
https://wiki.mozilla.org/CA/Communications#September_2018_CA_Communication

[Kathleen Wilson]

On 10/8/19 12:50 PM, Kathleen Wilson wrote:
> CAs,
>
> There is now an "Audit Letter Validation (ALV)" button on intermediate
> certificate records in the CCADB. There is also a new task list item on
> your home page. In the summary section you will see a line item like the
> following.
>     "Intermediate Certs with Failed ALV Results: 8"
> When that is non-zero, you will see a section that can be opened called
> "Check failed Audit Letter Validation (ALV) results"
>

CAs,

We have added a report called "My Certs Failed Audit Letter Validation"
that is available to CAs via the 'Reports' tab in the 'CA Community
Reports' folder. It is the same report as the "Check failed Audit Letter
Validation (ALV) results" task list item.

Filtered By:((1 AND 2 AND 3 AND 4 AND (5 OR 6) AND (7 OR 8)) AND 9) AND 10
1. CA Owner/Certificate Record Type equals Intermediate Certificate
2. Revocation Status equals Not Revoked
3. OneCRL Status not equal to Added to OneCRL
4. Valid To (GMT) greater than TODAY
5. Standard Audit ALV Found Cert equals FAIL
6. BR Audit ALV Found Cert equals FAIL
7. Mozilla Root Status equals Change Requested,Included
8. Microsoft Root Status equals Included,Change Requested
9. Technically Constrained equals False
10. Match Running User's Owner equals True

Columns: Certificate Name, SHA-256 Fingerprint, Audits Same as Parent,
Mozilla Root Status, Microsoft Root Status, Standard Audit ALV Results,
Standard Audit ALV Comments, BR Audit ALV Results, BR Audit ALV Comments


Thanks to those of you who have been proactively looking into the ALV
results for your intermediate certificates.

Thanks,
Kathleen

[Kathleen Wilson]

CAs,

Here's additional information based on questions I've received about
what to do if you determine that an intermediate certificate is not
listed in an audit statement that it should have been in.

When an intermediate certificate is not listed in all of the necessary
audit reports, it is a violation of Mozilla’s Root Store Policy and an
incident report[1] must be filed via a Bugzilla Bug which must list the
steps your CA is taking to resolve the situation.

For example, it is a violation of section 8 of the CA/Browser Forum
Baseline Requirements (BRs) and of Mozilla's Root Store Policy when
there have been no BR audits for an intermediate certificate that is not
technically constrained[2] via Extended Key Usage (EKU) and Name
Constraints (and chains up to a root certificate that has the Websites
trust bit enabled in Mozilla’s program).

Each copy or doppelganger (same Subject+SPKI) intermediate certificate
must have their SHA-256 Fingerprint listed in appropriate audit
statements, according to each of their EKU or inherited trust (Derived
Trust Bits). Certificates that are cross-signed versions of a root
certificate also must have their SHA-256 Fingerprints specifically
listed in the applicable audit statements, because these are also
intermediate certificates.

Acceptable remediation for an intermediate certificate missing BR audits
may include one or more of the following:

1. Have your auditor issue a revised report that includes the
intermediate certificate. Note that if the certificate has been in
existence for multiple past audit periods, this will not be considered a
full remediation unless new reports are supplied for all of those
periods in which the certificate did not appear on the original reports.

2. Revoke the intermediate certificate in accordance with BR section 4.9.
If your CA decides not to revoke the certificate within the timeline
specified by the BRs, then that is another incident, which must also be
addressed in an Incident Report. Note that this may be handled in the
same Bugzilla bug regarding the missing audits.

3. If the intermediate certificate is technically capable but not
intended for TLS issuance, and revocation is not imminent, you may
request that Mozilla add it to OneCRL by adding a comment to the
Bugzilla bug with the request and sending email to me.
Note: While adding the certificate to OneCRL satisfies Mozilla's
expectations for remediation, it may not satisfy other root store
programs. You are advised to seek their guidance on this issue.

Thanks,
Kathleen

[1] https://wiki.mozilla.org/CA/Responding_To_An_Incident
[2]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#531-technically-constrained

[Ryan Sleevi]

(Writing in an official capacity for the Google/Chrome Root Program)

There are still a remarkable number of CAs that have not filed incident
reports and not yet remediated this issue.

A reminder, the Baseline Requirements, Section 8.1, states:

> Certificates that are capable of being used to issue new certificates MUST
> either be Technically Constrained in line
> with section 7.1.5 and audited in line with section 8.7 only, or
> Unconstrained and fully audited in line with all
> remaining requirements from this section.
>
> *A Certificate is deemed as capable of being used to issue new
> certificatesif it contains an X.509v3 basicConstraints extension, with the
> cA boolean set to true and is therefore by definition aRoot CA Certificate
> or a Subordinate CA Certificate*.


Section 8.6 requires that this audit report be public.

Section 2.2 of the BRs includes the following:

> The CA SHALL publicly give effect to these Requirements and represent that
> it will adhere to the latest
> published version


Section 4.9.1.2 of the BRs includes the following:

> The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7)
> days if one or more of the
> following occurs:

5. The Issuing CA is made aware that the Certificate was not issued in
> accordance with or that
> Subordinate CA has not complied with this document or the applicable
> Certificate Policy or Certification
> Practice Statement;


The failure to provide public audit statements that give effect to the
coverage of these certificates, in scope of the BRs by definition, is a
violation of the BRs, and ergo a violation of a CA's CP/CPS, and *MUST* be
revoked.

Our expectation is that CAs will be filing incident reports for:
1) The failure to include and document as in-scope within the relevant audit
2) If the CA fails to revoke within the time period required by the BRs,
the failure to revoke within the BR time period

As two separate reports.

We encourage CAs to carefully examine these reports and provide updates as
to their planned revocations.

[Kathleen Wilson]

All,

As Ryan points out, root store operators enforce the BRs in different ways.

Ryan wrote:
> (Writing in an official capacity for the Google/Chrome Root Program)

> <snip>

> Our expectation is that CAs will be filing incident reports for:
> 1) The failure to include and document as in-scope within the relevant
> audit
> 2) If the CA fails to revoke within the time period required by the
> BRs,
> the failure to revoke within the BR time period
>
> As two separate reports.
>
> We encourage CAs to carefully examine these reports and provide
> updates as
> to their planned revocations.

My understanding is that Google’s root store expectations differ from
Mozilla’s root store expectations regarding handling of
non-technically-constrained intermediate certificates missing BR audits
in 2 ways.

1) Mozilla is currently okay with the incident report for not revoking
the non-BR-audited non-technically-constrained intermediate certificates
to be handled in the same Bugzilla bug as the missing-audits incident
report. However, I interpret Ryan’s message to mean that Google would
like those to be two separate Bugzilla Bugs.

Note: I will add a report to
wiki.mozilla.org/CA/Intermediate_Certificates to list all of the
intermediate certificates that have been added to OneCRL and their
revocation status. This will enable the CA Community to identify which
certificates have been added to OneCRL but are not actually revoked.

2) From Mozilla’s perspective, adding a non-technically-constrained
intermediate certificate to Mozilla’s OneCRL (only consumed by Firefox)
means that the BRs become out of scope for that certificate. So Mozilla
does not require that certificate to be revoked.

Thanks,
Kathleen

[Kathleen Wilson]

On 11/19/19 4:59 PM, Kathleen Wilson wrote:
> Note: I will add a report to
> wiki.mozilla.org/CA/Intermediate_Certificates to list all of  the
> intermediate certificates that have been added to OneCRL and their
> revocation status. This will enable the CA Community to identify which
> certificates have been added to OneCRL but are not actually revoked.

The report is available now.

https://wiki.mozilla.org/CA/Intermediate_Certificates
~~
The following reports list the intermediate certificates that have been
added to OneCRL, and their revocation status as indicated by the CA in
the CCADB.

Intermediate CA Certificates in OneCRL (HTML)
Intermediate CA Certificates in OneCRL (CSV)
~~

Direct links:
https://ccadb-public.secure.force.com/mozilla/IntermediateCertsInOneCRLReport
https://ccadb-public.secure.force.com/mozilla/IntermediateCertsInOneCRLReportCSV

[Kathleen Wilson]

On 10/29/19 12:46 PM, Kathleen Wilson wrote:

> When an intermediate certificate is not listed in all of the necessary
> audit reports, it is a violation of Mozilla’s Root Store Policy and an
> incident report[1] must be filed via a Bugzilla Bug which must list the
> steps your CA is taking to resolve the situation.
>
> For example, it is a violation of section 8 of the CA/Browser Forum
> Baseline Requirements (BRs) and of Mozilla's Root Store Policy when
> there have been no BR audits for an intermediate certificate that is not
> technically constrained[2] via Extended Key Usage (EKU) and Name
> Constraints (and chains up to a root certificate that has the Websites
> trust bit enabled in Mozilla’s program).
>
> Each copy or doppelganger (same Subject+SPKI) intermediate certificate
> must have their SHA-256 Fingerprint listed in appropriate audit
> statements, according to each of their EKU or inherited trust (Derived
> Trust Bits). Certificates that are cross-signed versions of a root
> certificate also must have their SHA-256 Fingerprints specifically
> listed in the applicable audit statements, because these are also
> intermediate certificates.
>

All,

Email that I wrote years ago should NOT be considered as granting anyone
exceptions to following the current version of the BRs and Mozilla's
root store policy.

It is the CA's responsibility to resolve problems that they were aware
of years ago, but which are no longer acceptable. Things have changed,
policies have changed, ability to identify problems and enforce policy
have changed.

CAs should have been keeping track of and resolving their own known
problems in regards to not fully following the BRs and Mozilla policy.
For example, I expect that a situation in which I responded with an OK
in 2016 would have been corrected in the 3 years since that email was
written.

Thanks,
Kathleen

[Nick Lamb]

On Mon, 25 Nov 2019 14:12:46 -0800
Kathleen Wilson via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> CAs should have been keeping track of and resolving their own known
> problems in regards to not fully following the BRs and Mozilla
> policy. For example, I expect that a situation in which I responded
> with an OK in 2016 would have been corrected in the 3 years since
> that email was written.

Perhaps to this end it would be useful for Mozilla's periodic survey
letters to always ask each CA to list any exceptional circumstances they
believe currently apply to them?

This would act both as a reminder to Mozilla of any such exceptions
which they granted but may have assumed meanwhile ceased to be
relevant, AND to the CA of any such exceptions upon which they find
themselves still relying.

The publication of CA responses is an opportunity for Mozilla, Peers
and the wider community to comment on any discrepancy.


Nick.

[Wayne Thayer]

On Tue, Nov 26, 2019 at 6:10 PM Nick Lamb via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Mon, 25 Nov 2019 14:12:46 -0800
> Kathleen Wilson via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
> > CAs should have been keeping track of and resolving their own known
> > problems in regards to not fully following the BRs and Mozilla
> > policy. For example, I expect that a situation in which I responded
> > with an OK in 2016 would have been corrected in the 3 years since
> > that email was written.
>
> Perhaps to this end it would be useful for Mozilla's periodic survey
> letters to always ask each CA to list any exceptional circumstances they
> believe currently apply to them?
>
>

We've included a question about complying with the intermediate audit
requirements in the January survey, but not a more general question about
exceptions. I feel that an open-ended question such as this will be
confusing for CAs to answer, and moreover I don't want to create the
impression that Mozilla grants exceptions for policy violations because, as
a general rule, we don't.

[Nick Lamb]

On Thu, 19 Dec 2019 10:23:19 -0700
Wayne Thayer via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> We've included a question about complying with the intermediate audit
> requirements in the January survey, but not a more general question
> about exceptions. I feel that an open-ended question such as this
> will be confusing for CAs to answer, and moreover I don't want to
> create the impression that Mozilla grants exceptions for policy
> violations because, as a general rule, we don't.

As a general rule you don't grant exceptions, and so exceptions are
let's say, an exception to that general rule? Hence the name.

So, to the same end as my original proposal, I recommend instead that
Mozilla personalizes any CA survey sent out to a CA which they believe
currently benefits from any such exceptions - setting out what those
exceptions to its rules are for that CA. And in all communications the
text should be clear that any exceptions the CA believed were in place
are in fact spent as far as Mozilla is concerned unless they are
enumerated in this communication.

In the event there are in fact NO exceptions, that's just one small
tweak to the text.

In the event that one or two CAs benefit from some minor exception
which still has force, it's a little bit of work, and in the process a
firm reminder to both Mozilla and the CA of the ongoing price of such
exceptions.

And in the event that it's actually dozens of exceptions across many or
most CAs I hope the realisation of the effort involved will cause Wayne
to reconsider his previous claim that "as a general rule, we don't".

One valuable opportunity from m.d.s.policy is for CAs to learn from
each others mistakes and in doing so avoid making the same or similar
mistakes themselves. But Mozilla has opportunities to learn from
mistakes here too, and I feel as though the mismatch between Kathleen's
expectation (that a situation should have "resolved" since 2016) and
the CA's understanding (that this constituted an indefinite exception
to Mozilla policy) is such a mistake.


Nick.

[Peter Bowen]

On Thu, Dec 19, 2019 at 9:23 AM Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Tue, Nov 26, 2019 at 6:10 PM Nick Lamb via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> > On Mon, 25 Nov 2019 14:12:46 -0800
> > Kathleen Wilson via dev-security-policy
> > <dev-secur...@lists.mozilla.org> wrote:
> >
> > > CAs should have been keeping track of and resolving their own known
> > > problems in regards to not fully following the BRs and Mozilla
> > > policy. For example, I expect that a situation in which I responded
> > > with an OK in 2016 would have been corrected in the 3 years since
> > > that email was written.
> >
> > Perhaps to this end it would be useful for Mozilla's periodic survey
> > letters to always ask each CA to list any exceptional circumstances they
> > believe currently apply to them?
>

> We've included a question about complying with the intermediate audit
> requirements in the January survey, but not a more general question about
> exceptions. I feel that an open-ended question such as this will be
> confusing for CAs to answer, and moreover I don't want to create the
> impression that Mozilla grants exceptions for policy violations because, as
> a general rule, we don't.

> This would act both as a reminder to Mozilla of any such exceptions
> > which they granted but may have assumed meanwhile ceased to be
> > relevant, AND to the CA of any such exceptions upon which they find
> > themselves still relying.
> >
> > The publication of CA responses is an opportunity for Mozilla, Peers
> > and the wider community to comment on any discrepancy.
>

Maybe rather than including it in the survey, Mozilla should make a
requirement that exception information be included in the yearly
reporting? It could simply be a separate letter from the CA management
requesting a continuation of the exception or could be a statement of
excluded topics in the auditor's report, depending on the situation and
structure of the audit.

Thanks,
Peter

[Wayne Thayer]

On Sat, Dec 21, 2019 at 11:30 AM Nick Lamb <n...@tlrmx.org> wrote:

> On Thu, 19 Dec 2019 10:23:19 -0700

> Wayne Thayer via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
> > We've included a question about complying with the intermediate audit
> > requirements in the January survey, but not a more general question
> > about exceptions. I feel that an open-ended question such as this
> > will be confusing for CAs to answer, and moreover I don't want to
> > create the impression that Mozilla grants exceptions for policy
> > violations because, as a general rule, we don't.
>

> As a general rule you don't grant exceptions, and so exceptions are
> let's say, an exception to that general rule? Hence the name.
>
>

Nope. The point is that we have no systematic process for handling
exceptions, and to the best of my knowledge no list of granted exceptions
exists. It's not even clear what constitutes an exception. Is any policy
violation an exception? Does a certificate that was misissued 23 months ago
but not revoked constitute an exception? Are the Symantec subordinates that
are allow-listed exceptions? Is an exception something that a Mozilla
representative interpreted for a CA as being permitted? Is an exception
narrowly defined as something that Mozilla agreed to in writing?

We may have been more liberal in making exceptions in the past, but I have
hopefully been consistent in stating that it is the CA's responsibility to
decide what to do and inform us rather than ask for permission.

So, to the same end as my original proposal, I recommend instead that
> Mozilla personalizes any CA survey sent out to a CA which they believe
> currently benefits from any such exceptions - setting out what those
> exceptions to its rules are for that CA. And in all communications the
> text should be clear that any exceptions the CA believed were in place
> are in fact spent as far as Mozilla is concerned unless they are
> enumerated in this communication.
>
>

This is challenging because no list of exceptions exists and because I'm
not aware of a way to perform this type of customization in our survey
system (I'll confirm with Kathleen).

In the event there are in fact NO exceptions, that's just one small
> tweak to the text.
>
>

But potentially a very confusing tweak, unless we define what we mean by an
exception. I suggest that we modify question #1 to require CAs to attest
that they intend to FULLY comply with version 2.7 of the policy and if they
won't fully comply, to list all non-conforrmities. In other words, define
an exception as anything that isn't compliant with the current policy
rather than something we granted in the past.

In the event that one or two CAs benefit from some minor exception
> which still has force, it's a little bit of work, and in the process a
> firm reminder to both Mozilla and the CA of the ongoing price of such
> exceptions.
>
>

Not to mention a good argument that exceptions are unfair.

And in the event that it's actually dozens of exceptions across many or
> most CAs I hope the realisation of the effort involved will cause Wayne

> to reconsider his previous claim that "as a general rule, we don't".
>
>
I agree that it would be valuable to know if this is the case.

One valuable opportunity from m.d.s.policy is for CAs to learn from
> each others mistakes and in doing so avoid making the same or similar
> mistakes themselves. But Mozilla has opportunities to learn from
> mistakes here too, and I feel as though the mismatch between Kathleen's
> expectation (that a situation should have "resolved" since 2016) and
> the CA's understanding (that this constituted an indefinite exception
> to Mozilla policy) is such a mistake.
>
>

I agree.


> Nick.
>

[Nick Lamb]

On Mon, 23 Dec 2019 14:20:16 -0700

Wayne Thayer via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> I suggest that we modify question #1 to require CAs
> to attest that they intend to FULLY comply with version 2.7 of the
> policy and if they won't fully comply, to list all non-conforrmities.
> In other words, define an exception as anything that isn't compliant
> with the current policy rather than something we granted in the past.

Thanks Wayne, I believe this would achieve my broader goals without
being too onerous for you/ Mozilla or the CAs.

I look forward to any discussions prompted by the modified question or
by non-comformities disclosed as a result.


Nick.

[Wayne Thayer]

I've modified the first question of the survey and added a response option
for exceptions:
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J00003waNOW

[Kathleen Wilson]

On 10/8/19 12:50 PM, Kathleen Wilson wrote:

> There is now an "Audit Letter Validation (ALV)" button on intermediate
> certificate records in the CCADB. There is also a new task list item on
> your home page.

I have added the following wiki page to provide instructions about ALV.

https://wiki.mozilla.org/CA/Audit_Letter_Validation

As always, I will greatly appreciate your constructive feedback on it.

Thanks,
Kathleen