Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

2017-06-02 Thread Peter Bowen via dev-security-policy
On Fri, Jun 2, 2017 at 8:12 AM, Ryan Sleevi wrote: > On Fri, Jun 2, 2017 at 10:09 AM Jakob Bohm wrote: > >> On 02/06/2017 15:54, Ryan Sleevi wrote: >> > On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen wrote: >> > >> >> Yes, my concern is that this could make SIGNED{ToBeSigned} considered >> >>

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

2017-06-02 Thread David E. Ross via dev-security-policy
On 6/2/2017 3:28 AM, Gervase Markham wrote: > The scope of the BRs is ambiguous, and almost certainly smaller than the > scope of the Mozilla policy. It might be useful to explicitly draw > attention to that fact, for the avoidance of doubt. > > Proposal: add a bullet to section 2.3, where we

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

2017-06-02 Thread Kurt Roeckx via dev-security-policy
On Fri, Jun 02, 2017 at 04:50:44PM +0100, Gervase Markham wrote: > On 02/06/17 12:24, Kurt Roeckx wrote: > > Should that be "all certificates" instead of "all SSL certificates"? > > No; the Baseline Requirements apply only to SSL certificates. Then I don't understand what you're trying to do. If

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

2017-06-02 Thread Peter Bowen via dev-security-policy
On Fri, Jun 2, 2017 at 8:50 AM, Gervase Markham via dev-security-policy wrote: > On 02/06/17 12:24, Kurt Roeckx wrote: >> Should that be "all certificates" instead of "all SSL certificates"? > > No; the Baseline Requirements apply only to SSL certificates.

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

2017-06-02 Thread Gervase Markham via dev-security-policy
On 02/06/17 12:24, Kurt Roeckx wrote: > Should that be "all certificates" instead of "all SSL certificates"? No; the Baseline Requirements apply only to SSL certificates. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

RE: [EXT] Symantec response to Google proposal

2017-06-02 Thread Steve Medin via dev-security-policy
> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of > Gervase Markham via dev-security-policy > Sent: Friday, June 02, 2017 10:54 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject:

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

2017-06-02 Thread Ryan Sleevi via dev-security-policy
On Fri, Jun 2, 2017 at 10:09 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 02/06/2017 15:54, Ryan Sleevi wrote: > > On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen wrote: > > > >> On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

2017-06-02 Thread Jakob Bohm via dev-security-policy
On 02/06/2017 15:54, Ryan Sleevi wrote: On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen wrote: On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi wrote: Yes, my concern is that this could make SIGNED{ToBeSigned} considered misissuance if ToBeSigned is not a

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

2017-06-02 Thread Ryan Sleevi via dev-security-policy
On Fri, Jun 2, 2017 at 9:33 AM, Peter Bowen wrote: > On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi wrote: > Yes, my concern is that this could make SIGNED{ToBeSigned} considered > misissuance if ToBeSigned is not a TBSCertificate. For example, if I > could

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

2017-06-02 Thread Peter Bowen via dev-security-policy
On Fri, Jun 2, 2017 at 4:27 AM, Ryan Sleevi wrote: > > > On Thu, Jun 1, 2017 at 10:19 PM, Peter Bowen via dev-security-policy > wrote: >> >> On Thu, Jun 1, 2017 at 5:49 AM, Ryan Sleevi via dev-security-policy >> > So I would definitely

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

2017-06-02 Thread Ryan Sleevi via dev-security-policy
I liked your previous version better, if it had to be updated. It would sound like you're suggesting "Enterprise RA" accounts should not use multi-factor authentication, but given that they're part of the scope of audited activities (that the CA must directly oversee), the use of multi-factor

Re: Policy 2.5 Proposal: Add definition of "mis-issuance"

2017-06-02 Thread Ryan Sleevi via dev-security-policy
On Thu, Jun 1, 2017 at 10:19 PM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, Jun 1, 2017 at 5:49 AM, Ryan Sleevi via dev-security-policy > > So I would definitely encourage that improper application of the > protocols > > and data formats

Re: Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

2017-06-02 Thread Kurt Roeckx via dev-security-policy
On 2017-06-02 12:28, Gervase Markham wrote: "Insofar as the Baseline Requirements attempt to define their own scope, the scope of this policy (section 1.1) overrides that. Mozilla expects CA operations relating to issuance of all SSL certificates in the scope of this policy to conform to the

Policy 2.5 Proposal: Make it clear that Mozilla policy has wider scope than the BRs

2017-06-02 Thread Gervase Markham via dev-security-policy
The scope of the BRs is ambiguous, and almost certainly smaller than the scope of the Mozilla policy. It might be useful to explicitly draw attention to that fact, for the avoidance of doubt. Proposal: add a bullet to section 2.3, where we define BR exceptions: "Insofar as the Baseline

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

2017-06-02 Thread Gervase Markham via dev-security-policy
On 01/06/17 13:59, Gervase Markham wrote: > Perhaps this leads to the solution? We say: > > "enforce multi-factor authentication for all accounts capable of causing > certificate issuance or performing RA or DTP functions as defined by the > Baseline Requirements" or "enforce multi-factor