Re: Use of information collected from problem reporting addresses for marketing?
On Tue, Jun 2, 2020 at 10:25 PM Paul Walsh via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I dislike being added to lists as much as the next person. There are > numerous reasons for what might have happened. Had you setup an address for > the purpose of contacting them, or any other company, you’d know for sure. > > My personal approach would be to ask them before emailing the list. And > I’m not pointing the finger because you decided to email the list :)) > > I’ve received some unsolicited emails from people here, but I’m lucky > because I appreciated each one - but they weren’t marketing emails. > > - Paul > > > >> On Jun 2, 2020, at 6:38 PM, Benjamin Seidenberg via dev-security-policy > wrote: > > Greetings: > > > > Today, I received a marketing email from one of the CAs in Mozilla's > > program (Sectigo). As far as I know, the only interactions I've ever had > > with this CA where they would have gotten my name and email address would > > be from me submitting problem reports to them (for compromised private > > keys). Therefore, I can only assume that they mined their problem report > > submissions in order to generate their marketing contact lists. As did I, not having done any business with Sectigo, on my personal email, which I’ve only ever used for problem reporting with them. > > > > This leads to two questions: > > > > 1.) Is anyone aware of any policies that speak to this practice? I'm not > > aware of anything in the BRs or Mozilla policy that speak to this, but > > there are many other standards, documents, audit regimes, etc., which are > > incorporated by reference that I am not familiar with, and so it's > possible > > one of them has something to say on this issue. > I’m not aware of any, although it seems a rather brazen and distasteful practice. > > > 2.) While I felt like this practice (if it happened the way I assumed) is > > inappropriate, is there a consensus from others that that is the case? If > > so, is there any interest in adding requirements to Mozilla's Policy > about > > handling of information from problem reports received by CAs? I think something more concrete is useful here before contemplating. I’m supportive of policies preventing such crass usages, but I’m worried CAs already take very liberal interpretations of things to be kept private in order to avoid transparency, and this might further embolden such shenanigans. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use of information collected from problem reporting addresses for marketing?
On Tue, Jun 02, 2020 at 06:38:12PM -0700, Benjamin Seidenberg via dev-security-policy wrote: > Today, I received a marketing email from one of the CAs in Mozilla's > program (Sectigo). As far as I know, the only interactions I've ever had > with this CA where they would have gotten my name and email address would > be from me submitting problem reports to them (for compromised private > keys). Therefore, I can only assume that they mined their problem report > submissions in order to generate their marketing contact lists. I've sent several hundred certificate problem reports to a number of CAs in the past few months, and I'm yet to get marketing spam from Sectigo as a result. I have had one (suspected) scrape-from-problem-report incident from a different CA, but I can't be 100% sure, since I was at that time still sending out problem reports from my personal address. I now use per-report plus-addressed addresses that go to a dedicated account -- its possible that the spamcannons don't recognise + as a valid local-part character, though. > 1.) Is anyone aware of any policies that speak to this practice? I'm not > aware of anything in the BRs or Mozilla policy that speak to this, but > there are many other standards, documents, audit regimes, etc., which are > incorporated by reference that I am not familiar with, and so it's possible > one of them has something to say on this issue. No, I am not aware of anything specific to CAs/PKIs that would prohibit such a practice. You'd need to fall back to general data-handling legislation like GDPR, California's new statute, and so on (as relevant to your jurisdiction). > 2.) While I felt like this practice (if it happened the way I assumed) is > inappropriate, is there a consensus from others that that is the case? If > so, is there any interest in adding requirements to Mozilla's Policy about > handling of information from problem reports received by CAs? It's certainly dumb as rocks, because the sort of people who are reporting problems to CAs are not, by and large, the sort of people who are going to be purchasing managers for things like managed PKI, and those same people are also probably going to be the sort of people who are not fans of getting spammed. However, Rule 1, I believe, is that spammers are dumb. If they weren't, they wouldn't scrape whois data for abuse reporting addresses... As far as making requirements in Mozilla Policy, I have my doubts that it'd really fly. As you note, the far more risky problem of having problem reporters exposed to potential unpleasantness from incompetent subscribers being unhappy at the wrong people: > I do recall a discussion a while back on this list where a reporter had > their information forwarded on to the certificate owner and got > unpleasant emails in response and was asking whether the CAs were obligated > to protect the identity of the reporters, but I don't recall any > conclusions being reached. was not conclusively addressed, and so I doubt there would be much interest in a rule that said "thou shalt not spam people who report problems". For all those reasons and more, I've switched to a separate e-mail account and per-reort addresses -- no (obvious) human to threaten with spurious lawsuits, and if I get spam it's blindingly obvious where it came from. The automated reporting system I've setup also watches OCSP for revocation times and keeps full and complete records of all correspondence and timestamps, so I can tell exactly what (for example) the reporting timeframes were, and whether the BR requirements were met. On that front, actually, would it be of any use to you (or others) if there was a way to route your problem reports through my Revokinator system? It'd give you some amount of protection against spam and the such like, and built-in OCSP / revocation time tracking. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use of information collected from problem reporting addresses for marketing?
I dislike being added to lists as much as the next person. There are numerous reasons for what might have happened. Had you setup an address for the purpose of contacting them, or any other company, you’d know for sure. My personal approach would be to ask them before emailing the list. And I’m not pointing the finger because you decided to email the list :)) I’ve received some unsolicited emails from people here, but I’m lucky because I appreciated each one - but they weren’t marketing emails. - Paul >> On Jun 2, 2020, at 6:38 PM, Benjamin Seidenberg via dev-security-policy >> wrote: > Greetings: > > Today, I received a marketing email from one of the CAs in Mozilla's > program (Sectigo). As far as I know, the only interactions I've ever had > with this CA where they would have gotten my name and email address would > be from me submitting problem reports to them (for compromised private > keys). Therefore, I can only assume that they mined their problem report > submissions in order to generate their marketing contact lists. > > This leads to two questions: > > 1.) Is anyone aware of any policies that speak to this practice? I'm not > aware of anything in the BRs or Mozilla policy that speak to this, but > there are many other standards, documents, audit regimes, etc., which are > incorporated by reference that I am not familiar with, and so it's possible > one of them has something to say on this issue. > > 2.) While I felt like this practice (if it happened the way I assumed) is > inappropriate, is there a consensus from others that that is the case? If > so, is there any interest in adding requirements to Mozilla's Policy about > handling of information from problem reports received by CAs? > > I do recall a discussion a while back on this list where a reporter had > their information forwarded on to the certificate owner and got > unpleasant emails in response and was asking whether the CAs were obligated > to protect the identity of the reporters, but I don't recall any > conclusions being reached. > > Good Day, > Benjamin > ___ > 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
Use of information collected from problem reporting addresses for marketing?
Greetings: Today, I received a marketing email from one of the CAs in Mozilla's program (Sectigo). As far as I know, the only interactions I've ever had with this CA where they would have gotten my name and email address would be from me submitting problem reports to them (for compromised private keys). Therefore, I can only assume that they mined their problem report submissions in order to generate their marketing contact lists. This leads to two questions: 1.) Is anyone aware of any policies that speak to this practice? I'm not aware of anything in the BRs or Mozilla policy that speak to this, but there are many other standards, documents, audit regimes, etc., which are incorporated by reference that I am not familiar with, and so it's possible one of them has something to say on this issue. 2.) While I felt like this practice (if it happened the way I assumed) is inappropriate, is there a consensus from others that that is the case? If so, is there any interest in adding requirements to Mozilla's Policy about handling of information from problem reports received by CAs? I do recall a discussion a while back on this list where a reporter had their information forwarded on to the certificate owner and got unpleasant emails in response and was asking whether the CAs were obligated to protect the identity of the reporters, but I don't recall any conclusions being reached. Good Day, Benjamin ___ 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
I have now reviewed Microsec's updated CPS for OV and DV. I am not going
to hold up approval of the inclusion of this root for the following
reasons, which I believe are relatively minor, but Microsec should be aware
that:
- section 3.1.1 of Microsec's "eIDAS conform Certificate for Website
Authentication CPS" (
https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.14.pdf) ("the
CPS") appears to allow certain identifiers, allowed for EV, but not yet
added to the Baseline Requirements, see
https://cabforum.org/2019/05/21/ballot-sc17-version-7-alternative-registration-numbers-for-ev-certificates/.
This is something that should be taken up with the CA/Browser Forum (and
corrected in Microsec's CPS); and
- section 4.9.5 of the CPS, which states, "Emails arriving out of office
hours are considered as arrived at the beginning of the next business day."
This may put Microsec at risk of a violation of the Baseline Requirements
sections 4.9.1 through 4.9.5. While "receipt" (or "arrival") is not yet
defined in the Baseline Requirements, there is an expectation of 24x7
availability, which it appears Microsec is providing - "The Trust Service
Provider maintains a continuous 24x7 ability to respond internally to a
High Piority Certificate Problem Report."
This concludes my review of the Microsec CPs/CPSes, and I believe it is now
appropriate to begin the process of adding this root CA into NSS (without
EV enablement).
On Thu, May 28, 2020 at 1:00 PM Ben Wilson wrote:
> In accordance with the CA inclusion process,[1] this is a summary of the
> public discussion of Microsec’s application for inclusion of the e-Szigno
> Root CA 2017 into the Mozilla root store, and to EV enable it and the
> currently-included e-Szigno Root CA 2009. The request is documented in
> Bugzilla #1445364.[2] The public discussion began on 9-March-2020.[3] The
> email launching the public discussion and comments received during the
> public discussion raised a number of issues, not all of which are itemized
> here, including:
>
> * the CPS was unclear about certificate problem reporting and revocation
> request processing[4]; and
>
> * Microsec has had systemic, standards-related non-conformities, e.g. Bug#
> 1622539[5], and needs to demonstrate better behavior in keeping up with and
> complying with the CABF Baseline Requirements and root store policy.[6]
>
> Microsec is resolving these concerns by:
>
> - updating its CPS[7][8]; and
>
> - committing to engage in better compliance with industry standards[9].
>
> In my opinion Microsec has demonstrated sufficient response that we do not
> need to remove Microsec from Mozilla’s root store. Therefore, once I am
> satisfied after a review of the updated CPS, I am planning to recommend
> that we approve the request to include the e-Szigno Root CA 2017
> certificate and enable the websites trust bit. However, I plan to deny
> the request for EV treatment for both root certificates. Microsec may
> re-apply by filing a new request for EV treatment after they have
> demonstrated improved compliance with the BRs and EV Guidelines.
>
> I appreciate any feedback on this proposed course of action.
>
> [1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
>
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1445364
>
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ
>
> [4]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/KN-gnSLLAAAJ
>
>
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1622539
>
> [6]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/T7hcaOYGAQAJ
>
>
> [7]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/pyZKc40_CQAJ
>
>
> [8]
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/1L0crAafm30
>
>
> [9]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/mNFZGgXBAgAJ
>
>
>
> On Mon, Apr 20, 2020 at 5:44 AM Sándor dr. Szőke via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>> Dear Ben,
>>
>> I confirm that Microsec will correct all issues in the CP and CPS
>> documents as promised during the public discussion.
>>
>> Thanks to everyone who took the time to read Microsec CP and CPS and to
>> comment on them.
>>
>> If there are no more comments on the content of our CP and CPS documents
>> in the public discussion, we will review the thread again and gather all
>> the issues to be resolved.
>> As usual, Microsec will review current versions of all applicable
>> requirements for changes.
>>
>> I confirm that the section 1.5.2 will be changed. The High Priority
>> Certificate Problem Report will be reviewed and will be moved here from
>> section 4.9.3.
>>
>> Other issues I can see after a brief overview:
>> - Preliminary report in case of Certificate problem report in section
>> 4.9.5
>> - correct the reference to section 1.3.1 instead of 1.2 in
Re: Audit Reminders for Intermediate Certs
Forwarded Message Subject: Summary of June 2020 Outdated Audit Statements for Intermediate Certs Date: Tue, 2 Jun 2020 14:00:11 + (GMT) intermediate certs chaining up to root certs in Mozilla's program.> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
