I have drafted the change as proposed, moving the exact "Required Practice" language into section 3.3 of the policy: https://github.com/mozilla/pkipolicy/commit/803ec1a1414318a69491854a867dc69889442b7b
On Sat, Apr 27, 2019 at 11:36 AM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hello, > > I totally agree about the need to specify this information clearly in the > documentation framework, but I personally think that it's not always > adequate to force listing the intermediate CA certificates in the CP, but > definitely this information is required to be disclosed in the CPS. > > Pedro: I agree with you if there is only one CP. However when there are multiple CPs, there needs to be some way to determine which one applies to each CA certificate. Does the language I proposed give you enough flexibility to meet the requirement without forcing the listing of every intermediate in your CPs? My rational is that the Root CA in a Trust Model has the role to define > different CP for the different certificate profiles that are allowed in the > hierarchy, setting the rules to be implemented by the issuing CAs (this > includes the OIDs to include in the certificates to identify the associated > CP), and it's in the particular CPS published by a CA operating in the > Trust Model where it's specified the CPs implemented and by which Issuing > CAs. > > This is what we are intending now to do as part of the process to split > the ownership of the Roots and the Issuing CAs, in our particular case, so > we'd have: > - The Root Owner (OISTE Foundation) defines: > * A number of CP documents that define the practices to be implemented > while issuing a particular type of certificate. This includes things from > the allowed validation practices to the OIDs to be included in the > certificates to associate a leaf certificate with a CP > Can we determine which CP applies to a given intermediate based on OIDs? * its own CPS, that has as main scope the Root CAs, but also defines the > general practices of the whole Trust Model > - A subordinate CA operating under the Root, in our case it would WISeKey, > defines: > * A CPS which is defined in accordance of the OISTE CPS and that > discloses the practices implemented while issuing certificates of one or > more of the CP defined by OISTE. It's here where WISeKey includes the > information about the Issuing CAs implementing the different OISTE CP > > With this scenario, we consider that the CP document is not aware of the > particular CA that issues certificates of a particular kind, but this > information must be disclosed in the CA's CPS. > > I think it is okay if a CP isn't aware of a particular CA certificate, as long as there is some clear way to determine which CP applies to that intermediate. How does the CPS identify which CP applies to each intermediate? Our particular approach can be seen here: > - CP and CPS published by the OISTE Foundation: > https://oiste.org/repository/ > - CPS published by WISeKey (New version 3.0): > https://www.wisekey.com/repository/ > > So, this discussion is relevant to us, as it could imply that our approach > might need to be adapted. > > Best, > Pedro > > PS Please note that WISeKey as not fully adopted yet the new CP/CPS > documentation framework, as this has a dependency on Mozilla approving our > transfer request, as it's being discussed in > https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/hueaxNtUNl0 > > El sábado, 27 de abril de 2019, 0:15:00 (UTC+2), Wayne Thayer escribió: > > The required practice "Publicly Available CP and CPS" [1] states: > > > > The CP/CPS must clearly indicate which root and subordinate certificates > > > the practices and processes described in those documents apply to. > > > > > > This can be done in (at least) two ways: > > * the policy document can unambiguously list the specific CA certificates > > within its scope > > * the CA certificate can contain one or more policy OIDs that are > > referenced in the applicable policy documents > > > > I have found that many CP/CPSes don't clearly list the certificates that > > are in-scope, and the binding between policy OIDs in subordinate CA > > certificates and CP/CPSes is often unclear when the CA has multiple > policy > > documents. > > > > My concern is that this could lead to situations where a CA can pick and > > choose policies to argue that a given certificate is compliant. > > > > However, BR section 7.1.2.3 already requires each end-entity certificate > to > > include "A Policy Identifier, defined by the issuing CA, that indicates a > > Certificate Policy asserting the issuing CA's adherence to and compliance > > with these Requirements." I'm much more interested in compliance with the > > BRs and Mozilla policy than the CA's own CPS, so this mitigates my > concern. > > > > Even though I don't think this is as important now that I've given it > some > > thought, I propose moving the following required practice into section > 3.3 > > "CPs and CPSes" of our policy: > > > > CPs and CPSes must clearly indicate which root and intermediate > > > certificates the practices and processes described in those documents > apply > > > to. > > > > > > > This is https://github.com/mozilla/pkipolicy/issues/171 > > > > I will appreciate everyone's input on this proposal. > > > > - Wayne > > > > [1] > > > https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
