Re: Policy 2.6 Proposal: Require audits back to first issuance
On Thu, Mar 29, 2018 at 4:57 PM, Wayne Thayer wrote: > On Thu, Mar 29, 2018 at 8:57 AM, Ryan Sleevi wrote: > >> >> I'm not fully sure I understand the proposal here. >> >> I would think that, for all roots created since 2012, the expectation >> > is that there is an unbroken series of audits, going from a Point in Time >> audit (of the policies and infrastructure) to a Root Key Generation >> Ceremony attestation (under the policies and practices) to a Period of Time >> audit, with the issuance of any supporting infrastructure appearing between >> the RKGC and the PoT and covered by the PoT audit. >> >> This expectation apparently isn't clear given the numerous inclusion > requests - for roots created before and after 2012 - we're seen that are > lacking historic audits - Japan GPKI and ComSign for instance. > > I wasn't thinking about requiring the RKGC audit report as part of our > inclusion process, but we probably should (assuming those reports aren't > confidential). > I'm not sure the extent for an equivalent under ETSI, but under the WebTrust side, practitioner guidance and illustrative reports have been provided at http://www.webtrust.org/practitioner-qualifications/item64422.aspx Under the US Reporting - SSAE 18 guidance [1], an illustrative report conforming to AT-C205 is provided on page 61. Under the Canada Reporting - CSAE 3000 - 3001 [2], an illustrative report as an independent assurance attestation engagement is provided on Page 85 Under the International Reporting - ISAE 3000 [3], an illustrative report conforming to ISAE 3000 is provided on page 68. My understanding is that these reports, and the international standards they adhere to, are designed for public reporting. [1] http://www.webtrust.org/practitioner-qualifications/docs/item85115.pdf [2] http://www.webtrust.org/practitioner-qualifications/docs/item85114.pdf [3] http://www.webtrust.org/practitioner-qualifications/docs/item85204.pdf > > Does that match your intent? Assuming I did not botch the audit timing >> issues here >> >> I think so. My intent is to make it clear that roots must meet our audit > requirements even before they are included, and I'm open to suggestions on > the best way to achieve that in our policy. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Permit issuance during change in ownership
On Thu, Mar 29, 2018 at 4:03 PM, Wayne Thayer wrote: > On Thu, Mar 29, 2018 at 8:53 AM, Ryan Sleevi wrote: > >> >> On Mon, Mar 26, 2018 at 3:46 PM, Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> When the Francisco Partners acquisition of Comodo was announced, it was >>> pointed out [1] that a strict reading of the current policy section 8.1 >>> would have forced Comodo to stop issuing certificates for some period of >>> time: >>> >>> If the receiving or acquiring company is new to the Mozilla root program, >>> > there MUST be a public discussion regarding their admittance to the >>> root >>> > program, which Mozilla must resolve with a positive conclusion before >>> > issuance is permitted. >>> > >>> >>> I propose that we update section 8.1 to distinguish between root >>> transfers >>> and acquisition of or investment in a CA organization, with the latter >>> cases allowing issuance to continue during the discussion period. >>> >>> During the earlier discussion on this topic [1], it was also proposed >>> that >>> we require the receiving or acquiring company to make no changes during >>> the >>> discussion period and that we require all material changes anticipated >>> as a >>> result of the investment or acquisition to be publicly disclosed by the >>> CA. >>> >>> This is: https://github.com/mozilla/pkipolicy/issues/109 >>> >>> [1] >>> https://groups.google.com/d/msg/mozilla.dev.security.policy/ >>> AvGlsb4BAZo/gQe5ggE6BQAJ >> >> >> I'm having a little bit of difficulty imagining what you see the change >> looking like. Do you have draft text in mind, to look for possible >> exploitable loopholes? >> >> Here's a proposal: https://github.com/mozilla/pkipolicy/commit/ > 565250b9bbc16c1a4e3d4165f0171e8702b2b21d > Thanks, that's much easier to visualize. I think it's a positive change, but it may be worth emphasizing that a complete change in ownership does not otherwise exempt a CA from the other reporting - such as changes in operational personnel, material changes in the CA's operations (CP/CPS), etc. This is covered by Section 8.2 and 8 overall, so it may not bear mentioning explicitly, or it may be worth noting that the receiving or acquiring company will be bound by the policy, in full, including any notifications of further changes. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Require audits back to first issuance
On Thu, Mar 29, 2018 at 8:57 AM, Ryan Sleevi wrote: > > I'm not fully sure I understand the proposal here. > > I would think that, for all roots created since 2012, the expectation > is that there is an unbroken series of audits, going from a Point in Time > audit (of the policies and infrastructure) to a Root Key Generation > Ceremony attestation (under the policies and practices) to a Period of Time > audit, with the issuance of any supporting infrastructure appearing between > the RKGC and the PoT and covered by the PoT audit. > > This expectation apparently isn't clear given the numerous inclusion requests - for roots created before and after 2012 - we're seen that are lacking historic audits - Japan GPKI and ComSign for instance. I wasn't thinking about requiring the RKGC audit report as part of our inclusion process, but we probably should (assuming those reports aren't confidential). Does that match your intent? Assuming I did not botch the audit timing > issues here > > I think so. My intent is to make it clear that roots must meet our audit requirements even before they are included, and I'm open to suggestions on the best way to achieve that in our policy. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Permit issuance during change in ownership
On Thu, Mar 29, 2018 at 8:53 AM, Ryan Sleevi wrote: > > On Mon, Mar 26, 2018 at 3:46 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> When the Francisco Partners acquisition of Comodo was announced, it was >> pointed out [1] that a strict reading of the current policy section 8.1 >> would have forced Comodo to stop issuing certificates for some period of >> time: >> >> If the receiving or acquiring company is new to the Mozilla root program, >> > there MUST be a public discussion regarding their admittance to the root >> > program, which Mozilla must resolve with a positive conclusion before >> > issuance is permitted. >> > >> >> I propose that we update section 8.1 to distinguish between root transfers >> and acquisition of or investment in a CA organization, with the latter >> cases allowing issuance to continue during the discussion period. >> >> During the earlier discussion on this topic [1], it was also proposed that >> we require the receiving or acquiring company to make no changes during >> the >> discussion period and that we require all material changes anticipated as >> a >> result of the investment or acquisition to be publicly disclosed by the >> CA. >> >> This is: https://github.com/mozilla/pkipolicy/issues/109 >> >> [1] >> https://groups.google.com/d/msg/mozilla.dev.security.policy/ >> AvGlsb4BAZo/gQe5ggE6BQAJ > > > I'm having a little bit of difficulty imagining what you see the change > looking like. Do you have draft text in mind, to look for possible > exploitable loopholes? > > Here's a proposal: https://github.com/mozilla/pkipolicy/commit/565250b9bbc16c1a4e3d4165f0171e8702b2b21d On its face, it sounds reasonable, but it seems the wording will be tricky > to get right. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits for new subCAs
On Thu, Mar 29, 2018 at 2:46 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Thanks everyone for your input on this topic. I'm hearing consensus that we > should not require a newly issued subordinate CA certificate to appear on > an audit statement prior to being used to sign end-entity certificates. > There's a little danger here in this phrasing. If a CA generates a key, has a report, and then places it in a safe for 3 years before issuing the first cert, I would think you'd want some reports covering this. In particular, what are the controls around the safe that were protecting the key? How do we know they didn't simply stow it on a USB stick in someone's unlocked desk? etc > This is something that could be clarified in our policy with a statement > such as "Newly issued subordinate CA certificates MUST appear on the CAs > next period-of-time audit statements" in section 5.3.2. > This mitigates one window of vulnerability - reducing the span from multiple years to, at most, one year. > It's not yet clear to me if we should require something more than > disclosure of the actual certificate because: > * All end-entity certificates are already required to contain "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" (BR 7.1.2.3). Isn't this enough to assert the controls > applied to the subCA certificate? > * I'm not opposed to explicitly stating that any newly issued subCA > certificate MUST appear in the appropriate CP/CPS before being used, but > isn't that obvious? > Obvious for who? It's not obvious CAs are doing it, no. For relying parties, it's equally not obvious, but presumably being inferred by trying to map the policy OID back. > * The amount of effort needed to verify compliance with a new requirement > for a management assertion (option #2) is significant and could outweigh > the benefit we receive from those documents. > * Peter's sample assertion letter [1] includes a link to an auditor's key > generation ceremony report. Can this type of audit report be shared > publicly? If so, those might be a reasonable thing to require via a new > field in CCADB. > I think, for new CAs, the KGC report and the stated CP/CPS, combined with ensuring that the next audit that covers the period of time stated on the KGC report includes that certificate, seems like a reasonable balance. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audits for new subCAs
Thanks everyone for your input on this topic. I'm hearing consensus that we should not require a newly issued subordinate CA certificate to appear on an audit statement prior to being used to sign end-entity certificates. This is something that could be clarified in our policy with a statement such as "Newly issued subordinate CA certificates MUST appear on the CAs next period-of-time audit statements" in section 5.3.2. It's not yet clear to me if we should require something more than disclosure of the actual certificate because: * All end-entity certificates are already required to contain "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" (BR 7.1.2.3). Isn't this enough to assert the controls applied to the subCA certificate? * I'm not opposed to explicitly stating that any newly issued subCA certificate MUST appear in the appropriate CP/CPS before being used, but isn't that obvious? * The amount of effort needed to verify compliance with a new requirement for a management assertion (option #2) is significant and could outweigh the benefit we receive from those documents. * Peter's sample assertion letter [1] includes a link to an auditor's key generation ceremony report. Can this type of audit report be shared publicly? If so, those might be a reasonable thing to require via a new field in CCADB. - Wayne [1] https://cabforum.org/pipermail/public/attachments/20160923/3da206b8/attachment-0001.bin On Wed, Mar 28, 2018 at 10:32 PM, Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Operating a technically unconstrained issuing CA, Siemens CA (aka TSP) > does something very similar in case a new CA is necessary: > > * In an audited ceremony based on the operational and technical controls > audited in the last annual audit a key pair is generated on one of the HSMs > * A CSR is constructed and sent to our cross signing partner, together > with the witness report of the auditor, filled with all the information > required by Microsoft in the Audit Cover Letter Template > * The cross signing partner checks the report and creates the certificate > for the issuing CA After receiving the new certificate we update our CPS > Only after the new CPS is published certificates are issued > > In the next annual audit the new CA is part of the normal audit. > > So I would recommend to choose a combination of options #1 and #2. > > With best regards, > Rufus Buschart > > Siemens AG > GS IT HR 7 4 > Hugo-Junkers-Str. 9 > 90411 Nuernberg, Germany > Tel.: +49 1522 2894134 > mailto:rufus.busch...@siemens.com > > www.siemens.com/ingenuityforlife > > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+rufus.buschart=siemens@lists.mozilla.org] On Behalf Of Bruce > via dev-security-policy > Sent: Mittwoch, 28. März 2018 23:38 > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Audits for new subCAs > > Entrust does the following: > - Each subCA certificate is created through a audited ceremony. The > auditor creates a report indicating the key ID and the CPS which was used > for key generation. > - When it is time for the subCA to go into production, an intermediate > certificate is issued from a root. The intermediate certificate will meet > the requirements of the CPS and the BRs if applicable. > - The subCA can now issue certificates. The end entity certificates will > have a certificate policy which is stated in the CPS. As such, issuing a > certificate is an assertion that the subCA is issuing in accordance with > the certificate policy and CPS. > - The new subCA is compliance audited at the next time in our annual audit > cycle. Note the new subCA is operated the same as all other CAs meeting the > same certificate policy. > > I would note that if there was a significant change such as data center > location or new certificate policy, then we may want to consider a > point-in-time readiness assessment. I think that all CAs required a > point-in-time readiness assessment, before we started to issue EV > certificates. > > I suppose that I am stating that I support option 1 as I think the option > 2 attestments are already covered. However, option 3 may be required for a > new data center or a policy which has not been previously audited. > > Thanks, Bruce. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Update domain validation requirements
On Fri, Mar 23, 2018 at 6:22 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I've drafted these changes: > https://github.com/mozilla/pkipolicy/commit/e5269ff0d6ced93a6c6af65947712b > 8e4b2e18b8 > > On Tue, Mar 20, 2018 at 9:57 AM, Tim Hollebeek > > wrote: > > > > > > * Add a new bullet on IP Address validation that forbids the use of BR > > > 3.2.2.5(4) (“any other method”) and requires disclosure of IP Address > > > validation processes in the CA’s CP/CPS. > > > > This is a bit premature. Most CA's IP validation procedures still fall > > under > > any other method, and the draft ballot that we've been trying to pass > > for a year or so is not done yet (I was writing it when the Validation > > Summit started taking over my life...) There's a good chance we will > > get a ballot passed on this issue this summer, but there's also a good > > chance that work on improving the non-IP validation methods will be > > prioritized above it. > > > > It might make sense, though, to require that if you use 3.2.2.4.8, you > > cannot use 3.2.2.5(4). That would eliminate the ability to use .5(4) to > > validate domain names. > > > > My commit includes this compromise. > > The IP validation disclosure language is fine and would actually help > > get a ballot passed. I've been trying to get everyone to disclose their > > IP validation practices and whether they issue IP certificates, but it > > turns out that "the CABF Validation Chair is politely asking for your > > cooperation" has some positive impact, but is mostly ignored. > > > > This is the new 2.2 (4) in my commit. > > I think disclosure and eliminating the loophole that allows IP validation > > method risk to bleed into domain names is a good place to start. > > > > -Tim > > I think this looks good, and paves a path for further simplification as the IP validation methods are reformed. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Require audits back to first issuance
On Mon, Mar 26, 2018 at 3:06 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Mozilla began requiring BR audits for roots in our program in 2013 [1], but > we have a vague policy statement in section 3.1 regarding audit > requirements prior to inclusion: > > Before being included and periodically thereafter, CAs MUST obtain certain > > audits… > > > > BR section 8.1 contains the following paragraph: > > If the CA does not have a currently valid Audit Report indicating > > compliance with one of the audit schemes listed in Section 8.1, then, > > before issuing Publicly-Trusted Certificates, the CA SHALL successfully > > complete a point-in-time readiness assessment performed in accordance > with > > applicable standards under one of the audit schemes listed in Section > 8.1. > > The point-in-time readiness assessment SHALL be completed no earlier than > > twelve (12) months prior to issuing Publicly-Trusted Certificates and > SHALL > > be followed by a complete audit under such scheme within ninety (90) days > > of issuing the first Publicly-Trusted Certificate. > > > > Unfortunately, the definition of Publicly-Trusted Certificates exempts > newly created roots from this requirement, and in practice we have seen > that violating this requirement does not prevent roots from receiving BR > audit statements. We continue to see inclusion requests for roots that do > not have an unbroken chain of BR audits back to first issuance. > > I propose that we add a requirement to Mozilla policy section 3.1.3 for > roots to have contiguous audits beginning within 90 days of issuing the > first certificate. I chose 90 days to allow some time for issuing > subordinate CA certificates and test certificates in preparation for the > audit. > . > This is: https://github.com/mozilla/pkipolicy/issues/113 > > [1] https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Audit_Criteria > [2] > https://groups.google.com/d/msg/mozilla.dev.security.policy/Mezqdljjerc/ > nIirftRqAgAJ I'm not fully sure I understand the proposal here. I would think that, for all roots created since 2012, the expectation is that there is an unbroken series of audits, going from a Point in Time audit (of the policies and infrastructure) to a Root Key Generation Ceremony attestation (under the policies and practices) to a Period of Time audit, with the issuance of any supporting infrastructure appearing between the RKGC and the PoT and covered by the PoT audit. Does that match your intent? Assuming I did not botch the audit timing issues here ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Permit issuance during change in ownership
On Mon, Mar 26, 2018 at 3:46 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > When the Francisco Partners acquisition of Comodo was announced, it was > pointed out [1] that a strict reading of the current policy section 8.1 > would have forced Comodo to stop issuing certificates for some period of > time: > > If the receiving or acquiring company is new to the Mozilla root program, > > there MUST be a public discussion regarding their admittance to the root > > program, which Mozilla must resolve with a positive conclusion before > > issuance is permitted. > > > > I propose that we update section 8.1 to distinguish between root transfers > and acquisition of or investment in a CA organization, with the latter > cases allowing issuance to continue during the discussion period. > > During the earlier discussion on this topic [1], it was also proposed that > we require the receiving or acquiring company to make no changes during the > discussion period and that we require all material changes anticipated as a > result of the investment or acquisition to be publicly disclosed by the CA. > > This is: https://github.com/mozilla/pkipolicy/issues/109 > > [1] > https://groups.google.com/d/msg/mozilla.dev.security.policy/AvGlsb4BAZo/ > gQe5ggE6BQAJ I'm having a little bit of difficulty imagining what you see the change looking like. Do you have draft text in mind, to look for possible exploitable loopholes? On its face, it sounds reasonable, but it seems the wording will be tricky to get right. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
