Question about BR Commitment to Comply

[Kathleen Wilson]

All,

https://wiki.mozilla.org/CA:BaselineRequirements
Currently says: "The CA's CP or CPS documents must include a commitment
to comply with the BRs, as described in BR section 8.3."

I have been asked if a CA can have their Webtrust audit statement
indicate their commitment to comply with the BRs, rather than putting
the commitment to comply statement in the CP/CPS.

Here are the reason:

1) We are not a member of CAB/Forum and do not have any mutual agreement
that can bind the obligations and responsibilities of both parties. It
seems that the BR keeps changing very often.

2) The requirement of BR section 8.3 is quite weird as there is no such
requirement in other audit criteria such as WebTrust. Would it be a
marketing requirement rather than a technical requirement?

3) Further to (1) above, the proposed statement in BR section 8.3 also
requires CA to adhere to the latest published version. But nobody can
assure compliance with it all the time. Even if a particular version
number could be stated, practically it'll take quite a long time to
modify our CPS just due to some minor changes in BR by CAB/Forum.

4) On the other hand, since CAs are required to perform Webtrust audit
annually anyway, it seems more appropriate for the Webtrust audit
statement to disclose which version of BR that the CA adhere to.

I will appreciate your thoughtful and constructive suggestions about this.

Thanks,
Kathleen

[Jeremy Rowley]

Some initial thoughts:

1) Membership in the CAB Forum is not required for a CA to commit to complying with the BR, and if non-membership avoids any obligation to comply with the BRs, I think you'll quickly see a mass exodus from the group. No member of the CAB Forum is bound to its requirements by agreement or through participation. Instead, the requirements are only imposed by the browsers are part of their root programs.
2) The goal of Section 8.3 is for the CA to inform the public about which certs are being issued in compliance with the BRs and which are not. It's not a marketing requirement. It's a technical requirement to provide relying parties (and browsers) information about how the CA operates. Section 8.3 basically requires the CA to assert that it is doing the MINIMUM required to issue certs. Any CA unwilling to assert this should not be issuing trusted certs.
3) Every CA should comply with the latest version of BRs. CAs who are so inflexible that they can't keep up with the "minor" changes made by the CAB Forum really shouldn't be issuing certs. Recent "minor" changes include deprecation of 1024 bit certs, SHA2 migration, deprecation of internal names, etc. These are pretty important issues, all of which should be promptly implemented by CAs when adopted.
4) Although relying parties might not frequently review audit reports and CPS docs, the Mozilla community does look at CPS docs. Asserting compliance in the CPS lets the community know the criteria under which the CA is operated and permits them to compare the CPS to a third party standard. Without the assertion, the CA isn't telling you anything about which policy they are operating under.

Obviously, I think an exception to this simple requirement is a mistake.

Jeremy

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Matt Palmer]

Hi Kathleen,

On Wed, Jan 28, 2015 at 02:49:22PM -0800, Kathleen Wilson wrote:
> https://wiki.mozilla.org/CA:BaselineRequirements
> Currently says: "The CA's CP or CPS documents must include a commitment to
> comply with the BRs, as described in BR section 8.3."
>
> I have been asked if a CA can have their Webtrust audit statement indicate
> their commitment to comply with the BRs, rather than putting the commitment
> to comply statement in the CP/CPS.

None of the reasons given for failing to assert a commitment to comply with
the CAB Forum BRs are persuasive to me. I'd like to re-emphasise Jeremy's
point that a CA which can't remain flexible enough to keep abreast of the
gradual pace of change of the BRs cannot, IMO, be trusted to deal with a
large-scale security problem which could happen at any time. It isn't even
a reasonable argument that the BRs could change unexpectedly -- all CAB
Forum actions are done in public (literally), so a CA which isn't a member
of the Forum can keep an eye on what's being considered.

- Matt

[Man Ho (Certizen)]

-- Man Ho

