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

On 19/5/2017 6:04 μμ, Jakob Bohm via dev-security-policy 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 (current or future) as a stronger identity than the technical e-mail

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

-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 Sent: viernes, 19 de mayo de 2017 16:38 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Policy 2.5 Proposal: Fix

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

Sent: viernes, 19 de mayo de 2017 15:13 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: 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

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

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

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

On 08/05/2017 12:16, Gervase Markham wrote: On 05/05/17 22:21, Jakob Bohm wrote: The issue would be implementations that only check the EE cert for their desired EKU (such as ServerAuth checking for a TLS client or EmailProtection checking for a mail client). In other words, relying parties

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

On 8/5/2017 1:18 μμ, Gervase Markham wrote: On 05/05/17 19:44, Dimitris Zacharopoulos wrote: * MUST include an EKU that has the id-kp-emailProtection value AND * MUST include a nameConstraints extension with o a permittedSubtrees with + rfc822Name entries scoped in the

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

On 6/5/2017 1:19 πμ, Peter Bowen via dev-security-policy wrote: One other question: Does your proposal allow a TCSC that covers both ServerAuth and EmailProtection for the domains of the same organization? Or put another way, would your proposed language force an organization wanting to run

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

On 05/05/17 19:44, Dimitris Zacharopoulos wrote: > * MUST include an EKU that has the id-kp-emailProtection value AND > * MUST include a nameConstraints extension with > o a permittedSubtrees with > + rfc822Name entries scoped in the Domain (@example.com) or >Domain

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

On Fri, May 5, 2017 at 2:21 PM, Jakob Bohm via dev-security-policy wrote: > On 05/05/2017 22:45, Dimitris Zacharopoulos wrote: >> >> >> >> On 5/5/2017 10:58 μμ, Peter Bowen wrote: >>> >> >> I don't know if all implementations doing path validation, use the

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

On 05/05/2017 22:45, Dimitris Zacharopoulos wrote: On 5/5/2017 10:58 μμ, Peter Bowen wrote: On Fri, May 5, 2017 at 11:58 AM, Dimitris Zacharopoulos via dev-security-policy wrote: On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote: On Fri,

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

On 5/5/2017 10:58 μμ, Peter Bowen wrote: On Fri, May 5, 2017 at 11:58 AM, Dimitris Zacharopoulos via dev-security-policy wrote: On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote: On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via

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

On Fri, May 5, 2017 at 11:58 AM, Dimitris Zacharopoulos via dev-security-policy wrote: > > > On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote: >> >> On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via >> dev-security-policy

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

On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote: On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via dev-security-policy wrote: Looking at https://github.com/mozilla/pkipolicy/issues/69 do you have a proposed language that takes

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

On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via dev-security-policy wrote: > > Looking at https://github.com/mozilla/pkipolicy/issues/69 > > do you have a proposed language that takes all comments into account? From > what I understand, the

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

Looking at https://github.com/mozilla/pkipolicy/issues/69 do you have a proposed language that takes all comments into account? From what I understand, the Subordinate CA Certificate to be considered Technically Constrained only for S/MIME: * MUST include an EKU that has the

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

On 01/05/17 09:55, Gervase Markham wrote: > "Each entry in permittedSubtrees must either be or end with a Public > Suffix." (And we'd need to link to publicsuffix.org) Aargh. This should, of course, be "Public Suffix + 1" - i.e. an actual domain owned by someone. > The second option is harder to

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

On 01/05/2017 10:55, Gervase Markham wrote: Does anyone have any thoughts about this issue, below? I sent out a message saying that I had adopted this change as proposed, but that was an error. It has not yet been adopted, because I am concerned about the below. The first option is simpler,

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

Does anyone have any thoughts about this issue, below? I sent out a message saying that I had adopted this change as proposed, but that was an error. It has not yet been adopted, because I am concerned about the below. The first option is simpler, because it does not need to get into the details

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

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

On 12/04/17 10:47, Gervase Markham wrote: > "If the certificate includes the id-kp-emailProtection extended key > usage, it MUST include the Name Constraints X.509v3 extension with > constraints on rfc822Name, with at least one name in permittedSubtrees." As worded, this would allow for a set

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

On 13/04/2017 15:46, Gervase Markham wrote: Hi Rob, You either have a great memory or good search-fu; well done for digging this out! On 12/04/17 22:14, Rob Stradling wrote: Gerv, FYI what you're proposing here (https://github.com/mozilla/pkipolicy/issues/69) was slated to appear in v2.1 of

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

Thanks Gerv. :-) On 13/04/17 14:46, Gervase Markham via dev-security-policy wrote: Hi Rob, You either have a great memory or good search-fu; well done for digging this out! On 12/04/17 22:14, Rob Stradling wrote: Gerv, FYI what you're proposing here

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

On 12/04/17 10:47, Gervase Markham via dev-security-policy wrote: Section 5.3.1 of policy 2.4.1 defines what it means to be technically constrained for email sub-CAs (those with id-kp-emailProtection). It says: "If the certificate includes the id-kp-emailProtection extended key usage, then

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

On 12/04/17 11:41, Kurt Roeckx wrote: > But I'm also wondering what you expect if it contains other EKUs like > client auth, code sign, unknown. Do we always consider them constraint? Formally, we don't care if they also have those EKUs, or whether the use of those EKUs is constrained, because

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

On 2017-04-12 11:47, Gervase Markham wrote: "If the certificate includes the id-kp-emailProtection extended key usage, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees." I think this change itself makes