On 03/04/2018 14:57, Ryan Sleevi wrote:
On Mon, Apr 2, 2018 at 9:03 PM, Jakob Bohm via dev-security-policy <
[email protected]> wrote:
On 03/04/2018 02:15, Wayne Thayer wrote:
On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy <
[email protected]> 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 not true. A CP/CPS is not bound to the organization, it's bound to
specific operations, and as such, the creation of a subCA by an
organization has no implicit binding to a CP/CPS.
A CP/CPS covers (by its very nature) all SubCA signing operations
by a covered CA private key and as others have pointed out, each
compliant SubCA is required to contain an OID identifying the applicable
CP/CPS.
Thus a CP/CPS can state that it covers all CA keys and certs listed in
public document X and that all SubCAs referencing that CP/CPS and issued
by a covered CA key must be added to public document X, which shall be
published and archived in a specific way, such as in the CA
organizations public repository, sent to all enrolled root programs and
logged to CT.
The CP/CPS can also state that the CA HSM must store, in a secured
hardware log, all signed SubCA certs (or even all issued certs), this
log will be one of the key things checked by auditors (it already is in
the current WebTrust and ETSI auditing standards, as part of the
sampling of previously issued end entity certs).
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.
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.
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.
What? No.
If the Change Log is only informative (from a legal standpoint), then it
does not relieve those who read the document of the burden of actually
checking that nothing else was changed.
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.
These are all material and substantial changes.
Only if those things are hardcoded into the text of the CPS, rather than
being in different documents that are restricted (by the CPS) to only
provide those details. For example, a CPS can state that the HSM must
be officially validated to FIPS 140-3 level 3 or higher, and that the
secured CA facility is located in Mountain View, while leaving it to
other documents to state if the HSM is a specific model from nCipher or
IBM, and which exact building contains the secure equipment (the latter
might even be a secret).
Similarly for a list of current and past CA certs and a list where the
officials sign of on having reviewed the CPS document on specific dates.
This is fundamentally similar to how a CPS may refer to the latest BRs
without having to be updated for each ballot that affects only other
CAs.
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.
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.
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.
These all sound like rather terrible ideas, and while having been adopted
by some CAs in the past, are shown to be regularly problematic as to
forming a meaningful opinion as to whether the CA is themselves
trustworthy, particularly such CAs that argue for 'hidden' addendums, as
has happened in the past.
I am talking about public addendums, reviewed by auditors and root
programs, and in the case of Mozilla, uploaded to the CCADB or Bugzilla.
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