On 1/29/2015 7:10 AM, Jeremy Rowley wrote:
> Some initial thoughts:
>
> 1) Membership in the CAB Forum is not required for a CA to commit to complying with the BR, and if non-membership avoids any obligation to comply with the BRs, I think you'll quickly see a mass exodus from the group. No member of the CAB Forum is bound to its requirements by agreement or through participation. Instead, the requirements are only imposed by the browsers are part of their root programs.

The question is only whether a CA can have their Webtrust audit

statement indicate their commitment to comply with the BRs, rather than

putting the commitment to comply statement in the CP/CPS. Therefore, the
CA is still required to comply with BR according to Webtrust audit.

> 2) The goal of Section 8.3 is for the CA to inform the public about which certs are being issued in compliance with the BRs and which are not. It's not a marketing requirement. It's a technical requirement to provide relying parties (and browsers) information about how the CA operates. Section 8.3 basically requires the CA to assert that it is doing the MINIMUM required to issue certs. Any CA unwilling to assert this should not be issuing trusted certs.

The CA's assertion to issue certificate in accordance to BR is REQUIRED
by Webtrust audit anyway. The assertion is also publicly disclosed with
the audit report. Again, the question is only whether a CA should put a
statement in the CP/CPS as section 8.3 required. If yes, it is a
marketing requirement, because not aware of other audit requirements or
standardization bodies that have such requirement, e.g. Webtrust, ETSI,
even Mozilla's CP itself.

> 3) Every CA should comply with the latest version of BRs. CAs who are so inflexible that they can't keep up with the "minor" changes made by the CAB Forum really shouldn't be issuing certs. Recent "minor" changes include deprecation of 1024 bit certs, SHA2 migration, deprecation of internal names, etc. These are pretty important issues, all of which should be promptly implemented by CAs when adopted.

Exactly. Changes in BR may be "minor" or "important" from different
point of views. A CA may be in trouble of making a false statement in
its CP/CPS if the latest version of BR suddenly changed. Worst of all,
the BR is suddenly changed just before annual audit. But of course, the
"minor" changes that you have mentioned should have already fulfilled by
CAs.

> 4) Although relying parties might not frequently review audit reports and CPS docs, the Mozilla community does look at CPS docs. Asserting compliance in the CPS lets the community know the criteria under which the CA is operated and permits them to compare the CPS to a third party standard. Without the assertion, the CA isn't telling you anything about which policy they are operating under.

I think Mozilla community should have no problem looking at Webtrust
report and CA's assertion to which version of BR since it's required by
Mozilla's CP. I understand that Kathleen is somehow maintaining a
spreadsheet of CA audits, isn't it? This approach is actually a better
alternative.

>
> Obviously, I think an exception to this simple requirement is a mistake.

Obviously I don't think that section 8.3 of BR is a simple requirement.

>
> Jeremy
>
>
>
>
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Kathleen Wilson
> Sent: Wednesday, January 28, 2015 3:49 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Question about BR Commitment to Comply
>
> All,
>

> https://wiki.mozilla.org/CA:BaselineRequirements
> Currently says: "The CA's CP or CPS documents must include a commitment to comply with the BRs, as described in BR section 8.3."
>
> I have been asked if a CA can have their Webtrust audit statement indicate their commitment to comply with the BRs, rather than putting the commitment to comply statement in the CP/CPS.
>

[Kurt Roeckx]

On 2015-01-28 23:49, Kathleen Wilson wrote:
> All,
>
> https://wiki.mozilla.org/CA:BaselineRequirements
> Currently says: "The CA's CP or CPS documents must include a commitment
> to comply with the BRs, as described in BR section 8.3."

section 8.3 says:
| The CA SHALL publicly give effect to these Requirements and represent
| that it will adhere to the latest published version. The CA MAY
| fulfill this requirement by incorporating these Requirements directly
| into its Certificate Policy and/or Certification Practice Statements
| or by incorporating them by reference [...]

So it says they must commit to it. It does not say it must be in the CP
or CPS, it just recommends to put it there since it's the most obvious
place to put it. But I think any document created the by CA that says
so should be fine.

> I have been asked if a CA can have their Webtrust audit statement
> indicate their commitment to comply with the BRs, rather than putting
> the commitment to comply statement in the CP/CPS.

