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

[Dimitris Zacharopoulos via dev-security-policy]

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


Do you know of any such clients?



No, but it would be similar to how Fx displays that field in EV certs,
so a future Thunderbird, or a non-Mozilla client could reasonably do
something similar, even at OV level.


It doesn't have to be displayed in a client UI. It is information in the 
Subject of the Certificate and Relying Parties read and decide what to 
do with this information. I think we need to describe some use cases to 
better understand if dirName in permittedSubtrees must be required.


One case, is issuing a TCSC for an organization so that this 
organization (and possibly its affiliates) can issue personal 
certificates for employees. These personal certificates, apart from 
document signing/client authentication, could also be used for s/mime.


Just as section 7.1.5 of the BRs for TCSCs require a dirName present in 
the permittedSubtrees, having a similar requirement for 
email-constrained TCSCs reduces the risk of having end-entity 
certificates that bind particular users (e.g. CN=John Doe) to an 
organization (O=Very High Profile Corporation). If the TCSC was 
restricted to dirName="C=XX, L=XXX, O=ACME", the risk is lower. The 
administrator could still allow any e-mail address to be included in the 
end-entity certificates.


Another case that was described in this thread is an e-mail provider 
(such as Gmail) that wants to constrain issuance via a TCSC for 
@gmail.com. However, as Gerv pointed out, they would need to allow only 
information related to their customers (CN=John Doe and 
emailAddress=jsomeu...@gmail.com). I don't think dirName entries in 
permittedSubtrees allow such a representation. If there was a way to 
limit this, we would have a solution for both cases.


Are there any other cases we should consider in this discussion? IMHO, 
because of the risk associated in the first use case (incorrect binding 
between a natural person and an organization), TCSCs should require a 
dirName.



Dimitris.





Imagine a certificate saying that ge...@wosign.cn is "CN=Gervase
Markham, O=Mozilla Corporation, ST=California, CN=US", issued by a
SubCA name constrained to "@wosign.cn", but not to any range of DNs.


Surely such a certificate would be misissued? Although I guess the issue
here is that we are excluding them from scope...

So the idea would be to say that dirName had to be constrained to either
be empty (is that possible?) or to contain a dirNames validated as
correctly representing an organization owning at least one of the domain
name(s) in the cert?



Rather: It should be constrained to an X.500 subtree identifying an
organization validated to at least BR compliant OV level (EV level if
SubCA notBefore after some policy date) as for a ServerAuth certificate
for the same domain names specified in the rfc822name restrictions.

Keeps it short and simple and subject to well-understood policies.

Enjoy

Jakob


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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 technically constrained sub-CAs, not about general email
certs.

