Re: TrustCor root inclusion request

2017-05-19 Thread Gervase Markham via dev-security-policy
On 18/05/17 23:40, Nick Lamb wrote: > Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong > here? Judging from self-assessment document, TrustCor's actual > practices are all intended to be 3.2.2.4 compliant (I will examine in > more detail later) but the language here suggests it

Re: Mozilla Policy and CCADB Disclosure scope

2017-05-19 Thread Nick Lamb via dev-security-policy
On Friday, 19 May 2017 20:41:20 UTC+1, Matthew Hardeman wrote: > From a perspective of risk to the broader web PKI, it would appear that a > properly name constrained intermediate with (for example) only the Server > and Client TLS authentication ekus with name constraints limited to >

Re: Mozilla Policy and CCADB Disclosure scope

2017-05-19 Thread Matthew Hardeman via dev-security-policy
Thanks, Nick, for the comment on the scope difference in the dnsName constraints vs. SAN wildcard. I hadn't contemplated that. As you note, the real risk isn't dissimilar. (I would presume that this is because a CA willing to issue a SAN dnsName of *.example.com would also presumably issue a

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

2017-05-19 Thread Gervase Markham via dev-security-policy
At the moment, the CAB Forum's Network Security guidelines are audited as part of an SSL BR audit. This means that CAs or sub-CAs which only do email don't technically have to meet them. However, they also have a number of deficiencies, and the CAB Forum is looking at replacing them with something

Re: Symantec: Update

2017-05-19 Thread Peter Bowen via dev-security-policy
On Fri, May 19, 2017 at 7:25 AM, Gervase Markham via dev-security-policy wrote: > On 15/05/17 21:06, Michael Casadevall wrote: > >>> Are there any RA's left for Symantec? >> >> TBH, I'm not sure. I think Gervase asked for clarification on this >> point, but

Re: Symantec: Update

2017-05-19 Thread Gervase Markham via dev-security-policy
On 19/05/17 15:28, Peter Bowen wrote: > This is not accurate. They have indicated that the SSP customers have > some level of issuance capability. Oops. Well, they said that a while back, but yes indeed, since then we have discovered the above fact. Gerv

Re: Policy 2.5 Proposal: Add anyEKU to scope

2017-05-19 Thread Gervase Markham via dev-security-policy
On 12/05/17 14:00, Gervase Markham wrote: > Because the Mozilla root store is used by more people than Mozilla, > Kathleen would like to put anyEKU in scope even though Firefox ignores it. Implemented as specced. Gerv ___ dev-security-policy mailing

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

2017-05-19 Thread Gervase Markham via dev-security-policy
On 12/04/17 10:47, Gervase Markham wrote: > We don't have any "Email BRs" to refer to, but I think we want something > like this: > > "If the certificate includes the id-kp-emailProtection extended key > usage, it MUST include the Name Constraints X.509v3 extension with > constraints on

Re: Hunting for intermediates that still haven't been disclosed to CCADB

2017-05-19 Thread Rob Stradling via dev-security-policy
On 17/05/17 15:12, Gervase Markham wrote: On 17/05/17 15:08, Rob Stradling wrote: Incidentally, it's true that Mozilla have said that they don't care about the Code Signing trust bit any more, but the CKA_TRUST_CODE_SIGNING haven't yet been removed from certdata.txt. Bug? Yes, but a low

Mozilla Policy and CCADB Disclosure scope

2017-05-19 Thread Gervase Markham via dev-security-policy
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 related, with 2) obviously being a subset of 1). It's also possible we might decide that for some certificates, some subset of the

Policy 2.5 Proposal: Clarify requirement for multi-factor auth

2017-05-19 Thread Gervase Markham via dev-security-policy
Ryan Sleevi suggested a wording clarification/policy extension to the multi-factor auth requirement, from: "enforce multi-factor authentication for all accounts capable of directly causing certificate issuance" to "enforce multi-factor authentication for all accounts capable of causing

Re: [EXT] Re: Draft further questions for Symantec

2017-05-19 Thread Gervase Markham via dev-security-policy
On 15/05/17 22:08, Michael Casadevall wrote: > RA & EV: > Were all the certificates issued by the RAs uploaded to a CT log? If > not, what, if any, subsets were uploaded? > > I'm aware Symantec was required to upload certificates to CT or if it > was retroactive, but I'm unsure if that requirement

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

2017-05-19 Thread Gervase Markham via dev-security-policy
On 19/05/17 15:16, Inigo Barreira wrote: > What about those for gmail, Hotmail, etc.? Are out of scope? I'm not sure what you mean. If Gmail wants a TCSC for @gmail.com, they can have one. They would presumably need to set the dirName to "" or null, because no dirName can cover all of their

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

