Re: Policy 2.6 Proposal: Require CAs to support problem reports via email

2018-04-25 Thread Wayne Thayer via dev-security-policy
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

2018-04-20 Thread Wayne Thayer via dev-security-policy
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

2018-04-19 Thread Kristian Fiskerstrand via dev-security-policy
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

2018-04-18 Thread Dimitris Zacharopoulos via dev-security-policy



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

2018-04-18 Thread Ryan Sleevi via dev-security-policy
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

2018-04-18 Thread Wayne Thayer via dev-security-policy
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

2018-04-18 Thread Ryan Sleevi via dev-security-policy
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

2018-04-18 Thread Dimitris Zacharopoulos via dev-security-policy

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

2018-04-17 Thread Jeremy Rowley via dev-security-policy
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

2018-04-17 Thread Wayne Thayer via dev-security-policy
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