If you are issuing a TCSC for gmail.com, you should only be issuing that
to Google, who can prove ownership of gmail.com. You should not be
issuing it to any old Gmail user :-)

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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 (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 similar to how Fx displays that field in EV certs,
> so a future Thunderbird, or a non-Mozilla client could reasonably do
> something similar, even at OV level.


It sounds like that issue should be dealt with when there are Mozilla
clients that require such use case.

For example, the recognition of EV involves a whole separate set of
additional policies, for which OV is not suitable. The notion of EV S/MIME,
as terrible as it is from a security and usability perspective, would
minimally need to account for that in light of the existing lack of
standards regarding S/MIME issuance.

It does not seem useful or productive for Mozilla's Root Store to attempt
to solve that abstract case for which there are no direct Mozilla product
consumers, particularly when it can entirely be addressed at a later time.


> Keeps it short and simple and subject to well-understood policies.


Avoiding that policy requirement entirely avoids introducing feature creep
for unspecified and unused features.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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, because no dirName can cover all of their customers, as their
customerd don't represent Google?

Gerv



Or it could be O=GMail Canada Users, C=CA for @gmail.ca with the SubCA
itself being O=Google.  Etc. For each country-specific GMail domain.
@gmail.com would be C=US, or some C= value indicating unknown country
(if permitted in the X.500 standards).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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


-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 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 customers, as their customerd
don't represent Google?

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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 similar to how Fx displays that field in EV certs,
so a future Thunderbird, or a non-Mozilla client could reasonably do
something similar, even at OV level.


Imagine a certificate saying that ge...@wosign.cn is "CN=Gervase
Markham, O=Mozilla Corporation, ST=California, CN=US", issued by a
SubCA name constrained to "@wosign.cn", but not to any range of DNs.


Surely such a certificate would be misissued? Although I guess the issue
here is that we are excluding them from scope...

So the idea would be to say that dirName had to be constrained to either
be empty (is that possible?) or to contain a dirNames validated as
correctly representing an organization owning at least one of the domain
name(s) in the cert?



Rather: It should be constrained to an X.500 subtree identifying an
organization validated to at least BR compliant OV level (EV level if
SubCA notBefore after some policy date) as for a ServerAuth certificate
for the same domain names specified in the rfc822name restrictions.

Keeps it short and simple and subject to well-understood policies.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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 customers, as their
customerd don't represent Google?

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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
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 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 rfc822Name, with at least one name in permittedSubtrees."

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
having its ownership validated according to section
3.2.2.4 of the BRs."

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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
> Markham, O=Mozilla Corporation, ST=California, CN=US", issued by a
> SubCA name constrained to "@wosign.cn", but not to any range of DNs.

Surely such a certificate would be misissued? Although I guess the issue
here is that we are excluding them from scope...

So the idea would be to say that dirName had to be constrained to either
be empty (is that possible?) or to contain a dirNames validated as
correctly representing an organization owning at least one of the domain
name(s) in the cert?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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 Subscriber belongs to an Organization that needs to be included
in the subjectDN.


Right, but why do we need name constraints here?

It seems to me that positive constraints on rfc822Name are sufficient
for an intermediate to be a TCSC.

Gerv



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.

Imagine a certificate saying that ge...@wosign.cn is "CN=Gervase
Markham, O=Mozilla Corporation, ST=California, CN=US", issued by a
SubCA name constrained to "@wosign.cn", but not to any range of DNs.

It would be problematic for such a SubCA to be considered a TCSC
excluded from all usual checks and balances.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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 Organization that needs to be included
> in the subjectDN.

Right, but why do we need name constraints here?

It seems to me that positive constraints on rfc822Name are sufficient
for an intermediate to be a TCSC.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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 rfc822Name, with at least one name in permittedSubtrees."

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 having its ownership validated according to section
3.2.2.4 of the BRs."

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

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 whose software would accept a chain such as

root CA (no EKUs) => SubCA (EmailProtection) => EE cert (ServerAuth).


Do you know of any such implementations?


I am not sure.  I suspect such simple implementations (that only check
for the specifically desired EKU in the EE cert) were common in the
past, and I don't know if all implementations have switched to the
interpretation that CA EKUs act as constraints on child EKUs.

This simple implementation kind would correspond to interpreting the
EKUs in a CA cert to describe the abilities of the CA cert itself (i.e.
it could reasonable list only CA related uses such as CertSign,
CRLSign, OCSPSign).  (Not checked for typos).




One other question: Does your proposal allow a TCSC that covers both
ServerAuth and EmailProtection for the domains of the same organization?


I don't believe my proposal forbids this. Do you think it should?



These questions were directed at Dimitris' wording.


Does Mozilla as a Browser implementer have any policy or technical
requirements on certificates that Mozilla products can use for
ClientAuth


No policy requirements to my knowledge. There may be technical
requirements (e.g. now we've turned off SHA-1 support, I doubt that
works with ClientAuth either).





Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Dimitris Zacharopoulos via dev-security-policy]

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 (@example.com) or
Domain Namespace (@example.com, @.example.com) controlled by
an Organization and

It's this part that I'm looking for good wording for to make sure I
don't accidentally exclude valid use cases.


  + 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 Organization that needs to be included 
in the subjectDN.



Dimitris.




(a) For each rfc822Name in permittedSubtrees, the CA MUST confirm that
the Applicant has registered the Domain or Domain Namespace or has been
authorized by the domain registrant to act on the registrant's behalf in
line with the verification practices of section 3.2.2.4.
(b) For each DirectoryName in permittedSubtrees the CA MUST confirm the
Applicants and/or Subsidiary’s Organizational name and location such
that end entity certificates issued from the subordinate CA Certificate
will be in compliance with section 7.1.2.4 and 7.1.2.5.

Does anyone see problems with this language?

Gerv


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Dimitris Zacharopoulos via dev-security-policy]

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 under its own TCSC(s) to obtain two TCSCs, one for their
S/MIME needs and another for their TLS needs?