2017-05-19 Thread Gervase Markham via dev-security-policy
On 08/05/17 11:32, Dimitris Zacharopoulos wrote: > On 8/5/2017 1:18 μμ, Gervase Markham wrote: >>> + dirName entries scoped in the Organizational name and >>> location >> Help me understand how dirName interacts with id-kp-emailProtection? > > When the Subscriber belongs to an

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

2017-05-19 Thread Kurt Roeckx via dev-security-policy
On 2017-05-19 14:18, Gervase Markham wrote: Ryan Sleevi suggested a wording clarification/policy extension to the multi-factor auth requirement, from: "enforce multi-factor authentication for all accounts capable of directly causing certificate issuance" to "enforce multi-factor

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

2017-05-19 Thread Jakob Bohm via dev-security-policy
On 19/05/2017 15:13, Gervase Markham wrote: On 08/05/17 11:32, Dimitris Zacharopoulos wrote: On 8/5/2017 1:18 μμ, Gervase Markham wrote: + dirName entries scoped in the Organizational name and location Help me understand how dirName interacts with id-kp-emailProtection? When the

Re: Symantec: Update

2017-05-19 Thread Gervase Markham via dev-security-policy
On 15/05/17 21:06, Michael Casadevall wrote: > Sorry, I could have been more clear here. What I'm proposing is that > after a specific TBD NotBefore date, we require SCTs to be in place on > the certificate to be trusted. Certificates from before that date > would remain trusted as-is (pending any

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

2017-05-19 Thread Carl Mehner via dev-security-policy
On Friday, May 19, 2017 at 7:19:27 AM UTC-5, Gervase Markham wrote: > "enforce multi-factor authentication for all accounts capable of causing > certificate issuance or performing validation functions" Should we specify somewhere that multi-factor auth encompasses two _different_ factors and not

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

2017-05-19 Thread Jakob Bohm via dev-security-policy
On 19/05/2017 16:15, Gervase Markham wrote: On 19/05/17 14:58, Jakob Bohm wrote: Because the O and other dirname attributes may be shown in an e-mail client (current or future) as a stronger identity than the technical e-mail address. Do you know of any such clients? No, but it would be

RE: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

2017-05-19 Thread Inigo Barreira via dev-security-policy
Yes, I wanted to know if a regular user can use its Gmail account to get an s/mime cert but that can´t be issued because the CA can´t validate the domain properly because it´s not his or authorized to use it when doing the 3.2.2.4 Best regards Iñigo Barreira CEO StartCom CA Limited

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

2017-05-19 Thread Jakob Bohm via dev-security-policy
On 19/05/2017 16:37, Gervase Markham wrote: On 19/05/17 15:16, Inigo Barreira wrote: What about those for gmail, Hotmail, etc.? Are out of scope? I'm not sure what you mean. If Gmail wants a TCSC for @gmail.com, they can have one. They would presumably need to set the dirName to "" or null,

Re: Policy 2.5 Proposal: Require CAs to operate in accordance with their CPs and CPSes

2017-05-19 Thread Gervase Markham via dev-security-policy
On 12/05/17 14:21, Gervase Markham wrote: > Specifically, we could add text to the top of section 5.2 ("Forbidden > and Required Practices"): > > "CA operations MUST at all times be in accordance with the applicable CP > and CPS." Implemented as specced. Gerv

Google Plan for Symantec posted

2017-05-19 Thread Gervase Markham via dev-security-policy
Hi m.d.s.p., Google have posted their updated plan for Symantec in the blink-dev forum (copied below). https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ Insofar as it pertains to Google's actions, you should go over and discuss it there. But of course, this plan

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

2017-05-19 Thread Ryan Sleevi via dev-security-policy
On Fri, May 19, 2017 at 11:04 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 19/05/2017 16:15, Gervase Markham wrote: > >> On 19/05/17 14:58, Jakob Bohm wrote: >> >>> Because the O and other dirname attributes may be shown in an e-mail >>> client

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

2017-05-19 Thread Gervase Markham via dev-security-policy
On 19/05/17 16:06, Inigo Barreira wrote: > Yes, I wanted to know if a regular user can use its Gmail account to get an > s/mime cert but that can´t be issued because the CA can´t validate the > domain properly because it´s not his or authorized to use it when doing the > 3.2.2.4 This is about

Re: TrustCor root inclusion request

2017-05-19 Thread Neil Dunbar via dev-security-policy
> On 19 May 2017, at 10:24, Gervase Markham via dev-security-policy > wrote: > > On 18/05/17 23:40, Nick Lamb wrote: >> Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong >> here? Judging from self-assessment document, TrustCor's actual >>

