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.
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 * 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. 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