Yes, it allows a single TCSC that does both.  The little three diamond
symbol means parallel, so both legs are evaluated at the same time.
If both get to "Goto B", then it is a single TCSC that can issue both
serverAuth and emailProtection certs.


As Gerv pointed out in previous messages, this issue is described in 
https://github.com/mozilla/pkipolicy/issues/26. The current Mozilla 
policy does not force separating Intermediate CAs for serverAuth and 
emailProtection certs.


Microsoft's Policy 
 
currently says:


"/New/ intermediate CA certificates under root certificates submitted 
for distribution by the Program must separate Server Authentication, 
S/MIME, Code Signing and Time Stamping uses. This means that a single 
intermediate issuing CA must not be used to issue both server 
authentication, S/MIME, and code signing certificates. A separate 
intermediate must be used for each use case."


It would be ideal if both policies were aligned to either allow both 
serverAuth and emailProtection from the same Intermediate CA, or 
separate them. As we are today, CAs that participate in Mozilla and 
Microsoft Root program need to comply with the more restrictive policy.



Dimitris.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Gervase Markham via dev-security-policy]

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 Namespace (@example.com, @.example.com) controlled by
>an Organization and

It's this part that I'm looking for good wording for to make sure I
don't accidentally exclude valid use cases.

>  + dirName entries scoped in the Organizational name and location

Help me understand how dirName interacts with id-kp-emailProtection?

> (a) For each rfc822Name in permittedSubtrees, the CA MUST confirm that
> the Applicant has registered the Domain or Domain Namespace or has been
> authorized by the domain registrant to act on the registrant's behalf in
> line with the verification practices of section 3.2.2.4.
> (b) For each DirectoryName in permittedSubtrees the CA MUST confirm the
> Applicants and/or Subsidiary’s Organizational name and location such
> that end entity certificates issued from the subordinate CA Certificate
> will be in compliance with section 7.1.2.4 and 7.1.2.5.

Does anyone see problems with this language?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Peter Bowen via dev-security-policy]

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 the most popular applications use it.
>>
>
> 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 as
>
> root CA (no EKUs) => SubCA (EmailProtection) => EE cert (ServerAuth).

This is the Mozilla policy and Mozilla does not do that, so I think we
should be fine there.

>>> If you look at
>>> https://imagebin.ca/v/3LRcaKW9t2Qt, you will see that TCSC will end up
>>> being two independent tests.
>>>
>
>
> 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 under its own TCSC(s) to obtain two TCSCs, one for their
> S/MIME needs and another for their TLS needs?

Yes, it allows a single TCSC that does both.  The little three diamond
symbol means parallel, so both legs are evaluated at the same time.
If both get to "Goto B", then it is a single TCSC that can issue both
serverAuth and emailProtection certs.

Also note that there is no check for pathlen:0 on the TCSC, so it
could be a policy CA that has multiple issuing CAs below it.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

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 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
Technically Constrained only for S/MIME:

   * 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 Namespace (@example.com, @.example.com)
controlled by
 an Organization and
   + dirName entries scoped in the Organizational name and
location
   o an excludedSubtrees with
   + a zero‐length dNSName
   + an iPAddress GeneralName of 8 zero octets (covering
the IPv4
 address range of 0.0.0.0/0)
   + an iPAddress GeneralName of 32 zero octets (covering the
 IPv6 address range of ::0/0)

Why do we need to address dNSName and iPAddress if the only EKU is
id-kp-emailProtection?

Can we simplify this to just requiring at least one rfc822Name entry
in the permittedSubtrees?


I would be fine with this but there may be implementations that
ignore the
EKU at the Intermediate CA level.

I've only ever heard of people saying that adding EKU at the
intermediate level breaks things, not that things ignore it.


You are probably right. Two relevant threads:

 * https://www.ietf.org/mail-archive/web/pkix/current/msg33507.html and
 * an older one from year 2000
   (https://www.ietf.org/mail-archive/web/pkix/current/msg06821.html)

I don't know if all implementations doing path validation, use the EKUs
at the CA level but it seems that the most popular applications use it.



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 as


root CA (no EKUs) => SubCA (EmailProtection) => EE cert (ServerAuth).




So, if we want to align with both the CA/B
Forum BRs section 7.1.5 and the Mozilla Policy for S/MIME, perhaps we
should
keep the excludedSubtrees.

The BRs cover serverAuth.


Of course they do, I was merely trying to re-use the same language for
S/MIME usage :)