RE: [EXT] Google Plan for Symantec posted

2017-05-19 Thread Steve Medin via dev-security-policy
> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of > Gervase Markham via dev-security-policy > Sent: Friday, May 19, 2017 11:42 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject:

Re: DRAFT: Notice to CAs about CCADB changes May 19-21

2017-05-19 Thread Kathleen Wilson via dev-security-policy
On Thursday, May 18, 2017 at 10:08:32 AM UTC-7, Kathleen Wilson wrote: > > On May 19 the following three breaking changes are planned, meaning that the > old URLs will no longer work. Any links or bookmarks to these URLs will need > to be updated. ... > > 1) The CA login page and the domain

Re: Google Plan for Symantec posted

2017-05-19 Thread Jakob Bohm via dev-security-policy
On 19/05/2017 22:04, Kathleen Wilson wrote: On Friday, May 19, 2017 at 8:42:40 AM UTC-7, Gervase Markham wrote: I have passed that document to Kathleen, and I hope she will be endorsing this general direction soon, at which point it will no longer be a draft. Assuming she does, this will

Re: Google Plan for Symantec posted

2017-05-19 Thread Jakob Bohm via dev-security-policy
On 19/05/2017 17:41, Gervase Markham wrote: Hi m.d.s.p., Google have posted their updated plan for Symantec in the blink-dev forum (copied below). https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ Insofar as it pertains to Google's actions, you should go over

Re: Google Plan for Symantec posted

2017-05-19 Thread Rob Stradling via dev-security-policy
On 19/05/17 21:04, Kathleen Wilson via dev-security-policy wrote: Hi Kathleen. I'm not quite sure how to interpret this part... - I'm not sold on the idea of requiring Symantec to use third-party CAs to perform validation/issuance on Symantec's behalf. The most serious concerns that I have

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

2017-05-19 Thread Gervase Markham via dev-security-policy
On 19/05/17 14:26, Kurt Roeckx wrote: > I'm wondering why something like this should be in the Mozilla policy > and not be part of something else that they get audited for. Section 6.5.1 of the BRs states: "The CA SHALL enforce multi‐factor authentication for all accounts capable of directly

Re: Google Plan for Symantec posted

2017-05-19 Thread Kurt Roeckx via dev-security-policy
On Fri, May 19, 2017 at 01:04:45PM -0700, Kathleen Wilson via dev-security-policy wrote: > > Gerv, thank you for all the effort you have been putting into this > investigation into Symantec's mis-issuances, and in identifying the best way > to move forward with the primary goal being to help

Re: Google Plan for Symantec posted

2017-05-19 Thread Kathleen Wilson via dev-security-policy
On Friday, May 19, 2017 at 8:42:40 AM UTC-7, Gervase Markham wrote: > > I have passed that document to Kathleen, and I hope she will be > endorsing this general direction soon, at which point it will no longer > be a draft. > > Assuming she does, this will effectively turn into a 3-way

Re: Mozilla Policy and CCADB Disclosure scope

2017-05-19 Thread Matthew Hardeman via dev-security-policy
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 holding and utilizing name constrained intermediates,

Re: Policy 2.5 Proposal: Require CAs to operate in accordance with their CPs and CPSes

2017-05-19 Thread Gervase Markham via dev-security-policy
On 12/05/17 18:54, Jakob Bohm wrote: > Perhaps tweak the wording to make the document submitted to the CCADB > binding, rather than any CP/CPS published elsewhere. While that certainly seems attractive, changing the location of the canonical CP/CPS from the CA's repository to Mozilla's repository

Re: Policy 2.5 Proposal: Clarify requirements for reporting of security failures/policy violations

2017-05-19 Thread Gervase Markham via dev-security-policy
On 12/05/17 14:18, Gervase Markham wrote: > I propose instead: > > "Changes that are motivated by a security concern such as certificate > misissuance or a root or intermediate compromise MUST be treated as a > security-sensitive, and a secure bug filed in Bugzilla. Implemented as proposed.

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

2017-05-19 Thread Gervase Markham via dev-security-policy
On 19/05/17 14:58, Jakob Bohm wrote: > Because the O and other dirname attributes may be shown in an e-mail > client (current or future) as a stronger identity than the technical > e-mail address. Do you know of any such clients? > Imagine a certificate saying that ge...@wosign.cn is "CN=Gervase

RE: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

2017-05-19 Thread Inigo Barreira via dev-security-policy
What about those for gmail, Hotmail, etc.? Are out of scope? Best regards Iñigo Barreira CEO StartCom CA Limited -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On Behalf Of Gervase Markham via dev-security-policy