Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours
On Tue, Mar 31, 2020 at 01:34:27PM +1100, Matt Palmer wrote: > If someone would like to make the argument that it's a gray area because I > submitted the revocation requests via ACME, rather than the CPS-provided > e-mail address, well, I can switch to sending e-mails, but having a human > process all the revocation requests is unlikely to be a better use of > everyone's time. ... aaand they did (https://bugzilla.mozilla.org/show_bug.cgi?id=1625322#c2). Oh well, I guess someone at Let's Encrypt is going to have a bit more to do from now on. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours
On Mon, Mar 30, 2020 at 06:01:58PM -0400, Ryan Sleevi wrote: > On Mon, Mar 30, 2020 at 5:43 PM Matt Palmer via dev-security-policy > wrote: > > > > On Mon, Mar 30, 2020 at 01:48:28PM -0700, Josh Aas via dev-security-policy > > wrote: > > > Matt - It would be helpful if you could report issues like this to the CA > > > in question, not just to mdsp. > > > > Helpful to *whom*, exactly? I don't write up these reports to be helpful to > > the CA in question; I write them to be helpful to the community. I don't > > see how reporting these problems to an individual CA is helpful to anyone > > except that one CA -- which, as I said, is not a goal I am aiming for here. > > I don't think that's quite a particularly helpful stance to take :) > Or, put differently, "why not both" Yes, I might have put it a bit harshly, and I apologise for that. I was somewhat taken aback by the implication of hiding problems by reporting to them to the CA, rather than to the community. > That said, your specific incident was in the gray area, where you'd > already previously reported compromise and the CA issued certs with > known compromised keys. You shouldn't "have" to report those new keys, > but it's still good form. I *have* been reporting additional certificates using the same compromised key, using the ACME revocation endpoint provided by the CA, and indicating that the reason for requesting certificate revocation was key compromise. I don't see how it's a "gray area", though, except insofar as multiple CAs have misinterpreted the BRs in roughly the same way. If someone would like to make the argument that it's a gray area because I submitted the revocation requests via ACME, rather than the CPS-provided e-mail address, well, I can switch to sending e-mails, but having a human process all the revocation requests is unlikely to be a better use of everyone's time. > > At any rate, since (as I understand it) all CAs are supposed to be watching > > mdsp anyway, sending a report here should be equivalent to sending it to all > > CAs -- including Let's Encrypt -- anyway. > > Ish? https://wiki.mozilla.org/CA/Incident_Dashboard specifically > encourages reporters to file a new incident bug. I don't see that that page *discourages* reporters from posting to mdsp. My point, though, is that Josh asked for a report to be sent to Let's Encrypt, all CAs are supposed to watch mdsp, therefore sending to mdsp should satisfy Josh's request for a copy to be sent to Let's Encrypt. > https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report > allows CAs to post to m.d.s.p. and a member will convert to a bug, but > I don't think it should be, nor do I want, m.d.s.p. to be the general > catch-all reporting mechanism for general users :) For one, as you can > see by my timeliness to the threads, it makes it hard to respond and > triage appropriately. I did look into creating CA Compliance bugs directly, however I'm not 100% confident of what counts as a compliance issue (as you've seen with some of my past posts). Also, bugzilla uses a mail relay which is blocked on my mail server (AWS' Spam Emission Service), and there's nothing in the SMTP transaction I can use to whitelist *just* Bugzilla's emails. So I can't create an account, and so I can't create bugs (or make snarky comments about why CAs haven't updated their open bugs in three weeks -- which you may count as a positive, perhaps?) - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal for New CA Certificate Policy Module Owner
This change has been made and Kathleen Wilson is now the CA Certificate Policy Module Owner. On Fri, Mar 20, 2020 at 1:34 PM Wayne Thayer wrote: > I posted the following message in the mozilla.governance forum. > > If you would like, please feel free to comment here in m.d.s.p. > > - Wayne > > -- Forwarded message - > From: Wayne Thayer > Date: Fri, Mar 13, 2020 at 11:11 AM > Subject: Proposal for New CA Certificate Policy Module Owner > To: > > > I’d like to propose making Kathleen Wilson the new owner of the “CA > Certificate Policy” module. Since leaving my job at Mozilla in January I > have continued to provide oversight for this module, and I intend to remain > involved in the future. However, given my diminished focus on this > important work, I believe now is a good time to transition the > responsibility for this module back to Kathleen. > > As an emeritus owner of this module, owner of the CA Certificates module, > and long-time member of this community, Kathleen's qualifications speak for > themselves. For reference, Kathleen became CA Certificates Module owner and > CA Certificate Policy peer in August 2010 [1] and CA Certificate Policy > Module owner in January 2012 [2]. She led the updates to the following > versions of Mozilla Root Store Policy [3]: 2.0, 2.1, 2.2. Kathleen has been > writing and maintaining CA program wiki pages since 2010. [4] > > There are two modules related to Mozilla’s CA Program which govern the > default set of certificates in Network Security Services (NSS) and > distributed in Mozilla’s software products. They are: > > 1) Mozilla CA Certificate Policy [5] > Description: Definition and enforcement of policies governing > Certification Authorities, their root certificates included in Mozilla > software products, and intermediate and end-entity certificates within > those CA hierarchies. > Current Owner: Wayne Thayer -- Proposed Owner: Kathleen Wilson > Current Peer(s): Kathleen Wilson -- Proposed Peer: Wayne Thayer > > 2) CA Certificates [6] > Description: Determine which root certificates should be included in > Mozilla software products, which trust bits should be set on them, and > which of them should be enabled for EV treatment. Evaluate requests from > Certification Authorities (CAs) for inclusion or removal of root > certificates, and for updating trust bit settings or enabling EV treatment > for already included root certificates. > Owner: Kathleen Wilson -- no change > Peer(s): Ryan Sleevi, Wayne Thayer -- no change > > Thanks, > > Wayne > > [1] > https://groups.google.com/d/msg/mozilla.governance/doYvOMfMuJc/aSt4aTEj4HMJ > [2] > https://groups.google.com/d/msg/mozilla.dev.security.policy/euJzuS737-Q/hX94NnNF5xUJ > [3] https://wiki.mozilla.org/CA/Root_Store_Policy_Archive > [4] > https://groups.google.com/d/msg/mozilla.dev.security.policy/qiSIaQ6ZvyU/fY7JD4EUd9QJ > [5] https://wiki.mozilla.org/Modules/All#Mozilla_CA_Certificate_Policy > [6] https://wiki.mozilla.org/Modules/All#CA_Certificates > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours
On Mon, Mar 30, 2020 at 5:43 PM Matt Palmer via dev-security-policy wrote: > > On Mon, Mar 30, 2020 at 01:48:28PM -0700, Josh Aas via dev-security-policy > wrote: > > Matt - It would be helpful if you could report issues like this to the CA > > in question, not just to mdsp. > > Helpful to *whom*, exactly? I don't write up these reports to be helpful to > the CA in question; I write them to be helpful to the community. I don't > see how reporting these problems to an individual CA is helpful to anyone > except that one CA -- which, as I said, is not a goal I am aiming for here. I don't think that's quite a particularly helpful stance to take :) Or, put differently, "why not both" That said, your specific incident was in the gray area, where you'd already previously reported compromise and the CA issued certs with known compromised keys. You shouldn't "have" to report those new keys, but it's still good form. > At any rate, since (as I understand it) all CAs are supposed to be watching > mdsp anyway, sending a report here should be equivalent to sending it to all > CAs -- including Let's Encrypt -- anyway. Ish? https://wiki.mozilla.org/CA/Incident_Dashboard specifically encourages reporters to file a new incident bug. https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report allows CAs to post to m.d.s.p. and a member will convert to a bug, but I don't think it should be, nor do I want, m.d.s.p. to be the general catch-all reporting mechanism for general users :) For one, as you can see by my timeliness to the threads, it makes it hard to respond and triage appropriately. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours
On Mon, Mar 30, 2020 at 01:48:28PM -0700, Josh Aas via dev-security-policy wrote: > Matt - It would be helpful if you could report issues like this to the CA > in question, not just to mdsp. Helpful to *whom*, exactly? I don't write up these reports to be helpful to the CA in question; I write them to be helpful to the community. I don't see how reporting these problems to an individual CA is helpful to anyone except that one CA -- which, as I said, is not a goal I am aiming for here. At any rate, since (as I understand it) all CAs are supposed to be watching mdsp anyway, sending a report here should be equivalent to sending it to all CAs -- including Let's Encrypt -- anyway. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: prohibit issuance of new certificates with known-compromised keys, and for related purposes
On Mon, Mar 30, 2020 at 10:59:02AM -0400, Ryan Sleevi wrote: > On Mon, Mar 30, 2020 at 6:28 AM Matt Palmer via dev-security-policy > wrote: > It's useful to focus on the goal, rather than the precise language, or > where you see folks getting confused or misunderstanding things. That > is, making sure we have a common understanding of the problems here. Righto, the goals are: * Make it a policy violation for CAs to issue a certificate using a public key they've revoked before. * Clarify the language around key compromise revocation to make it obvious that CAs have to revoke everything with a given private key. * Clarify the language around revocation time limits to make it obvious that the time period starts when the communication leaves the reporter. > > Step 1: add a new section 4.2.3 (pushing down the existing 4.2.3 to be > > 4.2.4, because RFC3647 says that "Finally, this subcomponent sets a time > > limit", which I assume means that the time limit section needs to be last), > > worded something like this: > > Well, no, that doesn't work with https://tools.ietf.org/html/rfc3647#section-6 Drat. Makes it hard to fit key checks into there anywhere, then. Shoehorn it into 4.2.2, perhaps? > > I know that Section 5.5.2 only requires storage of records for seven years; > > I figure if someone's going to hold onto a compromised private key for seven > > years just so they can bring it out for another cert, then they've earned > > the right to get their cert revoked again. Requiring CAs to maintain a list > > of keys in perpetuity may be considered an overly onerous burden. > > I don't think we want the explicit dependency on 5.5.2, because it > would be good to reduce that time in line with reducing certificate > lifetimes. > > The 7 years is derived from the validity period of the certificates > being issued (at the time, up to 10 year certs; 7 years was a > compromise between the 5 years the BRs were phasing in and the 10y+ > existing practice) Huh, that's interesting; I figured the 7 year requirement was in line with other standard business record-keeping requirements, like tax records. > By this logic, Debian weak keys would not need to be blocked, because > that even occurred in 2006. Hmm, no, unless the CA had previously issued a certificate for every Debian weak key and subsequently revoked them for key compromise. The existing provisions regarding Debian weak keys (as potentially to-be-amended in the near future) would still be in force, with no expiry time limit. I, personally, do not have a problem with mandating that CAs keep records of compromised keys in perpetuity. > Broadly, it seems your problem that this first proposal is trying to > solve is that CAs don't see it as logical that they must maintain a > database of revoked keys. Is that a fair statement? Close, but I'll quibble with "logical", and I dislike talking about "revoked keys" because it gives people the wrong mental shorthand -- you can't "revoke" a key, as such. Although I suppose published attestations of compromise are pretty close to a kind of OKSP, if you wanted to think that way. I'd rather word it as: "CAs don't see it as necessary that they must maintain a database of keys from *all* certificates they revoked for key compromise, and that they must check that database before issuance." > > Step 2: Replace the existing text of section 4.9.12 with something like the > > following: > > > > > In the event that the CA obtains evidence of Key Compromise, all > > > Certificates issued by the CA which contain the compromised key MUST be > > > revoked as per the requirements of Section 4.9.1.1, including the time > > > period requirements therein, even if no Certificate Problem Report for a > > > given Certificate has been received by the CA. > > > > In a perfect world, this sentence wouldn't be necessary, because 4.9.1.1 > > doesn't say that the certificate has to be revoked if a problem report comes > > in alleging key compromise, but since CAs don't appear to have interpreted > > 4.9.1.1 in that way, we may as well use 4.9.12 for a good purpose and > > clarify the situation. > > While I appreciate the suggestion, I'm worried this does more to sow > confusion rather than bring clarity. As you note, 4.9.1.1 is liked to > evidence about the Private Key, not the Certificate, so this is > already a "clear" requirement. What about it sows (additional) confusion? > I think we'd want to understand why/how CAs are misinterpreting this. > I think we've seen a common thread, which is CAs thinking about > systems in terms of Certificates, rather than thinking about Keys and > Issuers. We've seen that problem systemically come up in other areas, > such as OCSP, Precertificates, and SHA-1. > > Does that seem to track with the root cause of the problem? That is, > that this is an existing requirement, but CAs aren't recognizing it as > such? Yes, I certainly believe that you and I are in agreement that this is
Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours
On Monday, March 30, 2020 at 4:48:38 PM UTC-4, Josh Aas wrote: > On Thursday, March 26, 2020 at 6:27:10 PM UTC-4, Ryan Sleevi wrote: > > Apologies for the delay here. I filed > > https://bugzilla.mozilla.org/show_bug.cgi?id=1625322 for this. > > We are looking into this. > > Matt - It would be helpful if you could report issues like this to the CA in > question, not just to mdsp. We can review and respond faster. So far as I > know we were never contacted. You can use our secur...@letsencrypt.org email > address in the future. Thanks. It seems that Matt did report to our community forums. I'd like to encourage people to report known or potential security issues to our security@ address. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours
On Thursday, March 26, 2020 at 6:27:10 PM UTC-4, Ryan Sleevi wrote: > Apologies for the delay here. I filed > https://bugzilla.mozilla.org/show_bug.cgi?id=1625322 for this. We are looking into this. Matt - It would be helpful if you could report issues like this to the CA in question, not just to mdsp. We can review and respond faster. So far as I know we were never contacted. You can use our secur...@letsencrypt.org email address in the future. Thanks. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
Dear All, Microsec Ltd. is dedicated to comply with the standards and industry best practices at all times, including the applicable IETF RFCs, ETSI standards and technical specifications, CA/Browser Forum Baseline Requirements, Extended Validation Guidelines and Network Security Controls, as well as the Mozilla Root Store Policy and other root program policies. Being an EU-based Qualified Trust Service Provider, our trust services are regulated and nationally supervised under the Regulation (EU) No 910/2014 (eIDAS), which mandates the annual conformity assessment by an accredited conformity assessment body. In order to comply with all the latest legal and technical requirements, our CP/CPS documents incorporate all requirements from the above mentioned applicable sources, and we actively monitor the updates of the IETF RFCs, ETSI standards, CA/Browser Forum documents and the Mozilla Root Store Policy and other root program policies. As changes in the totality of requirements occur quite frequently, we regularly update our practices and develop our systems to ensure compliance with the changes too. Our annual conformity assessment, performed by TÜV Informationstechnik GmbH (TÜViT), is always based on the current version of the standards, as detailed in the Audit Attestation. Microsec greatly appreciates the detailed evaluation of our inclusion request, as well as the automated checks in the CCADB, since these enhance transparency and contribute to the security of the ecosystem. We welcome the opportunity to engage in the public discussion, to provide supporting information that none of the findings of the evaluation represent a significant risk for Mozilla users, and to take away any useful advice which might help us further improve our practices and documentation. Regarding the findings, please consider the information and explanations provided in our previous postings to this thread and several other threads, which are summarized in the following: 2020-03-09 - the thread was opened by Kathleen Wilson 2020-03-11 - First responses which were published one day later due to moderator approval delay. At first, Microsec gave some background information regarding the relatively high number of audit findings: https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/78T_0HWkAQAJ Then, Microsec uploaded the first answers to the original ===Meh=== and ===Bad=== findings of Wayne: https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/xNUov3WkAQAJ 2020-03-12 – Discussion to clarify the proper place of the Private Key Compromise information in CPS https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/1L0crAafm30 2020-03-13 – Incident report about the Issuance of 2 IVCP precertificates without givenName, surName, localityName fields https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C8YdPLAmCOE The evaluation of the issue runs according to the planned schedule. 2020-03-24 – Discussion: Microsec: Revoked subordinate CA certificates under the „Microsec e-Szigno Root CA 2009” root https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/QqYm4BhFMHs It is a complex issue and it is probably better to explain it in a separate discussion than as part of the present thread. Wayne asked to transform this information into a formal incident report. Microsec will do it soon. 2020-03-24 - Short explanations for the year 2018 audit findings: https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/iiMVWwQGBAAJ 2020-03-27 - Short explanations for the year 2019 audit findings: https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/ofERMFLnAQAJ We hope the above information reinforces that our procedures are reliable, and our certificates are trustworthy. We would like to thank Wayne, Matt, Ryan and all members of the forum for your valued feedback, which we can use as input to our continuous efforts to improve the clarity of our documentation and the high quality of our services. We remain open to constructive discussion regarding our inclusion request, as always. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: prohibit issuance of new certificates with known-compromised keys, and for related purposes
Thanks for starting this! On Mon, Mar 30, 2020 at 6:28 AM Matt Palmer via dev-security-policy wrote: > If such a modification were deemed appropriate for the BRs, I would suggest > that the following changes would fit the bill. All sections, etc taken from > version 1.6.7 of the BRs. Discussing changes to the BRs here are a bit complicated, for IP reasons (And no, disclaiming IP doesn't make this go away) It's useful to focus on the goal, rather than the precise language, or where you see folks getting confused or misunderstanding things. That is, making sure we have a common understanding of the problems here. > > Step 1: add a new section 4.2.3 (pushing down the existing 4.2.3 to be > 4.2.4, because RFC3647 says that "Finally, this subcomponent sets a time > limit", which I assume means that the time limit section needs to be last), > worded something like this: Well, no, that doesn't work with https://tools.ietf.org/html/rfc3647#section-6 > I know that Section 5.5.2 only requires storage of records for seven years; > I figure if someone's going to hold onto a compromised private key for seven > years just so they can bring it out for another cert, then they've earned > the right to get their cert revoked again. Requiring CAs to maintain a list > of keys in perpetuity may be considered an overly onerous burden. I don't think we want the explicit dependency on 5.5.2, because it would be good to reduce that time in line with reducing certificate lifetimes. The 7 years is derived from the validity period of the certificates being issued (at the time, up to 10 year certs; 7 years was a compromise between the 5 years the BRs were phasing in and the 10y+ existing practice) By this logic, Debian weak keys would not need to be blocked, because that even occurred in 2006. Broadly, it seems your problem that this first proposal is trying to solve is that CAs don't see it as logical that they must maintain a database of revoked keys. Is that a fair statement? > Step 2: Replace the existing text of section 4.9.12 with something like the > following: > > > In the event that the CA obtains evidence of Key Compromise, all > > Certificates issued by the CA which contain the compromised key MUST be > > revoked as per the requirements of Section 4.9.1.1, including the time > > period requirements therein, even if no Certificate Problem Report for a > > given Certificate has been received by the CA. > > In a perfect world, this sentence wouldn't be necessary, because 4.9.1.1 > doesn't say that the certificate has to be revoked if a problem report comes > in alleging key compromise, but since CAs don't appear to have interpreted > 4.9.1.1 in that way, we may as well use 4.9.12 for a good purpose and > clarify the situation. While I appreciate the suggestion, I'm worried this does more to sow confusion rather than bring clarity. As you note, 4.9.1.1 is liked to evidence about the Private Key, not the Certificate, so this is already a "clear" requirement. I think we'd want to understand why/how CAs are misinterpreting this. I think we've seen a common thread, which is CAs thinking about systems in terms of Certificates, rather than thinking about Keys and Issuers. We've seen that problem systemically come up in other areas, such as OCSP, Precertificates, and SHA-1. Does that seem to track with the root cause of the problem? That is, that this is an existing requirement, but CAs aren't recognizing it as such? > Step 3: Insert a new paragraph at the end of section 4.9.1.1, with the > following contents (or a reasonable facsimile thereof): This isn't where the suggested requirements go. That's covered in 4.9.5 Did I miss reports where this seemed to be an issue? I didn't really see this one coming up, since 4.9.5 tried to make it pretty clear. Please feel free to highlight the incidents though, I'm happy to take a second look. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Musings on mass key-compromise revocations
On Sat, Mar 28, 2020 at 07:11:43PM +1100, Matt Palmer wrote: > In concert with my (human-mediated) revocation notifications, I have been > sending semi-automated revocation requests to Let's Encrypt, using the ACME > protocol. This has been extremely smooth and straightforward, and my life > -- and, I presume, the lives of the staff at the CAs I've reported > revocations to -- would be a lot easier if every CA had an equivalent > facility available. I think this is so useful, in fact, that I have started > coding a program capable of receiving key compromise revocations and > forwarding them via e-mail, which will be released as open source when it is > in a fit state for deployment. A follow-up to this part of my musings: I got a rush of the blood to the head over the weekend, and an initial release of this software is now available from https://github.com/tobermorytech/acmevoke. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Proposal: prohibit issuance of new certificates with known-compromised keys, and for related purposes
In my recent forays into mass-revocation for key compromise, one aspect that was particularly frustrating and unnecessary was having to send revocation requests for new certificates, issued by a CA using a private key which I had previously reported as compromised to that same CA. Once a key is compromised, it's never going to get *less* compromised, so there is no reason why a CA should ever be issuing another certificate using that same key. Also, the requirement to revoke all certificates with a compromised private key, regardless of whether a given certificate is explicitly listed in a certificate problem report, does not appear to be clear. Finally, CAs appear to have a variety of interpretations of the start time of the 24 hour period in which revocation must be completed, and so I thought I'd include a small change for that. Thus, I would like to propose that either Mozilla Policy, or (preferably) the Baseline Requirements be amended to prohibit issuance of a certificate where the CA has previously revoked a certificate using the same key, and to clarify that all certificates using a compromised key are subject to revocation. If such a modification were deemed appropriate for the BRs, I would suggest that the following changes would fit the bill. All sections, etc taken from version 1.6.7 of the BRs. Step 1: add a new section 4.2.3 (pushing down the existing 4.2.3 to be 4.2.4, because RFC3647 says that "Finally, this subcomponent sets a time limit", which I assume means that the time limit section needs to be last), worded something like this: > In accordance with Section 5.5.2, the CA SHALL maintain an internal > database of all Public Keys contained in Certificates which have been > revoked due to the CA obtaining evidence of Key Compromise. This > requirement exists regardless of the revocation reason (if any) published > in Certificate status information. > > The CA SHALL NOT issue a Certificate containing a Public Key which the CA > has previously recorded as having been used in a Certificate revoked due > to the CA obtaining evidence of Key Compromise. I know that Section 5.5.2 only requires storage of records for seven years; I figure if someone's going to hold onto a compromised private key for seven years just so they can bring it out for another cert, then they've earned the right to get their cert revoked again. Requiring CAs to maintain a list of keys in perpetuity may be considered an overly onerous burden. Step 2: Replace the existing text of section 4.9.12 with something like the following: > In the event that the CA obtains evidence of Key Compromise, all > Certificates issued by the CA which contain the compromised key MUST be > revoked as per the requirements of Section 4.9.1.1, including the time > period requirements therein, even if no Certificate Problem Report for a > given Certificate has been received by the CA. In a perfect world, this sentence wouldn't be necessary, because 4.9.1.1 doesn't say that the certificate has to be revoked if a problem report comes in alleging key compromise, but since CAs don't appear to have interpreted 4.9.1.1 in that way, we may as well use 4.9.12 for a good purpose and clarify the situation. Step 3: Insert a new paragraph at the end of section 4.9.1.1, with the following contents (or a reasonable facsimile thereof): > The time periods specified in this Section SHALL BE measured from the time > that the communication which requests, notifies, makes the CA aware, > provides evidence which the CA later deems valid, or as otherwise > described above, is first received by a system or person acting on the > CA's behalf for the receipt of such communications. I know that's a phat sentence, but I wanted to try and get all the circumstances in there, to prevent another round of "BUT BUT BUT" in the future. Essentially, what I'm trying to get across is, "once it hits your MTA or phone tree, the clock starts ticking". No leaving a problem report in the inbox over the weekend and then claiming that they didn't "obtain evidence" until monday morning. ... and that's about it. Please tear my wording, rationale, and choice of font to pieces as you see fit. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