Dimitris.


If you look at
https://imagebin.ca/v/3LRcaKW9t2Qt, you will see that TCSC will end up
being two independent tests.




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 under its own TCSC(s) to obtain two TCSCs, one for their
S/MIME needs and another for their TLS needs?

P.S.

Does Mozilla as a Browser implementer have any policy or technical
requirements on certificates that Mozilla products can use for
ClientAuth (e.g. does Firefox only offer certs with the ClientAuth (or
no) EKU when prompting a user which cert to send to a webserver,
similar for Thunderbird doing ClientAuth to a TLS protected e-mail
server).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Dimitris Zacharopoulos via dev-security-policy]

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 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-emailProtection value AND
   * MUST include a nameConstraints extension with
   o a permittedSubtrees with
   + rfc822Name entries scoped in the Domain (@example.com) or
 Domain Namespace (@example.com, @.example.com) controlled by
 an Organization and
   + dirName entries scoped in the Organizational name and
location
   o an excludedSubtrees with
   + a zero‐length dNSName
   + an iPAddress GeneralName of 8 zero octets (covering the IPv4
 address range of 0.0.0.0/0)
   + an iPAddress GeneralName of 32 zero octets (covering the
 IPv6 address range of ::0/0)

Why do we need to address dNSName and iPAddress if the only EKU is
id-kp-emailProtection?

Can we simplify this to just requiring at least one rfc822Name entry
in the permittedSubtrees?


I would be fine with this but there may be implementations that ignore the
EKU at the Intermediate CA level.

I've only ever heard of people saying that adding EKU at the
intermediate level breaks things, not that things ignore it.


You are probably right. Two relevant threads:

 * https://www.ietf.org/mail-archive/web/pkix/current/msg33507.html and
 * an older one from year 2000
   (https://www.ietf.org/mail-archive/web/pkix/current/msg06821.html)

I don't know if all implementations doing path validation, use the EKUs 
at the CA level but it seems that the most popular applications use it.





So, if we want to align with both the CA/B
Forum BRs section 7.1.5 and the Mozilla Policy for S/MIME, perhaps we should
keep the excludedSubtrees.

The BRs cover serverAuth.


Of course they do, I was merely trying to re-use the same language for 
S/MIME usage :)



Dimitris.


If you look at
https://imagebin.ca/v/3LRcaKW9t2Qt, you will see that TCSC will end up
being two independent tests.

Thanks,
Peter



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Peter Bowen via dev-security-policy]

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/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-emailProtection value AND
>>>   * MUST include a nameConstraints extension with
>>>   o a permittedSubtrees with
>>>   + rfc822Name entries scoped in the Domain (@example.com) or
>>> Domain Namespace (@example.com, @.example.com) controlled by
>>> an Organization and
>>>   + dirName entries scoped in the Organizational name and
>>> location
>>>   o an excludedSubtrees with
>>>   + a zero‐length dNSName
>>>   + an iPAddress GeneralName of 8 zero octets (covering the IPv4
>>> address range of 0.0.0.0/0)
>>>   + an iPAddress GeneralName of 32 zero octets (covering the
>>> IPv6 address range of ::0/0)
>>
>> Why do we need to address dNSName and iPAddress if the only EKU is
>> id-kp-emailProtection?
>>
>> Can we simplify this to just requiring at least one rfc822Name entry
>> in the permittedSubtrees?
>
>
> I would be fine with this but there may be implementations that ignore the
> EKU at the Intermediate CA level.

I've only ever heard of people saying that adding EKU at the
intermediate level breaks things, not that things ignore it.

> So, if we want to align with both the CA/B
> Forum BRs section 7.1.5 and the Mozilla Policy for S/MIME, perhaps we should
> keep the excludedSubtrees.

The BRs cover serverAuth.  If you look at
https://imagebin.ca/v/3LRcaKW9t2Qt, you will see that TCSC will end up
being two independent tests.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Dimitris Zacharopoulos via dev-security-policy]

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 understand, the Subordinate CA Certificate to be considered
Technically Constrained only for S/MIME:

  * 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 Namespace (@example.com, @.example.com) controlled by
