Re: FW: Complying with Mozilla policy on email validation

2018-04-04 Thread Adrian R. via dev-security-policy
On Thursday, 5 April 2018 03:08:44 UTC+3, Wayne Thayer wrote: [...] > If a CA first confirms that it is a condition of a > particular federated authentication system that a user must have proven > control over the email account that constitutes their username to activate > their account, then requ

RE: Policy 2.6 Proposal: Require English Language Audit Reports

2018-04-04 Thread Tim Hollebeek via dev-security-policy
Call me crazy, but for this particular requirement, I think simple sentences might be better. "The audit information MUST be publicly available. An English version MUST be provided. The English version MUST be authoritative." -Tim > -Original Message- > From: dev-security-policy [mailt

Re: FW: Complying with Mozilla policy on email validation

2018-04-04 Thread Wayne Thayer via dev-security-policy
On Wed, Apr 4, 2018 at 3:44 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, April 4, 2018 at 3:39:46 PM UTC-7, Wayne Thayer wrote: > > On Wed, Apr 4, 2018 at 2:44 PM, Ryan Hurst via dev-security-policy < > > > My opinion on this method and on

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

2018-04-04 Thread Wayne Thayer via dev-security-policy
On Wed, Apr 4, 2018 at 3:15 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Some thoughts: > > 1 - Should additional text be included to mandate strong cipher suites ( > http://unmitigatedrisk.com/?p=543) be used; it is not uncommon for me to > find PKCS#12

Re: Policy 2.6 Proposal: Require English Language Audit Reports

2018-04-04 Thread Ryan Hurst via dev-security-policy
> An authoritative English language version of the publicly-available audit > information MUST be supplied by the Auditor. > > it would be helpful for auditors that issue report in languages other than > English to confirm that this won't create any issues. That would address my concern. ___

Re: Policy 2.6 Proposal: Require English Language Audit Reports

2018-04-04 Thread Wayne Thayer via dev-security-policy
On Wed, Apr 4, 2018 at 2:46 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, April 4, 2018 at 1:58:35 PM UTC-7, Wayne Thayer wrote: > > Mozilla needs to be able to read audit reports in the English language > > without relying on machine transl

Re: FW: Complying with Mozilla policy on email validation

2018-04-04 Thread Ryan Hurst via dev-security-policy
On Wednesday, April 4, 2018 at 3:39:46 PM UTC-7, Wayne Thayer wrote: > On Wed, Apr 4, 2018 at 2:44 PM, Ryan Hurst via dev-security-policy < > > My opinion on this method and on Adrian's comments is that the CA/Browser > Forum, with it's new-found ability to create an S/MIME Working Group, is a > be

Re: FW: Complying with Mozilla policy on email validation

2018-04-04 Thread Wayne Thayer via dev-security-policy
On Wed, Apr 4, 2018 at 2:44 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tuesday, April 3, 2018 at 1:17:50 PM UTC-7, Wayne Thayer wrote: > > > I agree that name constraints would be difficult to implement in this > > scenario, but I'm less convinced t

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

2018-04-04 Thread Ryan Hurst via dev-security-policy
Some thoughts: 1 - Should additional text be included to mandate strong cipher suites (http://unmitigatedrisk.com/?p=543) be used; it is not uncommon for me to find PKCS#12s with very weak cryptographic algorithms in use. Such guidance would be limited by Windows which does not support modern c

Re: Policy 2.6 Proposal: Require English Language Audit Reports

2018-04-04 Thread Ryan Hurst via dev-security-policy
On Wednesday, April 4, 2018 at 1:58:35 PM UTC-7, Wayne Thayer wrote: > Mozilla needs to be able to read audit reports in the English language > without relying on machine translations that may be inaccurate or > misleading. > > I suggest adding the following sentence to the end of policy section 3

Re: FW: Complying with Mozilla policy on email validation

2018-04-04 Thread Ryan Hurst via dev-security-policy
On Tuesday, April 3, 2018 at 1:17:50 PM UTC-7, Wayne Thayer wrote: > > I agree that name constraints would be difficult to implement in this > scenario, but I'm less convinced that section 2.2(2) doesn't permit this. > It says: > > > *For a certificate capable of being used for digitally signing

Policy 2.6 Proposal: For new inclusions, require all existing unexpired unrevoked certs in hierarchy to be BR compliant

2018-04-04 Thread Wayne Thayer via dev-security-policy
Last year we held a discussion on this topic [1] that concluded as follows: It is true that in the case of a legacy root, creating a new root with a > cross-sign is not technically all that complex (although it may take > some time organizationally) and then we could embed that new one. > > Given

Policy 2.6 Proposal: Add prohibition on CA key generation to policy

2018-04-04 Thread Wayne Thayer via dev-security-policy
This issue is titled “Make sure Forbidden practices are forbidden” - in other words, make sure they are banned in our policy. The only forbidden practice on our list [1] that’s not already covered by our policy is “Distributing Generated Private Keys in PKCS#12 Files”. It reads: CAs must never gen

Policy 2.6 Proposal: Audit requirements for new subCA certificates

2018-04-04 Thread Wayne Thayer via dev-security-policy
In a recent discussion [1] we decided to clarify the audit requirements for new subordinate CA certificates. I’ve drafted a change that requires the new certificate to appear in the next periodic audits and in the CP/CPS prior to issuance: https://github.com/mozilla/pkipolicy/commit/09867ef4a0db3

Policy 2.6 Proposal: Require English Language Audit Reports

2018-04-04 Thread Wayne Thayer via dev-security-policy
Mozilla needs to be able to read audit reports in the English language without relying on machine translations that may be inaccurate or misleading. I suggest adding the following sentence to the end of policy section 3.1.4 “Public Audit Information”: An English language version of the publicly-a

Re: Policy 2.6 Proposal: Require audits back to first issuance

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

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

2018-04-04 Thread Wayne Thayer via dev-security-policy
Thanks everyone for your input. This discussion has reached the conclusion that Mozilla should deny the inclusion request for the AC Camerfirma CHAMBERS OF COMMERCE ROOT - 2016 (CCR2016) and GLOBAL CHAMBERSIGN ROOT - 2016 As suggested, AC Camerfirma is welcome to submit a new inclusion request for

ACES Sunset

2018-04-04 Thread Peter Bachman via dev-security-policy
https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/gsa-aces-sunset-guide.pdf ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Audits for new subCAs

2018-04-04 Thread Ryan Sleevi via dev-security-policy
On Tue, Apr 3, 2018 at 11:42 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 03/04/2018 14:57, Ryan Sleevi wrote: > >> On Mon, Apr 2, 2018 at 9:03 PM, Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >> On 03/04/20

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

2018-04-04 Thread ramirommunoz--- via dev-security-policy
El miércoles, 4 de abril de 2018, 4:10:16 (UTC+2), Matt Palmer escribió: > On Tue, Apr 03, 2018 at 05:19:32AM -0700, ramirommunoz--- via > dev-security-policy wrote: > > Completely agree with you about that a new root by itself do not solve the > > problem. > > The phrase you're looking for is

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

2018-04-04 Thread ramirommunoz--- via dev-security-policy
El martes, 3 de abril de 2018, 23:48:32 (UTC+2), okaphone.e...@gmail.com escribió: > On Tuesday, 3 April 2018 14:19:43 UTC+2, ramiro...@gmail.com wrote: > > El martes, 3 de abril de 2018, 11:58:49 (UTC+2), okaphone.e...@gmail.com > > escribió: > > > On Monday, 2 April 2018 19:22:02 UTC+2, rami

Re: FW: Complying with Mozilla policy on email validation

2018-04-04 Thread Adrian R. via dev-security-policy
On Tuesday, 3 April 2018 20:19:40 UTC+3, Ryan Hurst wrote: > > Reading this thread and thinking the current text, based on the > interpretation discussed, does not accommodate a few cases that I think are > useful. > > For example, if we consider a CA supporting a large mail provider in > pro