Re: Policy 2.6 Proposal: Require CAs to support problem reports via email
On Fri, Apr 20, 2018 at 12:33 PM, Wayne Thayer wrote:
> At this point we have a few choices:
>
> 1. Do nothing about requiring email as a problem reporting mechanism.
> Instead, take on the related issues of disclosure of the reporting
> mechanism and receipt confirmation in Mozilla policy, via the CAB Forum, or
> both.
> 2. Go ahead with the proposal to require email, but allow CAs to require
> some special, but standardized identifier be placed in the message that
> they can filter on. For example, CAs could ignore messages sent to their
> problem reporting address unless the subject contains the phrase "problem
> report".
> 3. Develop some new problem reporting mechanism that solves the problems
> with email and forms. For example, we could require CAs to accept problem
> reports posted to this list, but build in some additional time in which to
> "receive" the report by reading list messages. Or we could require CAs to
> accept problem reports via Bugzilla. We already see problems being reported
> via these mechanisms and require CAs to monitor both of them, just not on a
> 24x7 basis.
>
> The first option ('do nothing') is currently in the lead, so I would
> especially like to hear from anyone who wants to argue for a different
> solution.
>
>
This discussion has resulted in no agreed-upon changes to the Mozilla
policy. I will close the issue on GitHub [1], and I also plan to propose a
CAB Forum ballot that includes the requirement for CAs to disclose their
problem reporting mechanism in section 1.5.2 of their CPS.
- Wayne
[1] https://github.com/mozilla/pkipolicy/issues/98
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Require CAs to support problem reports via email
At this point we have a few choices:
1. Do nothing about requiring email as a problem reporting mechanism.
Instead, take on the related issues of disclosure of the reporting
mechanism and receipt confirmation in Mozilla policy, via the CAB Forum, or
both.
2. Go ahead with the proposal to require email, but allow CAs to require
some special, but standardized identifier be placed in the message that
they can filter on. For example, CAs could ignore messages sent to their
problem reporting address unless the subject contains the phrase "problem
report".
3. Develop some new problem reporting mechanism that solves the problems
with email and forms. For example, we could require CAs to accept problem
reports posted to this list, but build in some additional time in which to
"receive" the report by reading list messages. Or we could require CAs to
accept problem reports via Bugzilla. We already see problems being reported
via these mechanisms and require CAs to monitor both of them, just not on a
24x7 basis.
The first option ('do nothing') is currently in the lead, so I would
especially like to hear from anyone who wants to argue for a different
solution.
- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Require CAs to support problem reports via email
On 04/18/2018 10:51 PM, Dimitris Zacharopoulos via dev-security-policy wrote: >> 1 - it's easier. I have seen CAs use generic "support request" forms that >> are difficult to decipher, especially when not in one's native language. >> 2 - It scales better. When someone is trying to report the same >> problem to >> a number of CAs, one email is better than filling out a bunch of forms >> 3 - It automatically creates a record of the submission. Many forms >> provide >> the user no confirmation unless they remember to take a timestamped >> screen >> shot. >> > > Despite the arguments for email, there are equally good arguments for > web form submission. IMHO, both should be allowed. A CA could start with > email but if the spam volume becomes out of control, the CA might switch > to a web form solution and all we need to do is define the minimum > "properties" of such a solution. In all cases, CAs should maintain > up-to-date information for Certificate Problem Report submission methods > in CCADB. Although I much prefer email as a submission method myself, another argument is actually security. Given that most users (sadly) still don't use OpenPGP or S/MIME, a web form allows encrypted submissions. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Require CAs to support problem reports via email
On 18/4/2018 9:50 μμ, Wayne Thayer via dev-security-policy wrote: On Wed, Apr 18, 2018 at 12:14 AM, Dimitris Zacharopoulos via dev-security-policy wrote: On 18/4/2018 12:04 πμ, Jeremy Rowley via dev-security-policy wrote: Having to go through captchas to even get the email sent is just another obstacle in getting the CA a timely certificate problem report Nowadays, people deal with captchas all the time in various popular web sites. I don't understand this argument. Is someone wants to file a certificate problem report, they will take the extra "seconds" to pass the "I am not a robot" test :) The arguments for email are: When I wrote "I don't understand this argument" it was meant for the "having to go through captchas". Sorry, it wasn't very clear. 1 - it's easier. I have seen CAs use generic "support request" forms that are difficult to decipher, especially when not in one's native language. 2 - It scales better. When someone is trying to report the same problem to a number of CAs, one email is better than filling out a bunch of forms 3 - It automatically creates a record of the submission. Many forms provide the user no confirmation unless they remember to take a timestamped screen shot. Despite the arguments for email, there are equally good arguments for web form submission. IMHO, both should be allowed. A CA could start with email but if the spam volume becomes out of control, the CA might switch to a web form solution and all we need to do is define the minimum "properties" of such a solution. In all cases, CAs should maintain up-to-date information for Certificate Problem Report submission methods in CCADB. Mail servers receive tons of SPAM everyday and an email address target is a very easy target for popular CAs. We should also consider the possibility of accidental "spam labeling" of a certificate problem report via email. I believe CAs should include the necessary information for receiving Certificate Problem Reports in section 1.5.2 of their CP/CPS and this should be required by the Mozilla Policy for consistently. The same applies for the "high-priority" Certificate Problem Reports as mandated in 4.10.2 of the BRs. I plan to introduce a CAB Forum ballot for the 1.5.2 disclosure requirement. I disagree with the suggestion that Mozilla policy should duplicate the BRs "for consistency", but since Mozilla policy has a broader scope than the BRs (email certificates), I will plan to add this requirement. Currently the BRs don't mandate listing this particular information in 1.5.2, so there is no consistency among CAs. So far, CCADB has the best collection of this information and this was initiated by Mozilla in the April 2017 CA Communication. Historically, Mozilla had policies that passed on to the BRs and once they were in the BRs, they were removed from the Mozilla policy as duplicates :). We would support a ballot that would require CP/CPS sections 1.5.2 to describe the CA's specific Certificate Problem Report methods. Dimitris. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Require CAs to support problem reports via email
On Wed, Apr 18, 2018 at 2:50 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wed, Apr 18, 2018 at 12:14 AM, Dimitris Zacharopoulos via > dev-security-policy wrote: > > > On 18/4/2018 12:04 πμ, Jeremy Rowley via dev-security-policy wrote: > > > >> Having to go through captchas to even get the email sent is just another > >> obstacle in getting the CA a timely certificate problem report > >> > > > > Nowadays, people deal with captchas all the time in various popular web > > sites. I don't understand this argument. Is someone wants to file a > > certificate problem report, they will take the extra "seconds" to pass > the > > "I am not a robot" test :) > > > > The arguments for email are: > 1 - it's easier. I have seen CAs use generic "support request" forms that > are difficult to decipher, especially when not in one's native language. > 2 - It scales better. When someone is trying to report the same problem to > a number of CAs, one email is better than filling out a bunch of forms > While this optimizes for problem reporters, rather than receivers, I worry that the impact it would have to problem receivers - both in cost and effectiveness (particularly for spam) - will effectively disadvantage problem reporters. Being on the receiving end of several email aliases for security bugs, the noise to signal is... overwhelming. Even Mozilla now requires that security issues in Mozilla products be reported through Bugzilla, rather than email - and my understanding is for similar reasons. > 3 - It automatically creates a record of the submission. Many forms provide > the user no confirmation unless they remember to take a timestamped screen > shot. > While this is true, would an alternative solution be to require that problem reports receive a distinct confirmation ID (e.g. in the way that Mozilla assigns bug numbers to problems reported through Bugzilla?). As mentioned in the CA/Browser Forum regarding voting, there's a number of ways and reasons for which mail might be 'sent' by a client but not ever actually delivered to the recipient mailbox - hence the suggestion that email itself is not sufficient to constitute a vote, but that its availability on the public mail archives being that proof - aka, a stable, distinct identifier. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Require CAs to support problem reports via email
On Wed, Apr 18, 2018 at 12:14 AM, Dimitris Zacharopoulos via dev-security-policy wrote: > On 18/4/2018 12:04 πμ, Jeremy Rowley via dev-security-policy wrote: > >> Having to go through captchas to even get the email sent is just another >> obstacle in getting the CA a timely certificate problem report >> > > Nowadays, people deal with captchas all the time in various popular web > sites. I don't understand this argument. Is someone wants to file a > certificate problem report, they will take the extra "seconds" to pass the > "I am not a robot" test :) > > The arguments for email are: 1 - it's easier. I have seen CAs use generic "support request" forms that are difficult to decipher, especially when not in one's native language. 2 - It scales better. When someone is trying to report the same problem to a number of CAs, one email is better than filling out a bunch of forms 3 - It automatically creates a record of the submission. Many forms provide the user no confirmation unless they remember to take a timestamped screen shot. > Mail servers receive tons of SPAM everyday and an email address target is > a very easy target for popular CAs. We should also consider the possibility > of accidental "spam labeling" of a certificate problem report via email. > > I believe CAs should include the necessary information for receiving > Certificate Problem Reports in section 1.5.2 of their CP/CPS and this > should be required by the Mozilla Policy for consistently. The same applies > for the "high-priority" Certificate Problem Reports as mandated in 4.10.2 > of the BRs. > > I plan to introduce a CAB Forum ballot for the 1.5.2 disclosure requirement. I disagree with the suggestion that Mozilla policy should duplicate the BRs "for consistency", but since Mozilla policy has a broader scope than the BRs (email certificates), I will plan to add this requirement. > > Dimitris. > > ___ > 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: Policy 2.6 Proposal: Require CAs to support problem reports via email
On Wed, Apr 18, 2018 at 3:14 AM, Dimitris Zacharopoulos via dev-security-policy wrote: > Mail servers receive tons of SPAM everyday and an email address target is > a very easy target for popular CAs. We should also consider the possibility > of accidental "spam labeling" of a certificate problem report via email. > I have seen this happen with CAs when submitting problem reports on behalf of Google - so this definitely happens :) I've had to follow-up directly with contacts at the CA to make sure "they got it" in time. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.6 Proposal: Require CAs to support problem reports via email
On 18/4/2018 12:04 πμ, Jeremy Rowley via dev-security-policy wrote: Having to go through captchas to even get the email sent is just another obstacle in getting the CA a timely certificate problem report Nowadays, people deal with captchas all the time in various popular web sites. I don't understand this argument. Is someone wants to file a certificate problem report, they will take the extra "seconds" to pass the "I am not a robot" test :) Mail servers receive tons of SPAM everyday and an email address target is a very easy target for popular CAs. We should also consider the possibility of accidental "spam labeling" of a certificate problem report via email. I believe CAs should include the necessary information for receiving Certificate Problem Reports in section 1.5.2 of their CP/CPS and this should be required by the Mozilla Policy for consistently. The same applies for the "high-priority" Certificate Problem Reports as mandated in 4.10.2 of the BRs. Dimitris. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Policy 2.6 Proposal: Require CAs to support problem reports via email
I believe the intent of the certificate problem reporting in the BRs is to encourage CAs to accept and respond to issues. Although the intent is not specifically stated, my reasoning is based on the fact the BRs requiring CAs to maintain a 24x7 ability to respond, a 24 hour ability to process certificate problems, and a public reporting mechanism. To support this objective, I think we should make the process as easy as possible for reporters, including mandating email. Finding the email addresses is a pain with little reward. Having to go through captchas to even get the email sent is just another obstacle in getting the CA a timely certificate problem report. Therefore, I'd adopt Ryan Hurst's proposal and require that the email be in a standardized format (no more hunting for email aliases) without any blockers to prevent the certificate problem report. Filtering through the mess of emails you get on those aliases is the CAs responsibility. Jeremy -Original Message- From: dev-security-policy On Behalf Of Wayne Thayer via dev-security-policy Sent: Tuesday, April 17, 2018 10:50 AM To: mozilla-dev-security-policy Subject: Policy 2.6 Proposal: Require CAs to support problem reports via email Section 4.9.3 of the CA/Browser Forum's Baseline Requirements says: "The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means.” Mozilla has made a central list of these mechanisms in the CCADB [1] but, as it turns out, some of them (such as web forms with CAPTCHAs) are difficult to use. It is proposed that Mozilla policy go above and beyond the BR requirement to state that email must be one of the problem reporting methods supported. Another argument in favor or requiring CAs to accept problem reports via email is that it provides the reporter with evidence of the submission via their email client and server logs. Arguments against this requirement include the burden placed on CAs who must sort through the large quantities of SPAM received by any published email address, concerns with email reliability, and the reporter's inability to confirm that their email has been received by the CA. According to CCADB [1], all but a handful of CAs already support problem reporting via email. I would appreciate everyone's input on this topic. This is: https://github.com/mozilla/pkipolicy/issues/98 [1] https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport --- This is a proposed update to Mozilla's root store policy for version 2.6. Please keep discussion in this group rather than on GitHub. Silence is consent. Policy 2.5 (current version): https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md ___ 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
Policy 2.6 Proposal: Require CAs to support problem reports via email
Section 4.9.3 of the CA/Browser Forum's Baseline Requirements says: "The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means.” Mozilla has made a central list of these mechanisms in the CCADB [1] but, as it turns out, some of them (such as web forms with CAPTCHAs) are difficult to use. It is proposed that Mozilla policy go above and beyond the BR requirement to state that email must be one of the problem reporting methods supported. Another argument in favor or requiring CAs to accept problem reports via email is that it provides the reporter with evidence of the submission via their email client and server logs. Arguments against this requirement include the burden placed on CAs who must sort through the large quantities of SPAM received by any published email address, concerns with email reliability, and the reporter's inability to confirm that their email has been received by the CA. According to CCADB [1], all but a handful of CAs already support problem reporting via email. I would appreciate everyone's input on this topic. This is: https://github.com/mozilla/pkipolicy/issues/98 [1] https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport --- This is a proposed update to Mozilla's root store policy for version 2.6. Please keep discussion in this group rather than on GitHub. Silence is consent. Policy 2.5 (current version): https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
