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 > <[email protected]> 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
