Re: Grace Period for Sub-CA Disclosure

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 requi

Re: Grace Period for Sub-CA Disclosure

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

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

On 31/03/2017 19:31, tarah.syman...@gmail.com wrote: On Friday, March 31, 2017 at 9:51:03 AM UTC-7, Jakob Bohm wrote: Dear Tarah, Below some friendly speculation as to what the parts that some bloggers claimed was included (if those claims were somehow true) might have been (i.e. where *you*

Re: Criticism of Google Re: Google Trust Services roots

On 30/03/2017 08:08, Gervase Markham wrote: On 29/03/17 20:42, Jakob Bohm wrote: That goal would be equally (in fact better) served by new market entrants getting cross-signed by incumbents, like Let's encrypt did. Google will be issuing from Google-branded intermediates under the

Re: Criticism of Google Re: Google Trust Services roots

KI, manual checking remains relevant. On Wed, Mar 29, 2017 at 2:42 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 29/03/2017 16:47, Gervase Markham wrote: On 29/03/17 15:35, Peter Kurrasch wrote: In other words, what used to be a trust anchor

Re: Criticism of Google Re: Google Trust Services roots

On 29/03/2017 16:47, Gervase Markham wrote: On 29/03/17 15:35, Peter Kurrasch wrote: In other words, what used to be a trust anchor is now no better at establishing trust than the end-entity cert one is trying to validate or investigate (for example, in a forensic context) in the first place. I

Re: Next CA Communication

On 28/03/2017 16:13, Ryan Sleevi wrote: On Tue, Mar 28, 2017 at 10:00 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: In principle any source of information could change just one minute later. A domain could be sold, a company could declare bank

Re: Next CA Communication

On 27/03/2017 11:10, Gervase Markham wrote: On 17/03/17 15:30, Gervase Markham wrote: The URL for the draft of the next CA Communication is here: https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2 Note that this is a

Re: Grace Period for Sub-CA Disclosure

On 28/03/2017 12:21, Rob Stradling wrote: On 28/03/17 11:02, Gervase Markham via dev-security-policy wrote: On 27/03/17 23:12, Andrew Ayer wrote: My interpretation of the policy is that a CA could delay disclosure for quite some time if the sub-CA is not used to issue certificates right away.

Re: Grace Period for Sub-CA Disclosure

mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Jakob Bohm via dev-security-policy Sent: Monday, March 27, 2017 3:58 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Grace Period for Sub-CA Disclosure On 27/03/2017 23:41, Rob Stradling wrote: On 27/0

Re: Grace Period for Sub-CA Disclosure

On 27/03/2017 23:41, Rob Stradling wrote: On 27/03/17 22:37, Jakob Bohm via dev-security-policy wrote: It should also be made a requirement that the issued SubCA certificate is provided to the CCADB and other root programs before providing it to the SubCA owner/operator, That'd be a bit

Re: Symantec: Next Steps

On 24/03/2017 21:03, Jakob Bohm wrote: On 24/03/2017 19:08, Ryan Sleevi wrote: On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Examples discussed in the past year in this group include the Taiwan GRCA roots and s

Re: Symantec: Next Steps

On 24/03/2017 19:08, Ryan Sleevi wrote: On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Examples discussed in the past year in this group include the Taiwan GRCA roots and several of the SubCAs hosted by Verizon

Re: Symantec: Next Steps

On 24/03/2017 17:12, Peter Bowen wrote: On Fri, Mar 24, 2017 at 9:06 AM, Ryan Sleevi via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: (Wearing an individual hat) On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mo

Re: Symantec: Next Steps

On 24/03/2017 10:56, Gervase Markham wrote: On 07/03/17 11:37, Gervase Markham wrote: Here are some proposals for policy change. Please do comment on these or suggest others. I can report that at the CAB Forum face-to-face in Raleigh, NC, USA this week, there was broad consensus to draw up a

Re: Safely testing TLS in dev & test environments

On 24/03/2017 05:54, Walter Goulet wrote: On Thursday, March 23, 2017 at 8:13:38 PM UTC-5, Jakob Bohm wrote: On 23/03/2017 22:59, Walter Goulet wrote: Hi all, This is not directly related to Mozilla policy, CA issues or really any of the normal discussions that I typically see in the group.

Re: Safely testing TLS in dev & test environments

On 23/03/2017 22:59, Walter Goulet wrote: Hi all, This is not directly related to Mozilla policy, CA issues or really any of the normal discussions that I typically see in the group. However, I think that my question may be relevant in helping to understand what a 'policy' for an internal,

Re: Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates

On 23/03/2017 20:27, Ryan Sleevi wrote: On Thu, Mar 23, 2017 at 1:38 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 23/03/2017 17:09, Ryan Sleevi wrote: (Posting in a Google Capacity) I just wanted to notify the members of this Forum that w

Re: Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates

On 23/03/2017 17:09, Ryan Sleevi wrote: (Posting in a Google Capacity) I just wanted to notify the members of this Forum that we have started an Intent to Deprecate and Remove, consistent with our Blink process, related to certain certificates issued by Symantec Corporation. This is a

Re: Next CA Communication

On 21/03/2017 10:09, Kurt Roeckx wrote: On 2017-03-17 16:30, Gervase Markham wrote: The URL for the draft of the next CA Communication is here: https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2 Action 6 says: However,

Re: Google Trust Services roots

On 10/03/2017 07:29, Ryan Hurst wrote: On Thursday, March 9, 2017 at 9:00:21 PM UTC-8, Peter Kurrasch wrote: By definition, a CPS is the authoritative document on what root certificates a CA operates and how they go about that operation. If the GlobalSign CPS has been updated to reflect the

Re: Google Trust Services roots

On 08/03/2017 18:12, Ryan Hurst wrote: jacob: Could a reasonably condition be that decision authority, actual and physical control for a root are not moved until proper root program coordination has been done (an action which may occur after/before the commercial conclusion of a transaction).

Re: Google Trust Services roots

On 08/03/2017 16:54, Gervase Markham wrote: On 08/03/17 03:54, Peter Kurrasch wrote: - Google has acquired 2 root certificates from GMO GlobalSign but not the ‎company itself. Yes. GMO GlobalSign will continue to own other roots and will use only those other roots for the various products

Re: Symantec: Next Steps

On 08/03/2017 14:18, Ryan Sleevi wrote: On Wed, Mar 8, 2017 at 1:36 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I am simply going by the wording in Gervs posting not stating what you stated. I presume that if Gerv wanted to complete eliminate t

Re: Symantec: Next Steps

On 08/03/2017 06:27, Ryan Sleevi wrote: On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I saw nothing in Gervs posting suggesting that banning all kinds of RA/DTP relationships was the intended effect. But would yo

Re: Symantec: Next Steps

On 08/03/2017 04:21, Ryan Sleevi wrote: On Tue, Mar 7, 2017 at 8:08 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I contradicted you in saying that RAs (or DTP as you now want to call them) were not supposed to be banned by the policy change.

Re: Symantec: Next Steps

On 08/03/2017 01:40, Ryan Sleevi wrote: On Tue, Mar 7, 2017 at 6:26 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 07/03/2017 21:37, Ryan Sleevi wrote: To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated Third Partie

Re: Symantec: Next Steps

On 07/03/2017 21:37, Ryan Sleevi wrote: On Tue, Mar 7, 2017 at 6:37 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Policy Proposal 1: require all CAs to arrange it so that certs validated by an RA are issued from one or more intermediates dedicated

Re: Google Trust Services roots

On 07/03/2017 18:29, Ryan Hurst wrote: pzb: I appreciate you finally sending responses. I hope you appreciate that they are clearly not adequate, in my opinion. Please see the comments inline. Again, sorry for the delay in responding, I will be more prompt moving forward. pzb: This

Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)