Isn't an audit statement done by an auditor? How can an auditor
indicate that the CA is committed to doing it? It's the CA that needs
to commit to it.

> 1) We are not a member of CAB/Forum and do not have any mutual agreement
> that can bind the obligations and responsibilities of both parties.

I don't see how that is relevant. The CAB/Forum is just like any other
standard body. If you wish you can join it, but you're not required to.

The obligations and responsibilities are not with CAB/Forum, but with
the the of the world that would use the certificates.

> 2) The requirement of BR section 8.3 is quite weird as there is no such
> requirement in other audit criteria such as WebTrust. Would it be a
> marketing requirement rather than a technical requirement?

I see this as a pure technical requirement that you will follow the
requirements, and that you will follow the new requirements. I see no
other reason why you would be forced to follow them other then that you
say you will.

> 3) Further to (1) above, the proposed statement in BR section 8.3 also
> requires CA to adhere to the latest published version. But nobody can
> assure compliance with it all the time. Even if a particular version
> number could be stated, practically it'll take quite a long time to
> modify our CPS just due to some minor changes in BR by CAB/Forum.

When they adopt something, they also give you a reasonable time to
comply with those changes.

> 4) On the other hand, since CAs are required to perform Webtrust audit
> annually anyway, it seems more appropriate for the Webtrust audit
> statement to disclose which version of BR that the CA adhere to.

I think that the webtrust audit is also based on a certain version of
the BR and that they might not have been updated yet to check the latest
version. So I think the audit report should indicate which version was
checked. If an audit was not for the last version that doesn't mean CA
shouldn't already be complying with the later version or be working on
complying with it.


Kurt

[Jeremy Rowley]

> Some initial thoughts:
>
> 1) Membership in the CAB Forum is not required for a CA to commit to complying with the BR, and if non-membership avoids any obligation to comply with the BRs, I think you'll quickly see a mass exodus from the group. No member of the CAB Forum is bound to its requirements by agreement or through participation. Instead, the requirements are only imposed by the browsers are part of their root programs.
The question is only whether a CA can have their Webtrust audit statement indicate their commitment to comply with the BRs, rather than putting the commitment to comply statement in the CP/CPS. Therefore, the CA is still required to comply with BR according to Webtrust audit.

[JR] No - as Kurt mentioned, the CA is attesting to its compliance, not the auditors. Putting it in the audit statement doesn't make sense as the audit statement is only the auditors opining on your compliance with whatever audit criteria is relevant not the CA's assertion of compliance.

> 2) The goal of Section 8.3 is for the CA to inform the public about which certs are being issued in compliance with the BRs and which are not. It's not a marketing requirement. It's a technical requirement to provide relying parties (and browsers) information about how the CA operates. Section 8.3 basically requires the CA to assert that it is doing the MINIMUM required to issue certs. Any CA unwilling to assert this should not be issuing trusted certs.
The CA's assertion to issue certificate in accordance to BR is REQUIRED by Webtrust audit anyway. The assertion is also publicly disclosed with the audit report. Again, the question is only whether a CA should put a statement in the CP/CPS as section 8.3 required. If yes, it is a marketing requirement, because not aware of other audit requirements or standardization bodies that have such requirement, e.g. Webtrust, ETSI, even Mozilla's CP itself.

[JR] Not true. Audits can have restricted scope and only cover the CA's compliance with its CPS. Not all audit reports are clear on what parts of the audit covered which certs.

> 3) Every CA should comply with the latest version of BRs. CAs who are so inflexible that they can't keep up with the "minor" changes made by the CAB Forum really shouldn't be issuing certs. Recent "minor" changes include deprecation of 1024 bit certs, SHA2 migration, deprecation of internal names, etc. These are pretty important issues, all of which should be promptly implemented by CAs when adopted.
Exactly. Changes in BR may be "minor" or "important" from different point of views. A CA may be in trouble of making a false statement in its CP/CPS if the latest version of BR suddenly changed. Worst of all, the BR is suddenly changed just before annual audit. But of course, the "minor" changes that you have mentioned should have already fulfilled by CAs.

