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
