The proposed language includes the requirement for compliance with both the
BRs and Mozilla policy, so it's a better fit for the section of our policy
titled "Inclusions" than the section titled "Baseline Requirements
Conformance". To close out this discussion, I added the proposed language
to sect
Hi again,
>Thank you for responding Matthias.
>
>On Wed, Apr 11, 2018 at 10:52 AM, m.wiedenhorst---
>via dev-security-policy wrote:
>
>>
>> Hi Wayne
>>
>>> Can anyone say if an equivalent public-facing
>>> report exists for ETSI audits? If so, I think we should require CAs to
>>> provide these r
Thank you for responding Matthias.
On Wed, Apr 11, 2018 at 10:52 AM, m.wiedenhorst--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Hi Wayne
>
> > Can anyone say if an equivalent public-facing
> > report exists for ETSI audits? If so, I think we should require CAs to
Hi Wayne
> Can anyone say if an equivalent public-facing
> report exists for ETSI audits? If so, I think we should require CAs to
> provide these reports with their root inclusion requests.
ETSI does require reports on key ceremonies (ETSI EN 319 411-1, 6.5.1 g).
But ETSI does NOT require thes
On Mon, Apr 2, 2018 at 9:28 PM, tom.prince--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Monday, April 2, 2018 at 7:12:19 PM UTC-6, Wayne Thayer wrote:
> > In section 2.3 (Baseline Requirements Conformance), add a new bullet that
> > states "Before being included,
On Monday, April 2, 2018 at 7:12:19 PM UTC-6, Wayne Thayer wrote:
> In section 2.3 (Baseline Requirements Conformance), add a new bullet that
> states "Before being included, CAs MUST provide evidence that their root
> certificates have continually, from the time of creation, complied with the
> th
Thanks Tim and Ryan for the information on WebTrust Root Key Generation
Ceremony audit reports. Can anyone say if an equivalent public-facing
report exists for ETSI audits? If so, I think we should require CAs to
provide these reports with their root inclusion requests.
Regarding the issue of requ
On Thursday, March 29, 2018 at 10:59:10 AM UTC-5, Ryan Sleevi wrote:
> On Mon, Mar 26, 2018 at 3:06 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Mozilla began requiring BR audits for roots in our program in 2013 [1], but
> > we have a vague polic
On Thu, Mar 29, 2018 at 4:57 PM, Wayne Thayer wrote:
> On Thu, Mar 29, 2018 at 8:57 AM, Ryan Sleevi wrote:
>
>>
>> I'm not fully sure I understand the proposal here.
>>
>> I would think that, for all roots created since 2012, the expectation
>>
> is that there is an unbroken series of audits, go
On Thu, Mar 29, 2018 at 8:57 AM, Ryan Sleevi wrote:
>
> I'm not fully sure I understand the proposal here.
>
> I would think that, for all roots created since 2012, the expectation
>
is that there is an unbroken series of audits, going from a Point in Time
> audit (of the policies and infrastruct
On Mon, Mar 26, 2018 at 3:06 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Mozilla began requiring BR audits for roots in our program in 2013 [1], but
> we have a vague policy statement in section 3.1 regarding audit
> requirements prior to inclusion:
>
Mozilla began requiring BR audits for roots in our program in 2013 [1], but
we have a vague policy statement in section 3.1 regarding audit
requirements prior to inclusion:
Before being included and periodically thereafter, CAs MUST obtain certain
> audits…
>
BR section 8.1 contains the following
12 matches
Mail list logo