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
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
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
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
> 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.
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
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
>
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
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
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
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
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
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
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:
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
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
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
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
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
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
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,
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
>
22 matches
Mail list logo
