Re: Policy 2.7 Proposal: CA Certificate Binding to Policy Documents
I've gone ahead and made this change in the 2.7 branch: https://github.com/mozilla/pkipolicy/commit/3a70cf31cf81f5e00b62f958fe8a3b59c7cb0f34 I'll consider this issue resolved unless further comments are received. - Wayne On Mon, May 13, 2019 at 11:41 PM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Wayne, > I agree with this approach, it's quite explicit but flexible at the same > time. > Thanks, > Pedro > > El martes, 14 de mayo de 2019, 0:49:40 (UTC+2), Wayne Thayer escribió: > > On Mon, May 13, 2019 at 7:06 AM Pedro Fuentes via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > Hi Wayne, > > > inserting my comments below. > > > Best, > > > Pedro > > > > > > El viernes, 10 de mayo de 2019, 23:54:40 (UTC+2), Wayne Thayer > escribió: > > > > 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 (...) 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 point about the wording is that you propose to disclose this > > > information in both the CP and the CPS, and I propose that this is made > > > mandatory in the CPS only, as it can happen that the CA is adopting a > CP > > > defined by another entity. > > > So I'd prefer a wording that says: "CPSes must clearly indicate which > root > > > and intermediate certificates the practices and processes described in > CPs > > > and CPSes documents apply to. " > > > > > > > My rational is that (...) a leaf certificate with a CP > > > > > > > > > > > > > Can we determine which CP applies to a given intermediate based on > OIDs? > > > > > > > > > > Right now is only mandatory to use the OIDs in SSL certificates, but we > > > embraced this as a general practice for the new CAs we are deploying, > so > > > all new certificates include a policy OID, as stipulated in the > related CP > > > document, independently if are SSL or Personal certificates. > > > > > > >* its own CPS, that (...) 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? > > > > > > Actually we updated recently our WISeKey CPS to accommodate this > change. > > > Previously we were relying on publishing the current version of the > list of > > > Issuing CAs in the website, but I added this explicitly in the WISeKey > CPS. > > > If you check our new CPS (you can get it at > > > https://filevault.wisekey.com/f/7bc86620ea/?dl=1) you'll find the > method > > > we use to disclose this: > > > - In section 1.3.1 we disclose the Roots and Intermediates and in > > > particular in section 1.3.1.3 we clarify about the Issuing CAs and we > make > > > a reference to the Annex B (using an Annex because of the different > page > > > format so it's easer to read and maintain) > > > - In Annex B (page 63 at the end of the doc) we add the list of the > active > > > intermediate and issuing CAs, mapping it to the allowed CP they issue > > > > > > I think the only place where we can disclose this is in the WISeKey > CPS, > > > as the CP documents published by the OISTE Foundation set the rules to > be > > > implemented by the CAs operating in the trust model, but aren't > necessarily > > > aware of the particular Issuing CAs allowed to issue the CP. > > > > > > > > > > > Our particular approach (...) > > > > > > > > Thank you Pedro, this helps to clarify your concern. I think your > approach > > is good, but I am concerned that limiting the scope of the requirement to > > only the CPS does not address my concern when CAs have multiple CPs. Here > > is an alternate proposal: > > > > CAs must provide a way to clearly determine which CP and CPS applies to > > each root and intermediate certificate. > > > > I think that this would allow you to continue with the approach you > > described above. Do you agree? > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: CA Certificate Binding to Policy Documents
Hi Wayne, I agree with this approach, it's quite explicit but flexible at the same time. Thanks, Pedro El martes, 14 de mayo de 2019, 0:49:40 (UTC+2), Wayne Thayer escribió: > On Mon, May 13, 2019 at 7:06 AM Pedro Fuentes via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Hi Wayne, > > inserting my comments below. > > Best, > > Pedro > > > > El viernes, 10 de mayo de 2019, 23:54:40 (UTC+2), Wayne Thayer escribió: > > > 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 (...) 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 point about the wording is that you propose to disclose this > > information in both the CP and the CPS, and I propose that this is made > > mandatory in the CPS only, as it can happen that the CA is adopting a CP > > defined by another entity. > > So I'd prefer a wording that says: "CPSes must clearly indicate which root > > and intermediate certificates the practices and processes described in CPs > > and CPSes documents apply to. " > > > > > My rational is that (...) a leaf certificate with a CP > > > > > > > > > > Can we determine which CP applies to a given intermediate based on OIDs? > > > > > > > Right now is only mandatory to use the OIDs in SSL certificates, but we > > embraced this as a general practice for the new CAs we are deploying, so > > all new certificates include a policy OID, as stipulated in the related CP > > document, independently if are SSL or Personal certificates. > > > > >* its own CPS, that (...) 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? > > > > Actually we updated recently our WISeKey CPS to accommodate this change. > > Previously we were relying on publishing the current version of the list of > > Issuing CAs in the website, but I added this explicitly in the WISeKey CPS. > > If you check our new CPS (you can get it at > > https://filevault.wisekey.com/f/7bc86620ea/?dl=1) you'll find the method > > we use to disclose this: > > - In section 1.3.1 we disclose the Roots and Intermediates and in > > particular in section 1.3.1.3 we clarify about the Issuing CAs and we make > > a reference to the Annex B (using an Annex because of the different page > > format so it's easer to read and maintain) > > - In Annex B (page 63 at the end of the doc) we add the list of the active > > intermediate and issuing CAs, mapping it to the allowed CP they issue > > > > I think the only place where we can disclose this is in the WISeKey CPS, > > as the CP documents published by the OISTE Foundation set the rules to be > > implemented by the CAs operating in the trust model, but aren't necessarily > > aware of the particular Issuing CAs allowed to issue the CP. > > > > > > > > Our particular approach (...) > > > > > Thank you Pedro, this helps to clarify your concern. I think your approach > is good, but I am concerned that limiting the scope of the requirement to > only the CPS does not address my concern when CAs have multiple CPs. Here > is an alternate proposal: > > CAs must provide a way to clearly determine which CP and CPS applies to > each root and intermediate certificate. > > I think that this would allow you to continue with the approach you > described above. Do you agree? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: CA Certificate Binding to Policy Documents
On Mon, May 13, 2019 at 7:06 AM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Wayne, > inserting my comments below. > Best, > Pedro > > El viernes, 10 de mayo de 2019, 23:54:40 (UTC+2), Wayne Thayer escribió: > > 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 (...) 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 point about the wording is that you propose to disclose this > information in both the CP and the CPS, and I propose that this is made > mandatory in the CPS only, as it can happen that the CA is adopting a CP > defined by another entity. > So I'd prefer a wording that says: "CPSes must clearly indicate which root > and intermediate certificates the practices and processes described in CPs > and CPSes documents apply to. " > > > My rational is that (...) a leaf certificate with a CP > > > > > > > Can we determine which CP applies to a given intermediate based on OIDs? > > > > Right now is only mandatory to use the OIDs in SSL certificates, but we > embraced this as a general practice for the new CAs we are deploying, so > all new certificates include a policy OID, as stipulated in the related CP > document, independently if are SSL or Personal certificates. > > >* its own CPS, that (...) 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? > > Actually we updated recently our WISeKey CPS to accommodate this change. > Previously we were relying on publishing the current version of the list of > Issuing CAs in the website, but I added this explicitly in the WISeKey CPS. > If you check our new CPS (you can get it at > https://filevault.wisekey.com/f/7bc86620ea/?dl=1) you'll find the method > we use to disclose this: > - In section 1.3.1 we disclose the Roots and Intermediates and in > particular in section 1.3.1.3 we clarify about the Issuing CAs and we make > a reference to the Annex B (using an Annex because of the different page > format so it's easer to read and maintain) > - In Annex B (page 63 at the end of the doc) we add the list of the active > intermediate and issuing CAs, mapping it to the allowed CP they issue > > I think the only place where we can disclose this is in the WISeKey CPS, > as the CP documents published by the OISTE Foundation set the rules to be > implemented by the CAs operating in the trust model, but aren't necessarily > aware of the particular Issuing CAs allowed to issue the CP. > > > > > Our particular approach (...) > > Thank you Pedro, this helps to clarify your concern. I think your approach is good, but I am concerned that limiting the scope of the requirement to only the CPS does not address my concern when CAs have multiple CPs. Here is an alternate proposal: CAs must provide a way to clearly determine which CP and CPS applies to each root and intermediate certificate. I think that this would allow you to continue with the approach you described above. Do you agree? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: CA Certificate Binding to Policy Documents
Hi Wayne, inserting my comments below. Best, Pedro El viernes, 10 de mayo de 2019, 23:54:40 (UTC+2), Wayne Thayer escribió: > 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 (...) 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 point about the wording is that you propose to disclose this information in both the CP and the CPS, and I propose that this is made mandatory in the CPS only, as it can happen that the CA is adopting a CP defined by another entity. So I'd prefer a wording that says: "CPSes must clearly indicate which root and intermediate certificates the practices and processes described in CPs and CPSes documents apply to. " > My rational is that (...) a leaf certificate with a CP > > > > Can we determine which CP applies to a given intermediate based on OIDs? > Right now is only mandatory to use the OIDs in SSL certificates, but we embraced this as a general practice for the new CAs we are deploying, so all new certificates include a policy OID, as stipulated in the related CP document, independently if are SSL or Personal certificates. >* its own CPS, that (...) 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? Actually we updated recently our WISeKey CPS to accommodate this change. Previously we were relying on publishing the current version of the list of Issuing CAs in the website, but I added this explicitly in the WISeKey CPS. If you check our new CPS (you can get it at https://filevault.wisekey.com/f/7bc86620ea/?dl=1) you'll find the method we use to disclose this: - In section 1.3.1 we disclose the Roots and Intermediates and in particular in section 1.3.1.3 we clarify about the Issuing CAs and we make a reference to the Annex B (using an Annex because of the different page format so it's easer to read and maintain) - In Annex B (page 63 at the end of the doc) we add the list of the active intermediate and issuing CAs, mapping it to the allowed CP they issue I think the only place where we can disclose this is in the WISeKey CPS, as the CP documents published by the OISTE Foundation set the rules to be implemented by the CAs operating in the trust model, but aren't necessarily aware of the particular Issuing CAs allowed to issue the CP. > > Our particular approach (...) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: CA Certificate Binding to Policy Documents
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
Re: Policy 2.7 Proposal: CA Certificate Binding to Policy Documents
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
Policy 2.7 Proposal: CA Certificate Binding to Policy Documents
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
