On 04/04/2018 16:01, Ryan Sleevi wrote:
On Tue, Apr 3, 2018 at 11:42 AM, Jakob Bohm via dev-security-policy <
[email protected]> 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 <
[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 all sounds good, but it does not reflect reality.
Consider a sub-CA whose control has been transferred - as has recently been
discussed here. The certificate does not magically change Policy OIDs, it
does not get revoked and reissued with a new policy OID, and yet, it is
operated under a distinct, new, and different CP/CPS.
As such, the proposed solution is fundamentally flawed, and resting on a
flawed assumption about how both CP/CPS works and the ecosystem works. For
this very reason, it seems extremely valuable - if not vitally necessary -
to ensure the scope is clearly and fairly stated, particularly when
engaging auditors who themselves will be bound by the scope of the publicly
stated documents, to the extent permitted within the scope of the audit.
Let's close a loophole. Not introduce more.
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.
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.
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.
I'm not sure your point - it's an objective goal to require the CP/CPS to
be updated as appropriate, and to fully and accurately reflect the CAs
operations. Each change is a material change, and should be fairly and
fully stated within the CP/CPS to the point that it's relevant to the
Baseline Requirements. That is, the CP/CPS must itself demonstrate complete
satisfaction of those requirements - or of Mozilla requirements. Burying
those in independent addenda, separately versioned, is to create a
fundamental loophole with regard to CP/CPS updates and policies, when these
changes practically matter. Your example - of specifying specific device -
is a bad example, precisely because one expects to see within the CP/CPS
the compliance with the expected policy (namely, an attestation of FIPS
140-2 Level 3). Similarly, as it applies to overall adherance with either
the BRs or Mozilla Policy, it's not unreasonable to expect sufficient
detail to demonstrate that compliance to be stated within the CP/CPS
itself, not addendum. While it may be that the CA produces supplementary
documentation (such as for the non-public portions of the audits) that
details the full performance, within the CP/CPS itself, one expects to see
all the information.
From a relying party point of view, it should be possible to understand the
CA's operations in a single pair of documents, without having to
cross-reference a set of nested or interrelated policy documents, some of
which may conflict due to their updates, and some of which may be created
in order to play semantic loopholes with regards to policy compliance.
It the very nature of CA hierarchies that most relying parties do not
usually know or care about every certificate and SubCA in existence,
only about the assurances that no bad certificates (including SubCAs)
will issue.
Relying parties frequently don't have the technical ability to create
custom entries in their copy of OneCRL (or equivalent) for specific
SubCAs that they disagree with anyway.
Note that I mentioned a hypothetical CPS requiring compliance with the
future (current draft is withdrawn) FIPS 140-3, not just FIPS 140-2.
Thus above and beyond the BRs. It could similarly have required FIPS
140-2 Level 4 or additional validation to some other standard.
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.
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 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.
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
