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. > > 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? > 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. > 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. > 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. 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. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
