On 03/04/2018 02:15, Wayne Thayer wrote:
On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
While Entrust happens to do this, as a relying party, I dislike frequent
updates to CP/CPS documents just for such formal changes.
This creates a huge loophole. The CP/CPS is the master set of policies the
TSP agrees to be bound by and audited against. If a TSP doesn't include a
new subCA certificate in the scope of their CP/CPS, then from an audit
perspective there is effectively no policy that applies to the subCA.
Similarly, if the TSP claims to implement a new policy but doesn't include
it in their CP/CPS, then the audit will not cover it (unless it's a BR
requirement that has made it into the BR audit criteria).
If the CP/CPS states as an auditable requirements that all SubCAs are
logged in the trusted hardware of the root CA HSM, listed in the
dedicated public document and audited, there is no need for that list to
be included verbatim in the CP/CPS any more than there is a need for
most other routine activities to change the CP/CPS.
This is because the CP/CPS is a lengthy legal document which relying
parties are "supposed to" read and understand. Thus each such needless
change generates a huge wave of millions of relying parties being
supposed to obtain and read through that document, a complete waste of
our time as relying parties.
I think you're confusing the Relying Party Agreement with the CP/CPS. Even
so, you've pointed out that it is absurd to use this as an argument against
regular CP/CPS updates.
Relying party agreements (and subscriber agreements too) often
incorporate the CP/CPS by reference.
TSPs are now required to maintain change logs in their CP/CPS. Would not a
quick glance at that meet your needs?
Only to the extent such logs are sufficient to determine how much of the
document is literally (not just subjectively) unchanged. And provided
any conflict between the change log and the actual document shall be
resolved to the benefit of all third parties.
It is much more reasonable, from a relying party perspective, for such
informational details to be in a parallel document and/or be postponed
until a scheduled annual or rarer document update (Yes I am aware of the
BR that such needless updates be done annually for no reason at all).
How would you distinguish between details and material changes? I would
argue that a new subCA certificate is more than an informational detail.
Details include such routine numerical changes as date of last review
(where that review does not result in any other change), changing the
list of CA certificates or changing the name brand of HSM hardware,
exact locations of technical facilities (as opposed to changing the
country and jurisdiction) etc.
Substantial changes are things that could actually affect the
willingness of parties to trust or request certificates, such as the
used validation methods, the contracting entity, the jurisdiction
capable of interfering with operations and issuance etc.
The point of the BR requirement is to create some documentation indicating
that a TSP is regularly reviewing and updating their CP/CPS.
However that could equally just be a management statement (copied in the
audit report if necessary), that the CP/CPS was reviewed on YYYY/MM/DD
and found to remain compliant to BRs version X.Y.Z. Mozilla policy
version A.B, ETSI standard EEE EEE and that the actual practice remains
within its limits.
There could also be restricting legal addendums saying things like
"Although our current CPS allows us to issue 5 year certificates based
on a sworn statement from a notary public, we will not and have not done
so since YYYY/MM/DD". Such addendums would be to satisfy those who no
longer accept that particular practice but would have no effect on the
relationship with parties that accept the CPS including the option to do
so.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