an Organization and
  + dirName entries scoped in the Organizational name and location
  o an excludedSubtrees with
  + a zero‐length dNSName
  + an iPAddress GeneralName of 8 zero octets (covering the IPv4
address range of 0.0.0.0/0)
  + an iPAddress GeneralName of 32 zero octets (covering the
IPv6 address range of ::0/0)

Why do we need to address dNSName and iPAddress if the only EKU is
id-kp-emailProtection?

Can we simplify this to just requiring at least one rfc822Name entry
in the permittedSubtrees?


I would be fine with this but there may be implementations that ignore 
the EKU at the Intermediate CA level. So, if we want to align with both 
the CA/B Forum BRs section 7.1.5 and the Mozilla Policy for S/MIME, 
perhaps we should keep the excludedSubtrees.


Dimitris.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Peter Bowen via dev-security-policy]

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
> Technically Constrained only for S/MIME:
>
>  * 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 Namespace (@example.com, @.example.com) controlled by
>an Organization and
>  + dirName entries scoped in the Organizational name and location
>  o an excludedSubtrees with
>  + a zero‐length dNSName
>  + an iPAddress GeneralName of 8 zero octets (covering the IPv4
>address range of 0.0.0.0/0)
>  + an iPAddress GeneralName of 32 zero octets (covering the
>IPv6 address range of ::0/0)

Why do we need to address dNSName and iPAddress if the only EKU is
id-kp-emailProtection?

Can we simplify this to just requiring at least one rfc822Name entry
in the permittedSubtrees?

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Dimitris Zacharopoulos via dev-security-policy]

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-emailProtection value AND
 * MUST include a nameConstraints extension with
 o a permittedSubtrees with
 + rfc822Name entries scoped in the Domain (@example.com) or
   Domain Namespace (@example.com, @.example.com) controlled by
   an Organization and
 + dirName entries scoped in the Organizational name and location
 o an excludedSubtrees with
 + a zero‐length dNSName
 + an iPAddress GeneralName of 8 zero octets (covering the IPv4
   address range of 0.0.0.0/0)
 + an iPAddress GeneralName of 32 zero octets (covering the
   IPv6 address range of ::0/0)

Borrowing language from BRs 7.1.5, it would look like this:

"If the Subordinate CA Certificate includes the id‐kp‐emailProtection 
extended key usage, then the Subordinate CA Certificate MUST include the 
Name Constraints X.509v3 extension with constraints on rfc822Name and 
DirectoryName as follows:


(a) For each rfc822Name in permittedSubtrees, the CA MUST confirm that 
the Applicant has registered the Domain or Domain Namespace or has been 
authorized by the domain registrant to act on the registrant's behalf in 
line with the verification practices of section 3.2.2.4.
(b) For each DirectoryName in permittedSubtrees the CA MUST confirm the 
Applicants and/or Subsidiary’s Organizational name and location such 
that end entity certificates issued from the subordinate CA Certificate 
will be in compliance with section 7.1.2.4 and 7.1.2.5.


If the Subordinate CA Certificate is not allowed to issue certificates 
with an iPAddress, then the Subordinate CA Certificate MUST specify the 
entire IPv4 and IPv6 address ranges in excludedSubtrees. The Subordinate 
CA Certificate MUST include within excludedSubtrees an iPAddress 
GeneralName of 8 zero octets (covering the IPv4 address range of 
0.0.0.0/0). The Subordinate CA Certificate MUST also include within 
excludedSubtrees an iPAddress GeneralName of 32 zero octets (covering 
the IPv6 address range of ::0/0). Otherwise, the Subordinate CA 
Certificate MUST include at least one iPAddress in permittedSubtrees.


If the Subordinate CA is not allowed to issue certificates with 
dNSNames, then the Subordinate CA Certificate MUST include a zero‐length 
dNSName in excludedSubtrees. Otherwise, the Subordinate CA Certificate 
MUST include at least one dNSName in permittedSubtrees."


Although this might seem to be an overkill (perhaps the EKU should be 
sufficient and we could remove the requirement for excludedSubtrees) , 
it clearly narrows down the scope of such a Subordinate CA to only S/MIME.



Dimitris.



On 5/5/2017 7:16 μμ, Gervase Markham via dev-security-policy wrote:

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 spec, because I don't know the uses to
which TCSCs for email are put. Is the idea that they get handed to a
customer, and so it's OK to say that the domain names have to be
validated as being owned by the entity which has authority to command
issuance? Or are there scenarios I'm missing?

