Re: Policy 2.5 Proposal: Require all CAs to have appropriate network security

I think the term "industry best practices" is too nebulous. For example, if I patch some of my systems but not all of them I could still make a claim that I am following best practices even though my network has plenty of other holes in it. I assume the desire is to hold CA's to account for

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 7:24:42 PM UTC-5, Ryan Sleevi wrote: > https://groups.google.com/d/msg/mozilla.dev.security.policy/yS_L_OgI5qk/OhLX9iyZBAAJ > specifically proposed > > "For example, no requirement of audit by the enterprise holding the > technically constrained intermediate, and no

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 7:58 PM, Peter Bowen wrote: > > Why do you need to add 10,000 communication points? A TCSC is, by > definition, a subordinate CA. The WebPKI is not a single PKi, is a > set of parallel PKIs which do not share a common anchor. The browser > to CA

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 12:21 PM, Ryan Sleevi via dev-security-policy wrote: > Consider, on one extreme, if every of the Top 1 sites used TCSCs to > issue their leaves. A policy, such as deprecating SHA-1, would be > substantially harder, as now there's

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 5:35 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > It is within the above that I can see a real problem in making more broad > use of TCSCs problematic. If the browser community does not effectively > move in the fashion

Sandbox: Mozilla: Audit Reminder

CAs, I was testing some changes in my CCADB Sandbox, and accidentally sent out audit reminder email from it. So, if you get an email with the subject "Sandbox: Mozilla: Audit Reminder" you can ignore it. It's likely a duplicate of the email you received last Tuesday. I apologize for the spam.

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 3:50:30 PM UTC-5, Ryan Sleevi wrote: > Right, but I reject that :) > I hope to better understand your position. In transitioning from a long time lurker to actively commenting on this list, it is my hope to contribute what that I usefully can, bow out gracefully

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 4:34 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I'm not certain that I accept the premise that TCSCs fundamentally or > substantively change that dynamic. Particularly if the validity period of > the TCSC is limited in

Re: Mozilla Policy and CCADB Disclosure scope

> > Right now the list excludes anything with a certain set of name > constraints and anything that has EKU constraints outside the in-scope > set. I'm suggesting that the first "layer" of CA certs always should > be disclosed. > I understand now. In that, I fully concur.

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 1:02 PM, Matthew Hardeman via dev-security-policy wrote: > On Monday, May 22, 2017 at 2:43:14 PM UTC-5, Peter Bowen wrote: > >> >> I would say that any CA-certificate signed by a CA that does not have >> name constraints and not

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 2:21:41 PM UTC-5, Ryan Sleevi wrote: > > > Regarding specifically the risk of the holder of a technically > > > constrained subCA issuing a certificate with an SHA-1 signature or > > > other improper signature / algorithm, my belief at this time is that > > > with

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 2:43:14 PM UTC-5, Peter Bowen wrote: > > I would say that any CA-certificate signed by a CA that does not have > name constraints and not constrained to things outside the set > {id-kp-serverAuth, id-kp-emailProtection, anyEKU} should be disclosed. > This would mean

Re: Mozilla Policy and CCADB Disclosure scope

On Fri, May 19, 2017 at 6:47 AM, Gervase Markham via dev-security-policy wrote: > We need to have a discussion about the appropriate scope for: > > 1) the applicability of Mozilla's root policy > 2) required disclosure in the CCADB > > The two questions are

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 2:14:57 PM UTC-5, Ryan Sleevi wrote: > Another approach is to make an argument that such validations are already > accounted for in the EV Guidelines, in which a certificate may be issued > for 27 months, but for which the domain must be revalidated at 13 months. > In

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 12:50 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 22/05/17 16:43, Matthew Hardeman wrote: > > Regarding specifically the risk of the holder of a technically > > constrained subCA issuing a certificate with an SHA-1

Re: Mozilla Policy and CCADB Disclosure scope