On 02/03/2017 00:59, Ryan Sleevi wrote: On Wed, Mar 1, 2017 at 12:12 PM, douglas.beattie--- via dev-security-policy wrote: On Wednesday, March 1, 2017 at 8:26:34 AM UTC-5, Peter Kurrasch wrote: Would it be possible to get a more precise answer other

Re: Intermediates Supporting Many EE Certs

On 01/03/2017 12:43, Gervase Markham wrote: On 13/02/17 12:23, Gervase Markham wrote: The GoDaddy situation raises an additional issue. What can be done about the potential future issue (which might happen with any large CA) of the need to untrust a popular intermediate? Suggestions

Re: Intermediates Supporting Many EE Certs

On 14/02/2017 22:03, Nick Lamb wrote: On Tuesday, 14 February 2017 17:55:18 UTC, Jakob Bohm wrote: Unfortunately, for these not-quite-web-server things (printers, routers etc.), automating use of the current ACME Let's encrypt protocol with or without hardcoding the Let's Encrypt URL is a

Re: Intermediates Supporting Many EE Certs

On 14/02/2017 18:14, Nick Lamb wrote: On Tuesday, 14 February 2017 13:47:51 UTC, Steve Medin wrote: - PKCS#7 chains are indeed not a requirement, but see point 1. It’s probably no coincidence that IIS supports it given awareness of the demands placed on enterprise IT admins. I

Re: Google Trust Services roots

On 10/02/2017 16:34, Ryan Sleevi wrote: On Thu, Feb 9, 2017 at 11:40 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: For clarity, I was pointing out that GTS seems to have chosen a method likely to fail if an when actually needed, due to the t

Re: Google Trust Services roots

On 10/02/2017 05:42, Ryan Sleevi wrote: On Thu, Feb 9, 2017 at 3:39 PM, Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org>> wrote: Additional issue #2: The information at https://pki.goog/ about how t

Re: Google Trust Services roots

On 09/02/2017 20:55, Ryan Hurst wrote: Peter, Thank you very much for your, as always, thorough review. Let me start by saying I agree there is an opportunity for improving the policies around how key transfers such your recent transfer and Google's are handled. It is my hope we can,

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

On 09/02/2017 18:20, Jakob Bohm wrote: On 09/02/2017 10:59, Gervase Markham wrote: On 08/02/17 11:25, Jakob Bohm wrote: My logic is that adding additional entropy to a serial number whose length is fully controlled by CA procedures can increase the mitigations against SHA-1 weaknesses. For

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

On 09/02/2017 10:59, Gervase Markham wrote: On 08/02/17 11:25, Jakob Bohm wrote: My logic is that adding additional entropy to a serial number whose length is fully controlled by CA procedures can increase the mitigations against SHA-1 weaknesses. For example if the existing CA setup uses all

<    1   2   3   4   5