[JR] That's my point. Minor is not in the discretion of the CA. If the CA/Browser Forum adopted a change, there was a probably a good reason behind it. Also, as Kurt mentioned, changes restricting a practice are always enacted with a lead time to give CAs time to comply. Truly minor changes (those without a lead time) don't restrict a CAs practices, just permit additional ways for compliance.

> 4) Although relying parties might not frequently review audit reports and CPS docs, the Mozilla community does look at CPS docs. Asserting compliance in the CPS lets the community know the criteria under which the CA is operated and permits them to compare the CPS to a third party standard. Without the assertion, the CA isn't telling you anything about which policy they are operating under.
I think Mozilla community should have no problem looking at Webtrust report and CA's assertion to which version of BR since it's required by Mozilla's CP. I understand that Kathleen is somehow maintaining a spreadsheet of CA audits, isn't it? This approach is actually a better alternative.

[JR] There's a lot more relying parties than the Mozilla community. Not only that, but many CAs have confusing CPS docs making it difficult to know exactly which certs comply with which policy. The assertion is an easy way for reviewers to understand when the CA is complying with the BRs and they are not. Plus, it's a representation that the CA understands the requirements and the importance of compliance. It makes the CA set forth when exactly it's deviating from the BRs (such as for code signing and clients, which are not covered by the BRs) rather leaving reviewers guessing about which policy is applicable.

>
> Obviously, I think an exception to this simple requirement is a mistake.
Obviously I don't think that section 8.3 of BR is a simple requirement.

[JR] Which tells me either you don't want to comply with the BRs (which is bad), you don't have control over the CP (which is also bad for someone going through the Mozilla program), or there is some third reason? Why can't the CA assert BR compliance? Non-compliance with the BRs SHOULD be public knowledge (not hidden) so concerned Internet citizens can choose whether to trust that CA.

[Jeremy Rowley]

Kurt said "I think that the webtrust audit is also based on a certain version of the BR and that they might not have been updated yet to check the latest version. So I think the audit report should indicate which version was checked. If an audit was not for the last version that doesn't mean CA shouldn't already be complying with the later version or be working on complying with it."

- I think adding clarity around version is a good idea. The audit reports tell you the date and, based on the date, you can tell which audit criteria was used. However, the audit reports would improve if they specifically mentioned which version of the BRs applied to the audit. ETSI and Webtrust audit criteria lag about six months to one year behind adoption of the standards so this info would be very useful when looking at a CA's practices and CPS.

[Man Ho (Certizen)]

On 1/30/2015 5:59 AM, Jeremy Rowley wrote:
>> Some initial thoughts:
>>
>> 1) Membership in the CAB Forum is not required for a CA to commit to complying with the BR, and if non-membership avoids any obligation to comply with the BRs, I think you'll quickly see a mass exodus from the group. No member of the CAB Forum is bound to its requirements by agreement or through participation. Instead, the requirements are only imposed by the browsers are part of their root programs.
> The question is only whether a CA can have their Webtrust audit statement indicate their commitment to comply with the BRs, rather than putting the commitment to comply statement in the CP/CPS. Therefore, the CA is still required to comply with BR according to Webtrust audit.
> [JR] No - as Kurt mentioned, the CA is attesting to its compliance, not the auditors. Putting it in the audit statement doesn't make sense as the audit statement is only the auditors opining on your compliance with whatever audit criteria is relevant not the CA's assertion of compliance.

[MH] If that's the case, the trustworthiness of a Webtrust audit would
be weakened. Auditors should obtain the CA's assertion of compliance,
and assess whether it's reasonable with respect to the CA's CP/CPS and
the target scope of audit (i.e. the BR). And finally give their opinions
in Webtrust audit report for public knowledge.