On Mon, May 22, 2017 at 1:41 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, May 22, 2017 at 11:50:59 AM UTC-5, Gervase Markham wrote: > > > How do the various validation routines in the field today validate a > > > scenario in which a

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 11:50:59 AM UTC-5, Gervase Markham wrote: > So your proposal is that technical requirements should be enforced > in-product rather than in-policy, and so effectively there's no need for > policy for the EE certs under a TCSC. > > This is not an unreasonable position. >

Re: Google Plan for Symantec posted

On 22/05/2017 18:33, Gervase Markham wrote: On 19/05/17 21:04, Kathleen Wilson wrote: - What validity periods should be allowed for SSL certs being issued in the old PKI (until the new PKI is ready)? Symantec is required only to be issuing in the new PKI by 2017-08-08 - in around ten weeks

Re: Google Plan for Symantec posted

Comments inline On 20/05/2017 16:49, Michael Casadevall wrote: Comments inline. On 05/19/2017 05:10 PM, Jakob Bohm wrote: Suggested trivial changes relative to the proposal for Mozilla use: 3. All non-expired Symantec issued certificates of any kind (including SubCAs and revoked

Re: Google Plan for Symantec posted

On Mon, May 22, 2017 at 05:33:26PM +0100, Gervase Markham via dev-security-policy wrote: > Google are doing a phased distrust of old certs, but they have not set a > date in their plan for total distrust of the old PKI. We should ask them > what their plans are for that. My understanding is that

Re: Mozilla Policy and CCADB Disclosure scope

On 22/05/17 16:43, Matthew Hardeman wrote: > Regarding specifically the risk of the holder of a technically > constrained subCA issuing a certificate with an SHA-1 signature or > other improper signature / algorithm, my belief at this time is that > with respect to the web PKI, we should be able

Re: Google Plan for Symantec posted

On 21/05/17 19:37, userwithuid wrote: > With the new proposal, the "minimal disruption" solution for Firefox > will require keeping the legacy stuff around for another 3.5-4 years > and better solutions will now be a lot harder to sell without the > leverage provided by Google. Why so? In eight

Re: Google Plan for Symantec posted

On 19/05/17 22:10, Jakob Bohm wrote: > Necessity: Whitelists in various forms based on such CT log entries, > as well as the SCTs in OCSP responses can provide an alternative for > relying parties checking current certificates even if the cleanup at > Symantec reveals a catastrophic breach

Re: Google Plan for Symantec posted

On 19/05/17 21:04, Kathleen Wilson wrote: > - What validity periods should be allowed for SSL certs being issued > in the old PKI (until the new PKI is ready)? Symantec is required only to be issuing in the new PKI by 2017-08-08 - in around ten weeks time. In the mean time, there is no

Re: Mozilla Policy and CCADB Disclosure scope

On Monday, May 22, 2017 at 3:41:50 AM UTC-5, Gervase Markham wrote: > On 19/05/17 20:40, Matthew Hardeman wrote: > > Not speaking as to the status quo, but rather in terms of > > updates/changes which might be considered for incorporation into > > policy would be to recognize the benefit of name

Re: Symantec: Update

On 20/05/17 15:26, Michael Casadevall wrote: > However, for Mozilla's purposes, is there a case where having a SCT in > certificate would either break something, or otherwise be undesirable? I believe we turned the checking on and discovered performance issues, so we turned it off. I'm not sure

Re: Mozilla Policy and CCADB Disclosure scope

On 19/05/17 20:40, Matthew Hardeman wrote: > Not speaking as to the status quo, but rather in terms of > updates/changes which might be considered for incorporation into > policy would be to recognize the benefit of name constrained > intermediates and allow a reduction in burden to entities

Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

On 19/05/17 15:52, Carl Mehner wrote: > Should we specify somewhere that multi-factor auth encompasses two > _different_ factors and not simply multiple authenticators? I appreciate your desire to cover all the angles, but I think the standard definition of the term encompasses this. I think