On Thu, Apr 5, 2018 at 4:08 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 04/04/2018 16:01, Ryan Sleevi wrote:
>> On Tue, Apr 3, 2018 at 11:42 AM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>> On 03/04/2018 14:57, Ryan Sleevi wrote:
>>> On Mon, Apr 2, 2018 at 9:03 PM, Jakob Bohm via dev-security-policy <
>>>> dev-security-policy@lists.mozilla.org> wrote:
>>> Relying party agreements (and subscriber agreements too) often
>>>>> incorporate the CP/CPS by reference.
>>>> Can you point out to where that's required by Mozilla policy or by the
>>>> Baseline Requirements?
>>>> It is not a BR, it is an observation of common practice.
>> I disagree even to the claim that it's "common" practice. There is only
>> one
>> CA that has ever raised this as a practical matter of concern, but their
>> practices are so fundamentally outmoded that it's hardly to be considered
>> the model of a good CA operation.
> It is not usually a "concern" of the CAs.  Many CAs have no inherent
> problem forcing all their relying parties to reread 100 pages of
> legalese every few months, just like many websites don't have any
> problem demanding that users reread overlong terms of service every time
> they fancy a new minor adjustment to some corner or their product
> portfolio.
> It is a concern of relying parties subject to such CA practices or
> otherwise wishing to independently check if a CPS is worthy of their
> trust.

Thank you for clarifying your position. This does not seem to be a
meaningful objection against the policy change - that is, it's a concern
about how CAs operationalize these practices, which is not something that
Mozilla is imposing on the community. As such, I do not think this concern
is reasonable.

> But it seems unnecessary that meta-data about a decision not to change
>>> the CP/CPS is stored inside the CP/CPS thereby changing it anyway.
>> If you'd followed past discussions, you'd see it's explicitly desired to
>> take that explicit step, because that provides public attestation of that
>> step in a consistent, defined, and audited manner. It's
>> <https://maps.google.com/?q=stent,+defined,+and+audited+manner.+It's&entry=gmail&source=g>
>> a fundamentally
>> necessary part of public trust, and this has been discussed rather at
>> length precisely because of that.
> I am opposing the tendency to add ever more crud and noise to the CPS
> documents and their updates by redundantly requiring evermore CCADB data
> etc. to be duplicated in policy documents.  Not making the problem worse
> by adding new such requirements is a first step towards cleaning up
> the current overhead.

I see. In this regard, we fundamentally disagree as to the value provided
by the community, likely in part due to misunderstandings that the policy
documents represent public commitments that the broader community relies
upon, and their consistency is in-scope for the audits (which is not
necessarily the case for addendum). As such, it is of critical necessity to
ensure that community expectations are clearly stated within a CP/CPS in
clear and unambiguous ways.

Stating it as a "problem" thus misstates the value provided, and I think is
an objection that should not be considered.
dev-security-policy mailing list

Reply via email to