On 24/03/2017 21:03, Jakob Bohm wrote:
On 24/03/2017 19:08, Ryan Sleevi wrote:
On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Examples discussed in the past year in this group include the Taiwan
GRCA roots and several of the
On 24/03/2017 19:08, Ryan Sleevi wrote:
On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Examples discussed in the past year in this group include the Taiwan
GRCA roots and several of the SubCAs hosted by Verizon prior to the
Di
On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Examples discussed in the past year in this group include the Taiwan
> GRCA roots and several of the SubCAs hosted by Verizon prior to the
> DigiCert transition.
Apologies for no
On 24/03/2017 17:12, Peter Bowen wrote:
On Fri, Mar 24, 2017 at 9:06 AM, Ryan Sleevi via dev-security-policy
wrote:
(Wearing an individual hat)
On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
One common scenario that a new
On Fri, Mar 24, 2017 at 9:06 AM, Ryan Sleevi via dev-security-policy
wrote:
> (Wearing an individual hat)
>
> On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>>
>> One common scenario that a new wording should allow is a "fully
(Wearing an individual hat)
On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> One common scenario that a new wording should allow is a "fully
> outsourced CA", where all the technical activities, including CA
> private key stor
On 24/03/2017 10:56, Gervase Markham wrote:
On 07/03/17 11:37, Gervase Markham wrote:
Here are some proposals for policy change. Please do comment on these or
suggest others.
I can report that at the CAB Forum face-to-face in Raleigh, NC, USA this
week, there was broad consensus to draw up a b
On 07/03/17 11:37, Gervase Markham wrote:
> Here are some proposals for policy change. Please do comment on these or
> suggest others.
I can report that at the CAB Forum face-to-face in Raleigh, NC, USA this
week, there was broad consensus to draw up a ballot which prevents CAs
from (to summarise
On Fri, Mar 17, 2017 at 5:33 AM Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 16/03/17 13:15, Ryan Sleevi wrote:
> > Or, put differently, it sounds as if you suggest the only obligation a CA
> > has to ensure their DTP auditors are qualified for the t
On 16/03/17 13:15, Ryan Sleevi wrote:
> Or, put differently, it sounds as if you suggest the only obligation a CA
> has to ensure their DTP auditors are qualified for the task at hand is if,
> and only if, Mozilla requests those audits. In the absence of that request,
> the CA is allowed to make th
Sent: Thursday, March 16, 2017 7:16 AM
To: Gervase Markham
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec: Next Steps
On Thu, Mar 16, 2017 at 6:01 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 09/03/17 13:32, Ry
On Thu, Mar 16, 2017 at 6:01 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 09/03/17 13:32, Ryan Sleevi wrote:
> > (Wearing Google hat only for this statement)
> > Have you considered having this discussion in the CA/Browser Forum?
> Google
> > had
On 08/03/17 15:06, Peter Bowen wrote:
> By eliminating the DTP option, you will massively raise costs for CAs
> that rely upon local translators and information gatherers. I think a
> much better proposal would be to require the CA perform the RA
> activity contemplated by BR 3.2.2.4 and 3.2.2.5 a
On 09/03/17 13:32, Ryan Sleevi wrote:
> (Wearing Google hat only for this statement)
> Have you considered having this discussion in the CA/Browser Forum? Google
> had planned to discuss this very topic at our upcoming F2F about how to
> address this, and would be very interested in collaborating w
ozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec: Next Steps
On Thu, Mar 9, 2017 at 6:48 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> That seems to make sense to me. Given that the BRs have the concept of
> a DTP, how can we b
On Thu, Mar 9, 2017 at 1:34 PM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> In the case of CrossCert, where we have evidence of failure to properly
> document their work, we are NOT relying on their previous work and have
> begun fully revalidating all act
On Behalf Of Ryan
> Sleevi via dev-security-policy
> Sent: Wednesday, March 08, 2017 11:37 AM
> To: Gervase Markham
> Cc: Ryan Sleevi ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: Symantec: Next Steps
>
>
> I highlight this, because at least
On Thu, Mar 9, 2017 at 6:48 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> That seems to make sense to me. Given that the BRs have the concept of a
> DTP, how can we best align the two in practice? Does requiring every RA
> to have its own subCA do th
On 08/03/17 16:36, Ryan Sleevi wrote:
> That is precisely the goal. We could define a set of process and procedures
> specific to DTPs, which is effectively duplicitive with the handling of
> subordinate CAs, or we could strive to align the two both conceptually and
> materially, since, as you note
On Wed, Mar 8, 2017 at 10:30 AM, Gervase Markham wrote:
> On 07/03/17 20:37, Ryan Sleevi wrote:
> > To make it simpler, wouldn't be a Policy Proposal be to prohibit
> Delegated
> > Third Parties from participating in the issuance process? This would be
> > effectively the same, in as much as the
On 07/03/17 20:37, Ryan Sleevi wrote:
> To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated
> Third Parties from participating in the issuance process? This would be
> effectively the same, in as much as the only capability to allow a
> third-party to participate in issuance
On Wed, Mar 8, 2017 at 6:50 AM, Ryan Sleevi wrote:
>
> On Wed, Mar 8, 2017 at 9:23 AM, Peter Bowen wrote:
>
>> > Does this make it clearer the point I was trying to make, which is that
>> > they're functionally equivalent - due to the fact that both DTPs and
>> > sub-CAs
>> > have the issue of mul
On 07/03/17 23:26, Nick Lamb wrote:
> I am concerned that the specificity of Policy Proposals 1 & 2 risks
> fighting the last war by focusing so much on the RA role.
I guess that's possible; however, it's clear to me that we need policy
improvements in this area. If you know where the next war wil
On Wed, Mar 8, 2017 at 9:23 AM, Peter Bowen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > This is why I'm suggesting, from an audit scope, they're functionally
> > equivalent approach, except one avoids the whole complexity of
> identifying
> > where or not a DTP is s
On Wed, Mar 8, 2017 at 8:46 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Yes, I agree they should be functionally equivalent, in the sense that
> all aspects of the operation and issuance are validated, and that one
> entity is ultimately responsible for
On Wed, Mar 8, 2017 at 5:08 AM, Ryan Sleevi wrote:
>
>
> On Wed, Mar 8, 2017 at 12:57 AM, Peter Bowen via dev-security-policy
> wrote:
>>
>> If the DTP is only performing the functions that Jakob lists, then
>> they only need an auditor's opinion covering those functions. In fact
>> there is no w
On 08/03/2017 14:18, Ryan Sleevi wrote:
On Wed, Mar 8, 2017 at 1:36 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I am simply going by the wording in Gervs posting not stating what you
stated. I presume that if Gerv wanted to complete eliminate the DTP
On Wed, Mar 8, 2017 at 1:36 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I am simply going by the wording in Gervs posting not stating what you
> stated. I presume that if Gerv wanted to complete eliminate the DTP
> concept for Mozilla trusted CAs, then
On Wed, Mar 8, 2017 at 1:29 AM, Santhan Raj via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Ryan,
>
> Section 8.4 (cited below), as worded today, does not mandate a DTP to go
> through an audit. Rather, it requires the CA to perform additional
> out-of-band checks or pe
On Wed, Mar 8, 2017 at 12:57 AM, Peter Bowen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> If the DTP is only performing the functions that Jakob lists, then
> they only need an auditor's opinion covering those functions. In fact
> there is no way for an auditor to audi
On 08/03/2017 06:27, Ryan Sleevi wrote:
On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I saw nothing in Gervs posting suggesting that banning all kinds of
RA/DTP relationships was the intended effect.
But would you also ack
> > For the kind of RA that only does specific relevant parts of validation
> > (a "traditional" RA), the suggested policy as written would "simply"
> > require the CA to set up and maintain one (set of) subCAs for each of
> > their RAs, while your rephrasing as a ban on RA/DTP relationships would
On Tue, Mar 7, 2017 at 9:27 PM, Ryan Sleevi via dev-security-policy
wrote:
> On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
]>
>> For example, an RA whose sole involvement is to receive a daily list of
>> company name/idno/addr
On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I saw nothing in Gervs posting suggesting that banning all kinds of
> RA/DTP relationships was the intended effect.
But would you also acknowledge that your originally stated "Th
On 08/03/2017 04:21, Ryan Sleevi wrote:
On Tue, Mar 7, 2017 at 8:08 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I contradicted you in saying that RAs (or DTP as you now want to call
them) were not supposed to be banned by the policy change.
DTPs are
On Tue, Mar 7, 2017 at 8:08 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I contradicted you in saying that RAs (or DTP as you now want to call
> them) were not supposed to be banned by the policy change.
>
DTPs are the terms from the Baseline Requireme
On 08/03/2017 01:40, Ryan Sleevi wrote:
On Tue, Mar 7, 2017 at 6:26 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 07/03/2017 21:37, Ryan Sleevi wrote:
To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated
Third Parties from part
On Tue, Mar 7, 2017 at 6:26 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 07/03/2017 21:37, Ryan Sleevi wrote:
>>
>> To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated
>> Third Parties from participating in the issuance process?
On 07/03/2017 21:37, Ryan Sleevi wrote:
On Tue, Mar 7, 2017 at 6:37 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Policy Proposal 1: require all CAs to arrange it so that certs validated
by an RA are issued from one or more intermediates dedicated s
On Tuesday, 7 March 2017 11:38:09 UTC, Gervase Markham wrote:
> Comments on this topic, with careful justification, are invited.
I am concerned that the specificity of Policy Proposals 1 & 2 risks fighting
the last war by focusing so much on the RA role.
To your final question, yes, but I would
On Tue, Mar 7, 2017 at 6:37 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Policy Proposal 1: require all CAs to arrange it so that certs validated
> by an RA are issued from one or more intermediates dedicated solely to
> that RA, with such intermedi
41 matches
Mail list logo