>
>> 2) The goal of Section 8.3 is for the CA to inform the public about which certs are being issued in compliance with the BRs and which are not. It's not a marketing requirement. It's a technical requirement to provide relying parties (and browsers) information about how the CA operates. Section 8.3 basically requires the CA to assert that it is doing the MINIMUM required to issue certs. Any CA unwilling to assert this should not be issuing trusted certs.
> The CA's assertion to issue certificate in accordance to BR is REQUIRED by Webtrust audit anyway. The assertion is also publicly disclosed with the audit report. Again, the question is only whether a CA should put a statement in the CP/CPS as section 8.3 required. If yes, it is a marketing requirement, because not aware of other audit requirements or standardization bodies that have such requirement, e.g. Webtrust, ETSI, even Mozilla's CP itself.
> [JR] Not true. Audits can have restricted scope and only cover the CA's compliance with its CPS. Not all audit reports are clear on what parts of the audit covered which certs.
>
>> 3) Every CA should comply with the latest version of BRs. CAs who are so inflexible that they can't keep up with the "minor" changes made by the CAB Forum really shouldn't be issuing certs. Recent "minor" changes include deprecation of 1024 bit certs, SHA2 migration, deprecation of internal names, etc. These are pretty important issues, all of which should be promptly implemented by CAs when adopted.
> Exactly. Changes in BR may be "minor" or "important" from different point of views. A CA may be in trouble of making a false statement in its CP/CPS if the latest version of BR suddenly changed. Worst of all, the BR is suddenly changed just before annual audit. But of course, the "minor" changes that you have mentioned should have already fulfilled by CAs.
> [JR] That's my point. Minor is not in the discretion of the CA. If the CA/Browser Forum adopted a change, there was a probably a good reason behind it. Also, as Kurt mentioned, changes restricting a practice are always enacted with a lead time to give CAs time to comply. Truly minor changes (those without a lead time) don't restrict a CAs practices, just permit additional ways for compliance.

[MH] Requiring CA to comply with BRs is good thing. But I also point out
that once a CA put a statement of compliance with "latest version" of
BRs in CP/CPS, the CA has committed to public that it "has already
complied" with all potential changes of BRs at all time. That may be a
false statement. The proper approach is for Mozilla's CP to require the
CA to perform audit on the latest version of BR. And the audit report
must state which version of BR that the CA adhere to.

>
>> 4) Although relying parties might not frequently review audit reports and CPS docs, the Mozilla community does look at CPS docs. Asserting compliance in the CPS lets the community know the criteria under which the CA is operated and permits them to compare the CPS to a third party standard. Without the assertion, the CA isn't telling you anything about which policy they are operating under.
> I think Mozilla community should have no problem looking at Webtrust report and CA's assertion to which version of BR since it's required by Mozilla's CP. I understand that Kathleen is somehow maintaining a spreadsheet of CA audits, isn't it? This approach is actually a better alternative.
> [JR] There's a lot more relying parties than the Mozilla community. Not only that, but many CAs have confusing CPS docs making it difficult to know exactly which certs comply with which policy. The assertion is an easy way for reviewers to understand when the CA is complying with the BRs and they are not. Plus, it's a representation that the CA understands the requirements and the importance of compliance. It makes the CA set forth when exactly it's deviating from the BRs (such as for code signing and clients, which are not covered by the BRs) rather leaving reviewers guessing about which policy is applicable.

[MH] CA's assertion is a mandatory requirement of Webtrust audit. If an
auditor has prepared the audit report, it should be no doubt.

>
>> Obviously, I think an exception to this simple requirement is a mistake.
> Obviously I don't think that section 8.3 of BR is a simple requirement.
> [JR] Which tells me either you don't want to comply with the BRs (which is bad), you don't have control over the CP (which is also bad for someone going through the Mozilla program), or there is some third reason? Why can't the CA assert BR compliance? Non-compliance with the BRs SHOULD be public knowledge (not hidden) so concerned Internet citizens can choose whether to trust that CA.

[MH] On the contrary, we want to comply with the BRs. We do have very
stringent control over our CP/CPS, which does not allow to over-commit a
practice to public. If there is non-compliance, they will be disclosed
in a public Webtrust audit report.

