RE: CA handling of contact information when reporting problems
I'm not sure there should be a strict requirement that you can't provide that communication (sometimes there is good reason to get people talking together). However, we don't forward this information as policy because we like to get the reports. Anything that ends up stifling getting the information is worse for us and hinders getting third party input on improvements on our operation. A Mozilla policy or CAB forum policy against disclosure seems like a bad idea since there are cases of abuse that could happen give the broad range of potential reasons for revocation under the BRs, some of which may require corroboration between the reporter and site owner, like "accurate information" or "misuse". -Original Message- From: dev-security-policy On Behalf Of Matthew Hardeman via dev-security-policy Sent: Thursday, August 22, 2019 9:49 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CA handling of contact information when reporting problems I'm merely a relying party and subscriber, but it seems quite unreasonable to believe that there is or should be any restriction upon a party to a business communication (which is what a report / complaint from a third party regarding key compromise, etc, is) from further dissemination of said communications. It seems to me quite a stretch to suggest that the even the GDPR restrains such behavior. Are people seriously suggesting that a third party, with whom you have no NDA or agreement in place, may as much as email you and expect you to take action based upon said email AND expect that you be enjoined from as little as forwarding a copy of that email? That seems absurd. ___ 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: CA handling of contact information when reporting problems
I'm merely a relying party and subscriber, but it seems quite unreasonable to believe that there is or should be any restriction upon a party to a business communication (which is what a report / complaint from a third party regarding key compromise, etc, is) from further dissemination of said communications. It seems to me quite a stretch to suggest that the even the GDPR restrains such behavior. Are people seriously suggesting that a third party, with whom you have no NDA or agreement in place, may as much as email you and expect you to take action based upon said email AND expect that you be enjoined from as little as forwarding a copy of that email? That seems absurd. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: CA handling of contact information when reporting problems
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 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 [1]. 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 > > > > [1] > > 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 > 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: CA handling of contact information when reporting problems
On Monday, 19 August 2019 17:26:06 UTC+3, Mathew Hodson wrote: [...] > 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? >From my experience if something is already covered by legislation there >doesn't need to be a separate procedure for "complying with the law". Since that researcher is an EU citizen from Netherlands, the GDPR applies for his personal contact data and both Sectigo's and that "angry" company's actions are (possible) GDPR violations. Was there explicit consent given to Sectigo to forward his contact details to that company? Is that "angry" company even aware of the GDPR? (GDPR, article 6 and 7) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA handling of contact information when reporting problems
On Mon, Aug 19, 2019 at 10:26 AM Mathew Hodson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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? > No, there are not. This is not an uncommon practice within the broader realm of Security Incident Reporting / Disclosure, and has been the subject of much discussion and debate for 30+ years of computer security. You can find plenty of information about lawsuits intended to chill vulnerability disclosure. This is not a problem that can or will be solved within the BRs or Mozilla Policy. In general, anyone disclosing vulnerabilities should expect their information may be released. That's par for the course here. Different jurisdictions may have different protections, but reporters are encouraged to disclose directly with the CA. Root Store Operators may be willing to intermediate (e.g. disclosing to Mozilla's security reporting), but I'm also not aware of any strong guarantees Mozilla makes with respect to protecting the information of folks who report security issues, especially in the potential incident of (misguided, frivolous) lawsuits. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA handling of contact information when reporting problems
Hello, I am a bit shocked about this case. The fact that this happened to someone would restrain myself from reporting key compromises. Even though it is the company's fault to protect their private key, their lawers still might sue the incident-reporter. A judge might not understand the PKI system and therefore might tend to decide in favor of the company, because the company can proove that they lost XXX dollars revenue because of the service outtage. I think big companies have a lot of expensive lawers who might win such a case against a private person who might not even have the money for a good lawer at all. In re privacy: Telling someone the name and/or email address of a person without their consent is a clear violation of the GDPR (European General Data Protection Regulation), in case European law applies. Publishing the name and/or email address online (e.g. in the incident template) is even worse. Take care, Daniel Am Montag, 19. August 2019 16:26:06 UTC+2 schrieb Mathew Hodson: > 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? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 [1]. 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 [1] 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
