Mozilla CT Policy: discussion location

drafted a version 0.0.1 of the Mozilla CT policy, and will soon post it to ct-pol...@chromium.org. If you want to be part of that conversation, you will need to subscribe, which you can do here: https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy I am unfortunately not aware of an NNTP

Re: Mozilla CT Policy

On Tue, Nov 8, 2016 at 12:07 PM, Jakob Bohm wrote: > I was responding to your simplistic argument that the existence of > ownership change detection failures made diversity requirements > worthless. I was not calculating their actual worth compared to other > measures.

Re: Mozilla CT Policy

On 08/11/2016 20:51, Ryan Sleevi wrote: On Tue, Nov 8, 2016 at 11:24 AM, Jakob Bohm wrote: Diversity requirements are about reducing the likelihood of simultaneous coercion, as it can never be ruled out that some powerful organization already engaged in such things could

Re: Mozilla CT Policy

On Tue, Nov 8, 2016 at 11:24 AM, Jakob Bohm wrote: > Diversity requirements are about reducing the likelihood of > simultaneous coercion, as it can never be ruled out that some powerful > organization already engaged in such things could use some of its > backhanded tactics

Re: Mozilla CT Policy

On 08/11/2016 17:50, Ryan Sleevi wrote: On Tue, Nov 8, 2016 at 2:05 AM, Gervase Markham wrote: ... ... Presumably this is one reason some people are suggesting Mozilla's policy have a jurisdictional diversity requirement - to make such coercion harder. Possibly, but I

Re: Mozilla CT Policy

On Tue, Nov 8, 2016 at 12:53 AM, Kurt Roeckx wrote: > On 2016-11-07 18:25, Ryan Sleevi wrote: >> >> This is why it's vitally important that clients fetch inclusion proofs in >> some manner > > > Have you considered a TLS extension, have the server fetch them and send to > the

Re: Mozilla CT Policy