CAs who issue email certs need to pay attention here, as I want to close
this loophole but am at risk of making policy which does not suit you,
if you do not engage in this discussion.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Gervase Markham via dev-security-policy]

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 spec, because I don't know the uses to
> which TCSCs for email are put. Is the idea that they get handed to a
> customer, and so it's OK to say that the domain names have to be
> validated as being owned by the entity which has authority to command
> issuance? Or are there scenarios I'm missing?

CAs who issue email certs need to pay attention here, as I want to close
this loophole but am at risk of making policy which does not suit you,
if you do not engage in this discussion.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

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, because it does not need to get into the
details of who controls or who has issuance authority for the
intermediate, and what their relationship is with the domain names in
question. Some concrete proposed text for that option is:

"Each entry in permittedSubtrees must either be or end with a Public
Suffix." (And we'd need to link to publicsuffix.org)

The second option is harder to spec, because I don't know the uses to
which TCSCs for email are put. Is the idea that they get handed to a
customer, and so it's OK to say that the domain names have to be
validated as being owned by the entity which has authority to command
issuance? Or are there scenarios I'm missing?




On 20/04/17 14:26, Gervase Markham wrote:

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 of constraints which looked like:

".com, .net, .edu, .us, .uk, ..."

The SSL BRs require:

"(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the
Applicant has registered the dNSName or has been authorized by the
domain registrant to act on the registrant's behalf in line with the
verification practices of section 3.2.2.4."

That's not possible for e.g. ".com", so the problem is avoided.

Do we need to say that each entry in permittedSubtrees must be a Public
Suffix? Or do we need to require that each rfc822Name is
ownership-validated in a analogous way to the dNSNames in the BRs?

Gerv



Some cases to consider:

  If the permittedSubtrees specifies a public suffix, the SubCA should
  not be considered a TCSC.  It could however be a public SubCA
  dedicated to some part of the Internet, such as a country.

  If the permittedSubtrees ends with, but isn't, a public suffix, then
  the ability to issue under the TCSC should be limited to a single
  entity which has been validated to have full authority over each
  domain specified.

  If the permittedSubtrees specifies a domain that is *not* a public
  suffix, but is an IANA TLD (The classic example would be a
  hypothetical .cocacola. TLD), then the ability to issue under the
  TCSC should be limited to a single entity which has been validated to
  have full authority over each domain specified.

Thus perhaps it would be more appropriate to require that in a TCSC,
the permittedSubtrees must NOT list any public suffix or a suffix of a
public suffix.  And that control of the TCSC must be exclusively by
someone properly validated to act on behalf of each domain listed in
permittedSubtrees.

I am using the phrase "control" as a placeholder for whatever phrase
would be consistent with wording elsewhere in the policy for someone
who either:

- Is in exclusive possession of the TCSC private key material and makes
 their own decisions regarding issuance

OR

- Holds exclusive RA authority for non-technical certificates issued
 under the TCSC, while the private key is stored elsewhere (e.g. at the
 parent CA or at some other CA outsourcing facility).

OR

- Holds blocking RA authority for the TCSC such that all non-technical
 certificates issued under the TCSC require approval by the entity, but
 that additional policy requirements may be checked/enforced by some
 other entity (for example the CA outsourcing provider may be doing
 some/all of the same automated checks it would have done for an EE
 cert issued from a public SubCA).  This would be a common case where
 the private key is hosted by the parent CA under some "Enterprise
 customer" user interface.

I am using the phrase "technical certificates" as a placeholder for
whatever phrase would be consistent with wording elsewhere in the
policy for  for such things as OCSP signing certificates, CRL signing
certificates, time stamping certificates and other such CA operational
certificate types now known or yet to be invented.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Gervase Markham via dev-security-policy]

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 of who controls or who has issuance authority for the
intermediate, and what their relationship is with the domain names in
question. Some concrete proposed text for that option is:

"Each entry in permittedSubtrees must either be or end with a Public
Suffix." (And we'd need to link to publicsuffix.org)

The second option is harder to spec, because I don't know the uses to
which TCSCs for email are put. Is the idea that they get handed to a
customer, and so it's OK to say that the domain names have to be
validated as being owned by the entity which has authority to command
issuance? Or are there scenarios I'm missing?

Gerv

