Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots
On Thu, 11 Feb 2021 15:12:46 -0500 Ryan Sleevi via dev-security-policy wrote: > So I'd say feel free to ask your question there, which helps make > sure it's answered before the issue is closed. Good point. In this case Arvid has clarified that in fact the ticket now has an updated sheet which (I haven't examined it yet) should satisfy my question so I shan't follow up there except in the event I have further questions. > This is one of many outstanding items still > for the Validation Working Group of the CA/B Forum, as possible > mitigations were also discussed. In short, "capability URLs" (where > the entire URL is, in effect, the capability) are dangerous. Good to know. > Note that there have been far more than "Ten Blessed Methods" since > those discussions, so perhaps it's clearer to just say 3.2.2.4. Personally I just like the way "Ten Blessed Methods" sounds. I wouldn't reliably recognise all Thirty Six Views of Mount Fuji, everything except (what I'd call) Big Wave, and Watermill could be any of dozens of imitators as far as this uneducated eye is concerned - and of course there are actually ten more of them, but we still call it "Thirty Six Views of Mount Fuji". The addition (and deprecation) of methods is an expected and desirable course for the Baseline Requirements, and I am watching even if I don't comment on it. However because everything is formatted according to RFC 3647 (which is a good thing), section 3.2.2.4 doesn't carry the same implication as "Ten Blessed Methods". BR 1.3.0 had a section 3.2.2.4 it's just that it doesn't in fact set down which methods must be used, which is how we got here in the first place. But I'm not old enough just yet to be incapable of learning new tricks, I've learned to call it a "blocklist" not a "blacklist" and I'm sure if everybody really starts to refer only to "3.2.2.4" I'll get used to that. Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits
All, The proposed change currently reads, "Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually from the time of CA key pair generation until the CA certificate is no longer trusted by Mozilla's root store or until all copies of the CA private key have been completely destroyed, as evidenced by a Qualified Auditor's key destruction report, whichever occurs sooner. This cradle-to-grave audit requirement applies equally to subordinate CAs as it does to root CAs. Successive period-of-time audits MUST be contiguous (no gaps)." But is the argument that I should also add something along these lines--"This cradle-to-grave audit requirement applies equally to ..., *and an audit would be required for all subordinate CAs until their private keys have been completely destroyed as well*."? Is that still the issue here? Or has it already been resolved with the language further above? Thanks, Ben On Sun, Jan 24, 2021 at 12:55 PM Ben Wilson wrote: > I agree that we should add language that makes it more clear that the key > destruction exception for audit only applies to the CA certificates whose > key has been destroyed. I'm also hoping that a CAO wouldn't destroy a Root > CA key if there were still valid subordinate CAs that the CAO might need to > revoke. > > On Fri, Nov 6, 2020 at 10:49 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 2020-11-05 22:43, Tim Hollebeek wrote: >> > So, I'd like to drill down a bit more into one of the cases you >> discussed. >> > Let's assume the following: >> > >> > 1. The CAO [*] may or may not have requested removal of the CAC, but >> removal >> > has not been completed. The CAC is still trusted by at least one public >> > root program. >> > >> > 2. The CAO has destroyed the CAK for that CAC. >> > >> > The question we've been discussing internally is whether destruction >> alone >> > should be sufficient to get you out of audits, and we're very skeptical >> > that's desirable. >> > >> > The problem is that destruction of the CAK does not prevent issuance by >> > subCAs, so issuance is still possible. There is also the potential >> > possibility of undisclosed subCAs or cross relationships to consider, >> > especially since some of these cases are likely to be shutdown >> scenarios for >> > legacy, poorly managed hierarchies. Removal may be occurring >> *precisely* >> > because there are doubts about the history, provenance, or scope of >> previous >> > operations and audits. >> > >> > We're basically questioning whether there are any scenarios where >> allowing >> > someone to escape audits just because they destroyed the key is likely >> to >> > lead to good outcomes as opposed to bad ones. If there aren't >> reasonable >> > scenarios where it is necessary to be able to remove CACs from audit >> scope >> > through key destruction while they are still trusted by Mozilla, it's >> > probably best to require audits as long as the CACs are in scope for >> > Mozilla. >> > >> > Alternatively, if there really are cases where this needs to be done, it >> > would be wise to craft language that limits this exception to those >> > scenarios. >> > >> >> I believe that destruction of the Root CA Key should only end audit >> requirements for the corresponding Root CA itself, not for any of its >> still trusted SubCAs. >> >> One plausible (but hypothetical) sequence of events is this: >> >> 1. Begin Root ceremony with Auditors present. >> >> 1.1 Create Root CA Key pair >> 1.2 Sign Root CA SelfCert >> 1.3 Create 5 SubCA Key pairs >> 1.4 Sign 5 SubCA pre-certificates >> 1.5 Request CT Log entries for the 5 SubCA pre-certificates >> 1.6 Sign 5 SubCA certificates with embedded CTs >> 1.7 Sign, but do not publish a set of post-dated CRLs for various >> contingencies >> 1.8 Sign, but do not publish a set of post-dated revocation OCSP >> responses for those contingencies >> 1.9 Sign, but do not yet publish, a set of post-dated non-revocation >> OCSP responses confirming that the SubCAs have not been revoked on each >> date during their validity. >> 1.10 Destroy Root CA Key pair. >> >> 2. Initiate audited storage of the unreleased CRL and OCSP signatures. >> >> 3. End Root ceremony, end root CAC audit period. >> >> 4. Release public audit report of this ceremony, this ends the ordinary >> audits required for the Root CA Cert. However audit reports that only >> the correct contingency and continuation OCSP/CRL signatures were >> released from storage remain technically needed. >> >> 5. Maintain revocation servers that publish the prepared CRLs and OCSP >> answers according to their embedded dates. Feed their publication queue >> from audited batch releases from the storage. >> >> 6. Operate the 5 SubCAs under appropriate security and audit schemes >> detailed in CP/CPS document pairs. >> >> 7. Apply for inclusion in the Mozilla root program. >> >> >> In the above
Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots
All, On Monday, I'm going to recommend to Kathleen that we proceed with these root inclusion requests of GlobalSign. Please let us know if there are any concerns. Thanks, Ben On Fri, Feb 12, 2021 at 7:31 AM Arvid Vermote via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Nick > > We attached an updated version of the affected certificate overview to the > bug on February 10, which does contain the date of order and date of > issuance. > > Thanks > > Arvid > > > -Original Message- > > From: dev-security-policy > > On > > Behalf Of Nick Lamb via dev-security-policy > > Sent: donderdag 11 februari 2021 19:12 > > To: dev-security-policy@lists.mozilla.org > > Cc: Ben Wilson > > Subject: Re: Public Discussion of GlobalSign's CA Inclusion Request for > R46, > > E46, R45 and E45 Roots > > > > On Tue, 9 Feb 2021 14:29:15 -0700 > > Ben Wilson via dev-security-policy > > wrote: > > > > > All, > > > GlobalSign has provided a very detailed incident report in Bugzilla - > > > see https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c2. > > > There are a few remaining questions that still need to be answered, so > > > this email is just to keep you aware. > > > Hopefully later this week I'll be able to come back and see if people > > > are satisfied and whether we can proceed with the root inclusion > > > request. > > > > I have a question (if I should write it in Bugzilla instead please say so > it is unclear > > to me what the correct protocol is) > > > > GlobalSign have provided a list of 112 other certificates which were > issued for the > > same reason, I examined some of them manually and determined that they > are > in > > appearance unextraordinary (2048-bit RSA keys for example) and so it's > > unsurprising we didn't notice they were issued previously. > > > > However, the list does not tell me when these certificates were ordered > or, if > > substantially different, when the email used to "validate" these orders > was sent. > > > > As a result it's hard to be sure whether these certificates were issued > perhaps > > only a few weeks after they were ordered, which is a relatively minor > oversight, > > or, like the incident certificate, many years afterwards. I'd like maybe > a > column of > > "order date" and "email sent date" if the two can be different. > > > > - > > > > I also have noticed something that definitely isn't (just) for > GlobalSign. > It seems to > > me that the current Ten Blessed Methods do not tell issuers to prevent > robots > > from "clicking" email links. We don't need a CAPTCHA, just a "Yes I want > this > > certificate" POST form ought to be enough to defuse typical "anti-virus", > "anti- > > malware" or automated crawling/ cache building robots. Maybe I just > missed > > where the BRs tell you to prevent that, and hopefully even without > prompting all > > issuers using the email-based Blessed Methods have prevented this, > > > > > > Nick. > > ___ > > 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.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports
I'm fine with that suggestion. On Fri, Feb 12, 2021 at 5:06 AM malcol...--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, 11 February 2021 at 21:14:13 UTC, Ben Wilson wrote: > > 11. all incidents (as defined in section 2.4), including those reported > in > > Bugzilla, that were: > > * disclosed by the CA or discovered by the auditor, and > > * unresolved at any time during the audit period; > > > > The idea is that all "incidents" must be reported if they were > "unresolved" > > - which would include those that occurred or were open - at any time > during > > the audit period. > > > > Wouldn't it be clearer to non-native English speakers to avoid the nuance > associated with "unresolved at any time" needing to imply both those that > occurred or those that were still open? > > Why not amend the language to just say: > > 11. all incidents (as defined in section 2.4), including those reported in > Bugzilla, that: > * were disclosed by the CA or discovered by the auditor, and > * occurred or were open at any time during the audit period; > ___ > 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: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots
Hi Nick We attached an updated version of the affected certificate overview to the bug on February 10, which does contain the date of order and date of issuance. Thanks Arvid > -Original Message- > From: dev-security-policy On > Behalf Of Nick Lamb via dev-security-policy > Sent: donderdag 11 februari 2021 19:12 > To: dev-security-policy@lists.mozilla.org > Cc: Ben Wilson > Subject: Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, > E46, R45 and E45 Roots > > On Tue, 9 Feb 2021 14:29:15 -0700 > Ben Wilson via dev-security-policy > wrote: > > > All, > > GlobalSign has provided a very detailed incident report in Bugzilla - > > see https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c2. > > There are a few remaining questions that still need to be answered, so > > this email is just to keep you aware. > > Hopefully later this week I'll be able to come back and see if people > > are satisfied and whether we can proceed with the root inclusion > > request. > > I have a question (if I should write it in Bugzilla instead please say so it is unclear > to me what the correct protocol is) > > GlobalSign have provided a list of 112 other certificates which were issued for the > same reason, I examined some of them manually and determined that they are in > appearance unextraordinary (2048-bit RSA keys for example) and so it's > unsurprising we didn't notice they were issued previously. > > However, the list does not tell me when these certificates were ordered or, if > substantially different, when the email used to "validate" these orders was sent. > > As a result it's hard to be sure whether these certificates were issued perhaps > only a few weeks after they were ordered, which is a relatively minor oversight, > or, like the incident certificate, many years afterwards. I'd like maybe a column of > "order date" and "email sent date" if the two can be different. > > - > > I also have noticed something that definitely isn't (just) for GlobalSign. It seems to > me that the current Ten Blessed Methods do not tell issuers to prevent robots > from "clicking" email links. We don't need a CAPTCHA, just a "Yes I want this > certificate" POST form ought to be enough to defuse typical "anti-virus", "anti- > malware" or automated crawling/ cache building robots. Maybe I just missed > where the BRs tell you to prevent that, and hopefully even without prompting all > issuers using the email-based Blessed Methods have prevented this, > > > Nick. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports
On Thursday, 11 February 2021 at 21:14:13 UTC, Ben Wilson wrote: > 11. all incidents (as defined in section 2.4), including those reported in > Bugzilla, that were: > * disclosed by the CA or discovered by the auditor, and > * unresolved at any time during the audit period; > > The idea is that all "incidents" must be reported if they were "unresolved" > - which would include those that occurred or were open - at any time during > the audit period. > Wouldn't it be clearer to non-native English speakers to avoid the nuance associated with "unresolved at any time" needing to imply both those that occurred or those that were still open? Why not amend the language to just say: 11. all incidents (as defined in section 2.4), including those reported in Bugzilla, that: * were disclosed by the CA or discovered by the auditor, and * occurred or were open at any time during the audit period; ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