On Tue, Nov 8, 2016 at 2:05 AM, Gervase Markham wrote: > On 07/11/16 17:25, Ryan Sleevi wrote: >> Yes. An 'evil log' can provide a divided split-view, targeting only >> an affected number of users. Unless that SCT was observed, and >> reported (via Gossip or some other means of

Re: Mozilla CT Policy

On 07/11/16 17:25, Ryan Sleevi wrote: > Yes. An 'evil log' can provide a divided split-view, targeting only > an affected number of users. Unless that SCT was observed, and > reported (via Gossip or some other means of exfiltration), that split > view would not be detected. So it is therefore

Re: Mozilla CT Policy

On 2016-11-07 18:25, Ryan Sleevi wrote: This is why it's vitally important that clients fetch inclusion proofs in some manner Have you considered a TLS extension, have the server fetch them and send to the client? Kurt ___ dev-security-policy

Re: Mozilla CT Policy

On Monday, November 7, 2016 at 9:02:37 AM UTC-8, Gervase Markham wrote: > As in, their dishonesty would be carefully targetted and so not exposed > by this sort of coarse checking? (Continuing with Google/Chrome hat on, since I didn't make the previous reply explicit) Yes. An 'evil log' can

Re: Mozilla CT Policy

On 07/11/16 16:13, Ryan Sleevi wrote: > Yes, particularly for logs that may be compelled to be dishonest for > geopolitical reasons. As in, their dishonesty would be carefully targetted and so not exposed by this sort of coarse checking? Gerv ___

Re: Mozilla CT Policy

On Monday, November 7, 2016 at 1:59:31 AM UTC-8, Gervase Markham wrote: > It is correct that there is not yet a plan for when Firefox might > implement inclusion proof fetching. > > One thing I have been pondering is checking the honesty of logs via > geographically distributed checks done by

Re: Mozilla CT Policy

On 05/11/16 19:33, Ryan Sleevi wrote: > My understanding was that Mozilla's implementation status was similar > to Chrome's a year ago - that is, that it doesn't implement inclusion > proof fetching (in the background) and that work hadn't been > scheduled/slated yet. In that case, it's a question

Re: Mozilla CT Policy

On Friday, November 4, 2016 at 5:32:23 AM UTC-7, Hanno Böck wrote: > Hi, > > Great to see Mozilla committing to CT. > > On Fri, 4 Nov 2016 12:19:32 + > Gervase Markham wrote: > > > So, please add comments with additional _questions_ you think the > > policy will need to

Re: Mozilla CT Policy

On Saturday, November 5, 2016 at 10:59:04 AM UTC-7, Tom Ritter wrote: > > * Are there any CT-related services Mozilla should consider running or > > supporting, for the good of the ecosystem? > > Part answer, part question, but I don't want to forget it: Besides an > Auditor, perhaps Mozilla

Re: Mozilla CT Policy

On 4 November 2016 at 07:19, Gervase Markham wrote: > * Are there any CT-related services Mozilla should consider running or > supporting, for the good of the ecosystem? Part answer, part question, but I don't want to forget it: Besides an Auditor, perhaps Mozilla should run a

Re: Mozilla CT Policy

Hey list, Here are some suggestions: Should we define log algorithm/key requirements (hashing algorithms (relevant with RFC6962-bis), asymmetric key type and length)? Should we define a maximum threshold on log response delay to queries? (e.g. is it acceptable for a log to answer to queries

RE: Mozilla CT Policy

[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Gervase Markham Sent: Friday, November 4, 2016 6:20 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Mozilla CT Policy CT is coming to Firefox. As part of that, Mozilla needs to have a set of CT

Re: Mozilla CT Policy

在 2016年11月4日星期五 UTC+8下午8:20:11，Gervase Markham写道： > CT is coming to Firefox. As part of that, Mozilla needs to have a set of > CT policies surrounding how that will work. Like our root inclusion > program, we intend to run our CT log inclusion program in an open and > transparent fashion, such

Re: Mozilla CT Policy

On 04/11/2016 15:42, Hanno Böck wrote: On Fri, 4 Nov 2016 14:09:55 +0100 Jakob Bohm wrote: * How do we allow organization internal non-public CAs to not reveal their secret membership/server lists to public CT systems or otherwise run the (administratively and

Re: Mozilla CT Policy

Well, these are logs. So: - Is it necessary to require that log items can't be modified after they have been created? (Or is that implied by the cryptography being used.) How about deleted? - Is is perhaps a good idea to require a certain minimum accuracy (or other characteristics, timestamps

Re: Mozilla CT Policy

On Fri, Nov 04, 2016 at 12:19:32PM +, Gervase Markham wrote: > > * Do we want to require a certain number of SCTs for certificates of > particular validity periods? What happens to the SCT requirements if a log is distrusted? Is the date of the distrust taking into account? Is that the same

Re: Mozilla CT Policy

On 4 November 2016 at 07:19, Gervase Markham wrote: > * How do we decide when to un-trust a log? What reasons are valid > reasons for doing so? Do we want different types of distrust for a log? That is, a "We don't trust you at all anymore" distrust vs a "We don't trust

Re: Mozilla CT Policy

On Fri, Nov 4, 2016 at 3:42 PM, Hanno Böck wrote: > > Isn't that already solved? > > Browsers already treat manually installed roots differently, e.g. > bypassing key pinning. Chrome's CT requirements don't apply to locally > installed roots. > > How about public technically

Re: Mozilla CT Policy

On Fri, 4 Nov 2016 14:09:55 +0100 Jakob Bohm wrote: > * How do we allow organization internal non-public CAs to not reveal > their secret membership/server lists to public CT systems or > otherwise run the (administratively and technically) expensive > processes required

Re: Mozilla CT Policy

Hi, Great to see Mozilla committing to CT. On Fri, 4 Nov 2016 12:19:32 + Gervase Markham wrote: > So, please add comments with additional _questions_ you think the > policy will need to address. What the answers should be is (for now) > off-topic. Some meta-thought: In

Mozilla CT Policy

CT is coming to Firefox. As part of that, Mozilla needs to have a set of CT policies surrounding how that will work. Like our root inclusion program, we intend to run our CT log inclusion program in an open and transparent fashion, such that the Internet community can see how it works and how