On 20/04/17 14:26, Gervase Markham wrote:
> 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 of constraints which looked like:
> 
> ".com, .net, .edu, .us, .uk, ..."
> 
> The SSL BRs require:
> 
> "(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the
> Applicant has registered the dNSName or has been authorized by the
> domain registrant to act on the registrant's behalf in line with the
> verification practices of section 3.2.2.4."
> 
> That's not possible for e.g. ".com", so the problem is avoided.
> 
> Do we need to say that each entry in permittedSubtrees must be a Public
> Suffix? Or do we need to require that each rfc822Name is
> ownership-validated in a analogous way to the dNSNames in the BRs?
> 
> Gerv
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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 rfc822Name, with at least one name in permittedSubtrees."

Adopted as proposed.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Gervase Markham via dev-security-policy]

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 of constraints which looked like:

".com, .net, .edu, .us, .uk, ..."

The SSL BRs require:

"(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the
Applicant has registered the dNSName or has been authorized by the
domain registrant to act on the registrant's behalf in line with the
verification practices of section 3.2.2.4."

That's not possible for e.g. ".com", so the problem is avoided.

Do we need to say that each entry in permittedSubtrees must be a Public
Suffix? Or do we need to require that each rfc822Name is
ownership-validated in a analogous way to the dNSNames in the BRs?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

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 the policy, but it was vetoed by Symantec.

Here's why...

https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/l1BAEHjKe8Q/mey4WREKpooJ


Hmm. I note we didn't end up using Symantec's proposed text either.

I'm not sure I entirely understand their objection. They wanted to
confirm via "business controls" that the customer was authorized to
issue email certs for the domain. What sort of thing might that be, and
how is it different to a technical control? Does it just involve the
customer pinky-swearing that it's OK for them to issue such certs?

I can see that CAs might want to issue email certs for almost any
domain, if the controller of an email address comes and asks for one.
But in that sort of case, I wouldn't expect them to be using a TCSC.
TCSCs are for "Hi, I'm Company X, and have 100,000 employees with
@companyx.com email addresses, and want to issue them publicly-trusted
email certs. Give me a TCSC for @companyx.com." Whereupon the CA would
get them to prove they own that domain, then provide them with such a
certificate.



Could the difference be one of outsourcing: Suppose Company X has
outsourced e-mail server operations (but not employee identity
checking) to big-name email provider Y.  Then Y has technical control
over @companyx.com, but Company X has business control and the
authority to decide who should and shouldn't get @companyx.com e-mail
certs.  For @companyx.maily.net e-mail addresses, that authority may
also be divorced from ownership of the maily.net domain.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Rob Stradling via dev-security-policy]

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/issues/69) was slated to appear in
v2.1 of the policy, but it was vetoed by Symantec.

Here's why...

https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/l1BAEHjKe8Q/mey4WREKpooJ


Hmm. I note we didn't end up using Symantec's proposed text either.

I'm not sure I entirely understand their objection. They wanted to
confirm via "business controls" that the customer was authorized to
issue email certs for the domain. What sort of thing might that be, and
how is it different to a technical control? Does it just involve the
customer pinky-swearing that it's OK for them to issue such certs?

I can see that CAs might want to issue email certs for almost any
domain, if the controller of an email address comes and asks for one.
But in that sort of case, I wouldn't expect them to be using a TCSC.
TCSCs are for "Hi, I'm Company X, and have 100,000 employees with
@companyx.com email addresses, and want to issue them publicly-trusted
email certs. Give me a TCSC for @companyx.com." Whereupon the CA would
get them to prove they own that domain, then provide them with such a
certificate.

Gerv


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Rob Stradling via dev-security-policy]

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 all end-entity certificates MUST only include e-mail
addresses or mailboxes that the issuing CA has confirmed (via technical
and/or business controls) that the subordinate CA is authorized to use."

This is bogus.



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.


Here's why...

https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/l1BAEHjKe8Q/mey4WREKpooJ 



--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Gervase Markham via dev-security-policy]

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 root program is not concerned
with those uses of certificates.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Kurt Roeckx via dev-security-policy]

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.

Reading that section, I think it could use some improvements. It's for 
instance not really clear that this is needed "to be considered 
technically constrained", but I guess that's the intention.


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?


So I'm suggesting something like:
When the following EKUs are included, to be considered technically 
constrained, the following additional constraints should be present.



Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy