Re: Mozilla Policy and CCADB Disclosure scope

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

Re: Mozilla Policy and CCADB Disclosure scope

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: Google Plan for Symantec posted

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

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: Google Plan for Symantec posted

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

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: DRAFT: Notice to CAs about CCADB changes May 19-21

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

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

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: [EXT] Google Plan for Symantec posted

> -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: TrustCor root inclusion request

> 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 >>

Google Plan for Symantec posted

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

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: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

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

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: Fix definition of constraints for id-kp-emailProtection

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

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: Clarify requirement for multi-factor auth

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

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: Symantec: Update

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: Clarify requirement for multi-factor auth

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: Symantec: Update

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

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: [EXT] Re: Draft further questions for Symantec

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

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

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

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

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

Mozilla Policy and CCADB Disclosure scope

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

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

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: Hunting for intermediates that still haven't been disclosed to CCADB

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

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

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: Fix definition of constraints for id-kp-emailProtection

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

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

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

Policy 2.5 Proposal: Clarify requirement for multi-factor auth

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: Policy 2.5 Proposal: Add anyEKU to scope

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: Require CAs to operate in accordance with their CPs and CPSes

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

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

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

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: TrustCor root inclusion request

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