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
