DigiCert currently has a policy of not publishing the names of those who report things to us without their permission. It just seems like the right thing to do.
If we do find that people are abusing that protection to selectively harass people that they personally have issues with, we may need to revisit that, but we haven't seen any evidence that is currently happening. Most of the people who report issues to us are quite professional about it, and we're always happy to engage with them. I would be interested to hear what others think the appropriate behavior for a CA is here, since it isn't covered by any compliance requirements. -Tim > -----Original Message----- > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On > Behalf Of Jakob Bohm via dev-security-policy > Sent: Monday, August 19, 2019 8:22 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: CA handling of contact information when reporting problems > > On 20/08/2019 03:15, Corey Bonnell wrote: > > On Monday, August 19, 2019 at 10:26:06 AM UTC-4, Mathew Hodson wrote: > >> Tom Wassenberg on Twitter reported an experience he had with Sectigo > >> when reporting a compromised private key. > >> > >> https://twitter.com/tomwas54/status/1162114413148725248 > >> https://twitter.com/tomwas54/status/1162114465065840640 > >> https://twitter.com/tomwas54/status/1162114495017299976 > >> > >> "So a few weeks ago, I came across a private key used for a TLS > >> certificate, posted online. These should never be public (hence the > >> "private"), and every trusted CA is obliged to revoke any certificate > >> they issued when they become aware its private key is compromised. > >> > >> "So when I informed the issuing CA (@SectigoHQ) about this, they > >> promptly revoked the cert. Two weeks later however, I receive an > >> angry email from the company using the cert (cc'd to their lawyer), > >> blaming me for a disruption in the services they provide. > >> > >> "The company explicitly mentioned @SectigoHQ "was so kind" to give > >> them my contact info! It was a complete surprise for me that > >> @SectigoHQ would do this without my consent. Especially seeing how > >> the info was used to badger me." > >> > >> If these situations were common, it could create a chilling effect on > >> problem reporting that would hurt the WebPKI ecosystem. Are specific > >> procedures and handling of contact information in these situations > >> covered by the BRs or Mozilla policy? > > > > Many CAs disclose the reporter's name and email address as part of their > response to item 1 of the incident report template . So this information is > already publicly available if the Subscriber were so inclined to look for it. > > > > Section 9.6.3 of the BRs list the provisions that must be included in the > Subscriber Agreement that every Applicant must agree to. Notably, one of > them is protection of the private key. The Subscriber in this case materially > violated the Subscriber Agreement by disclosing their private key, so I don't > think they have much footing to go badgering others for problems that they > brought on themselves. > > > > Thanks, > > Corey > > > >  > > https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report > > > > The question was if this is appropriate behavior, when the incident is not at > the CA, but at a subscriber. This is typically different from the case of > security > researchers filing systemic CA issues for which they typically want public > recognition. > > Specificially, the question is one of whistleblower protection for the > reporter > (in the general sense of whistleblower protection, not that of any single > national or other whistleblower protection legal regime). > > On the other hand there is the question of subscribers having a right to face > their accuser when there might be a question of trust of subjectivity > (example: > Someone with trusted subscriber private key access maliciously sending it to > the CA to cause revocation for failure to protect said key). > > Situation would get much more complicated when the report is one of > claiming a subscriber violates a subjective rule, such as malicious cert use > or > name ownership conflicts. > > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public > discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > _______________________________________________ > dev-security-policy mailing list > email@example.com > https://lists.mozilla.org/listinfo/dev-security-policy
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list firstname.lastname@example.org https://lists.mozilla.org/listinfo/dev-security-policy