On 19/05/17 14:12, Gervase Markham wrote:
> Updated language:
>
> "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,
> each such name havi
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 add
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 tech
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 (curre
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, be
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
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 sim
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 custom
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, b
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
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 Su
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 Organizati
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 rfc822
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 who
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 Domain
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 unde
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 Name
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 whose software would accept a chain such a
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 EKUs
>> at the CA level but it seems that
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, May 5, 2017 at 11:44 AM, Dimitris Zacha
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
dev-security-policy wrote:
Looking at
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 wrote:
>>>
>>> Looking at https://github.com/mozill
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 all comments into account? From
what I u
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 Subordinate CA Certificate to be considered
>
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 id-kp-emailProt
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
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, bec
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
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 rfc822
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
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 th
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
(https://github.com/mozilla/pkipolicy/issu
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 the policy, but it was vetoed by Symantec.
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 a
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 our
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 sense
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 all end-entity certificates MUST only include e-mail
addresses or mai
37 matches
Mail list logo