[Jeremy Rowley]

Snipped to try and make the convo less confusing.

[MH] If that's the case, the trustworthiness of a Webtrust audit would be weakened. Auditors should obtain the CA's assertion of compliance, and assess whether it's reasonable with respect to the CA's CP/CPS and the target scope of audit (i.e. the BR). And finally give their opinions in Webtrust audit report for public knowledge.

[JR] Per 8.3 that assertion of compliance must (and should) be made publicly. You're not representing to the auditors that the CA is compliant, you're representing compliance to the Mozilla's end users. To me, that's a very important assertion.

[MH] Requiring CA to comply with BRs is good thing. But I also point out that once a CA put a statement of compliance with "latest version" of BRs in CP/CPS, the CA has committed to public that it "has already complied" with all potential changes of BRs at all time. That may be a false statement. The proper approach is for Mozilla's CP to require the CA to perform audit on the latest version of BR. And the audit report must state which version of BR that the CA adhere to.

[JR] I agree, but the CA should also represent which version they are complying with. Audits only happen annually. Reliance on certificates is a year-around event. I want to know if the CA changes their policies to match the most current version of the BRs. Unless you have a daily audit, that only happens with a CA's assertion of compliance.

[MH] CA's assertion is a mandatory requirement of Webtrust audit. If an auditor has prepared the audit report, it should be no doubt.

[JR]Only at the time of the audit. What about the other 364 days?

[Man Ho (Certizen)]

On 1/31/2015 3:42 AM, Jeremy Rowley wrote:
> Snipped to try and make the convo less confusing.
>
> [MH] If that's the case, the trustworthiness of a Webtrust audit would be weakened. Auditors should obtain the CA's assertion of compliance, and assess whether it's reasonable with respect to the CA's CP/CPS and the target scope of audit (i.e. the BR). And finally give their opinions in Webtrust audit report for public knowledge.
> [JR] Per 8.3 that assertion of compliance must (and should) be made publicly. You're not representing to the auditors that the CA is compliant, you're representing compliance to the Mozilla's end users. To me, that's a very important assertion.

[MH] The CA's assertion of compliance with the Webtrust audit report is
also open to public. Since it is an important assertion, it must be read
together with the audit report. If a CA fails some BRs according to
"latest version" of BRs, but had already made that statement (probably
because it was true in previous version), it becomes a false statement
which in fact mislead end users.

>
> [MH] Requiring CA to comply with BRs is good thing. But I also point out that once a CA put a statement of compliance with "latest version" of BRs in CP/CPS, the CA has committed to public that it "has already complied" with all potential changes of BRs at all time. That may be a false statement. The proper approach is for Mozilla's CP to require the CA to perform audit on the latest version of BR. And the audit report must state which version of BR that the CA adhere to.
> [JR] I agree, but the CA should also represent which version they are complying with. Audits only happen annually. Reliance on certificates is a year-around event. I want to know if the CA changes their policies to match the most current version of the BRs. Unless you have a daily audit, that only happens with a CA's assertion of compliance.

[MH] BRs may be changed at any time before the next audit of a CA. For
public knowledge whether the CA would need to change its practice due to
changes of BR version, Mozilla had been doing this through Mozilla's
communications and then maintained a spreadsheet. I think it is the
better way.

>
> [MH] CA's assertion is a mandatory requirement of Webtrust audit. If an auditor has prepared the audit report, it should be no doubt.
> [JR]Only at the time of the audit. What about the other 364 days?

[MH] As you said reliance on certificates is a year-round matter. I'd
prefer to know exactly what BRs the CA has already complied, rather than
being misled by a statement for the other 364 days.
>
>
>
>

[Gervase Markham]

On 28/01/15 22:49, Kathleen Wilson wrote:
> I have been asked if a CA can have their Webtrust audit statement
> indicate their commitment to comply with the BRs, rather than putting
> the commitment to comply statement in the CP/CPS.

> Here are the reason:
>
> 1) We are not a member of CAB/Forum and do not have any mutual agreement
> that can bind the obligations and responsibilities of both parties. It
> seems that the BR keeps changing very often.

