On 01/04/17 00:38, Ryan Sleevi wrote:
> On Fri, Mar 31, 2017 at 2:39 PM, Gervase Markham via dev-security-policy <
> Thanks for organizing this information, as much of it was related to and
> relevant to Google's recent announcement. I want to take this opportunity
> to share additional details reg
On 01/04/17 05:57, Peter Bowen wrote:
> The GeoRoot program was very similar to that offered by many CAs a few
> years ago. CyberTrust (then Verizon, now DigiCert) has the OmniRoot
> program, Entrust has a root signing program[1], and GlobalSign Trusted
> Root[2] are just a few examples.
While th
On 03/04/17 02:37, Peter Bowen wrote:
> I believe Issue L is incorrectly dated.
Thank you for this; I have updated Issue L to hopefully be more
accurate, but I intend to keep it as a separate issue.
Gerv
___
dev-security-policy mailing list
dev-securi
Hi Steve and Rick,
You have told me that you are considering your response(s) to the
Symantec issues list, which is fine. Based on the list and further
discussions which have been happening in m.d.s.policy, and on your
recent audit publication, I thought it would be helpful to give a few
specific
On 01/04/2017 16:08, Ryan Sleevi wrote:
(Wearing a personal hat)
This timeline hopefully highlights a particular serious issue: If NTT
Docomo is operated as part of Symantec's operations, then there are several
ways to interpret Symantec's audit statements:
1) KPMG failed to include NTT Docomo
On 01/04/2017 03:49, Ryan Sleevi wrote:
On Fri, Mar 31, 2017 at 12:24 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
As previously stated, I think this will be too short if the issuance
happens at a time when a non-CCADB root program (or the CCADB
infrast
On Mon, Apr 3, 2017 at 12:46 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> How about this simple explanation (purely a guess, not at all checked):
>
I think we should focus on objective facts and statements. While there are
a number of possible ways to
On Saturday, April 1, 2017 at 3:59:28 AM UTC-7, Gervase Markham wrote:
> On 31/03/17 22:20, Kathleen Wilson wrote:
> > Please let me know asap if you see any problems, typos, etc. in this
> > version.
>
> Now that policy 2.4.1 has been published, we should update Action 3 to
> say the following at
On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> taking a holiday and not being able to process a disclosure of a new
> SubCA.
>
Considering that the CCADB does not require any of these parties to process
a disclosure, can you
I updated https://wiki.mozilla.org/CA:BRs-Self-Assessment to add a section
called 'Annual BR Self Assessment', which states:
"CAs with included root certificates that have the Websites trust bit set must
do an annual self-assessment of their compliance with the BRs, and must update
their CP and
Here's a summary of the automated email that was sent yesterday.
Forwarded Message
Subject: Summary of April 2017 Audit Reminder Emails For Intermediate Certs
Date: Sun, 2 Apr 2017 14:00:47 + (GMT)
From: Mozilla CA Program Manager
Need Audit or CP/CPS for Intermediate C
On Monday, April 3, 2017 at 10:13:22 AM UTC-7, Kathleen Wilson wrote:
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
> still shows version 2.4.
It's been updated to version 2.4.1.
Thanks,
Kathleen
___
dev-securi
On 03/04/2017 19:24, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
taking a holiday and not being able to process a disclosure of a new
SubCA.
Considering that the CCADB does not require any of these par
On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> The assumptions are:
>
> 0. All relevant root programs set similar/identical policies or they
> get incorporatated into the CAB/F BRs on a future date.
>
This is not correct at
On Mon, Apr 3, 2017 at 12:36 PM, Jakob Bohm via dev-security-policy
wrote:
> On 03/04/2017 19:24, Ryan Sleevi wrote:
>>
>> On Mon, Apr 3, 2017 at 12:58 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>>
>>> taking a holiday and not being able to proce
Further to Ryan's reply, we can once again take lessons from the real world
Ordinarily notice in law can be given by sending a letter and waiting a few
days. There is no obligation to prove the letter was delivered, let alone read
and comprehended, only that it was sent and that it was correctly
On 03/04/2017 21:48, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
The assumptions are:
0. All relevant root programs set similar/identical policies or they
get incorporatated into the CAB/F BRs on a futu
All,
I'm getting ready to send the April 2017 CA Communication email.
I updated the wiki page to have the survey introduction text, and a (read-only)
link to the full survey:
https://wiki.mozilla.org/CA:Communications#April_2017
The survey in the Common CA Database is now open, with an expirati
On Mon, Apr 3, 2017 at 1:45 PM, Jakob Bohm via dev-security-policy
wrote:
> On 03/04/2017 21:48, Ryan Sleevi wrote:
>>
>> On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>>
>>> The assumptions are:
>>>
>>> 0. All relevant r
I must be missing something still? The implication here is that a purchaser who
is not yet part of the root program is permitted to take possession of the root
cert private key and possibly the physical space, key personnel, networking
infrastructure, revocation systems, and responsibility for s
On 04/04/2017 00:31, Peter Bowen wrote:
On Mon, Apr 3, 2017 at 1:45 PM, Jakob Bohm via dev-security-policy
wrote:
On 03/04/2017 21:48, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 3:36 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
The assumptions are:
On Mon, Apr 3, 2017 at 7:18 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I see it as part of the underlying reasoning. Mozilla et al wants
> disclosure in order to take action if the disclosed facts are deemed
> unacceptable (under policy or otherwise).
On 04/04/2017 05:03, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 7:18 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I see it as part of the underlying reasoning. Mozilla et al wants
disclosure in order to take action if the disclosed facts are deemed
unac
On Mon, Apr 3, 2017 at 11:18 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 04/04/2017 05:03, Ryan Sleevi wrote:
>
>> On Mon, Apr 3, 2017 at 7:18 PM, Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> I see it as
On 04/04/2017 05:30, Ryan Sleevi wrote:
On Mon, Apr 3, 2017 at 11:18 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
So why does Mozilla want disclosure and not just a blanket X on a form
stating that all SubCAs are adequately audited, follow BRs etc.?
25 matches
Mail list logo