This seems like a non-sequitur. They are not refusing to comply, they
just want to change the location of the compliance statement. So why is
their lack of membership, or the rate of change, relevant?

Or are they basically saying they do not wish to be bound by the latest
version of the BRs, but only by the version current at the time of their
last audit?

If so, I'd say No. Mozilla expects all CAs in our program, whether CAB
Forum members or not, to comply with the latest version of the BRs
(taking into account any phase-in periods given in resolutions to adopt
new measures). Inability to do this might be considered indicative of
deeper problems at the CA.

It may be true that we can only have the compliance of a particular CA
checked formally once a year at audit time, but we still expect ongoing
compliance, and reserve the right to use other methods of checking it
(such as examining issued certificates).

> 2) The requirement of BR section 8.3 is quite weird as there is no such
> requirement in other audit criteria such as WebTrust. Would it be a
> marketing requirement rather than a technical requirement?

A commitment in the CA's official documents to conform to the BRs is
merely stating what should be required by Mozilla root program
membership anyway. So it shouldn't be a problem.

Gerv

[Man Ho (Certizen)]

On 2/4/2015 6:08 PM, Gervase Markham wrote:
> They are not refusing to comply, they
> just want to change the location of the compliance statement.

In practice, Webtrust BR audit report requires the CA's assertion of
compliance with BRs. It is a proper place to make the compliance
statement because it can be read together with the audit report.

> Or are they basically saying they do not wish to be bound by the latest
> version of the BRs, but only by the version current at the time of their
> last audit?
>
> If so, I'd say No. Mozilla expects all CAs in our program, whether CAB
> Forum members or not, to comply with the latest version of the BRs
> (taking into account any phase-in periods given in resolutions to adopt
> new measures). Inability to do this might be considered indicative of
> deeper problems at the CA.

The point of discussion is misunderstood. It is no doubt that CAs are
willing, or actually required, to commit its compliance with the latest
version of BRs. Otherwise the CA simply refuses to join the root
program. But making a statement in CP/CPS means that CA "has already
complied" with the "latest version" of BRs. In other words, CA has
already complied with all potential changes of BRs at all time. Such
statement could be a false statement when the "latest version" of BRs
has been changed and CA actually cannot comply with the changes at that
time. Hence, users are misled by the statement at that time.

> It may be true that we can only have the compliance of a particular CA
> checked formally once a year at audit time, but we still expect ongoing
> compliance, and reserve the right to use other methods of checking it
> (such as examining issued certificates).

By all means, Mozilla always has the right to check ongoing compliance
as stated in Mozilla's CP. Making a statement in CP/CPS or not, doesn't
mean anything.

-- Man

[Kurt Roeckx]

On 2015-02-04 14:55, Man Ho (Certizen) wrote:
> But making a statement in CP/CPS means that CA "has already
> complied" with the "latest version" of BRs. In other words, CA has
> already complied with all potential changes of BRs at all time. Such
> statement could be a false statement when the "latest version" of BRs
> has been changed and CA actually cannot comply with the changes at that
> time. Hence, users are misled by the statement at that time.

So maybe the CP/CPS should indicate what the version is they comply
with, and update it on regular basis? Or maybe just say that they will
follow the updates?


Kurt

[Man Ho (Certizen)]

On 2/4/2015 10:27 PM, Kurt Roeckx wrote:
> So maybe the CP/CPS should indicate what the version is they comply
> with, and update it on regular basis? Or maybe just say that they will
> follow the updates?

Since Mozilla's CP requires CA to submit audit report annually, the CA's
assertion of compliance is also updated annually. Unless the frequency
of updating CP/CPS is more often than annual basis, it makes no
difference whether it is stated in CP/CPS or the Webtrust audit
statement. I want to point out that having the CA's assertion of
compliance with BR in Webtrust audit is a proper approach because it can
be read together with Webtrust audit report. If some CAs want to make a
statement in CP/CPS to commit "willingness" of following the BR, it
should be optional as an expression of endeavor.