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

[Gervase Markham]

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. What it says here is something that you have to do for
any email cert - it's not a technical constraint but a policy
constraint, and it's basically the same as 2.2.2:

"for a certificate capable of being used for digitally signing or
encrypting email messages, the CA takes reasonable measures to verify
that the entity submitting the request controls the email account
associated with the email address referenced in the certificate or has
been authorized by the email account holder to act on the account
holder’s behalf;"

Section 5.3.1 should define technical constraints on the intermediate
appropriate for restricting email addresses to a whitelist of domains,
just as the section for id-kp-serverAuth restricts to a whitelist of
domains.

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

This is: https://github.com/mozilla/pkipolicy/issues/69

-------

This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates

[Kurt Roeckx]

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

[Gervase Markham]

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

[Rob Stradling]

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.

<snip>

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

[Gervase Markham]

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]

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

[Jakob Bohm]

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

[Gervase Markham]

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

[Gervase Markham]

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

[Gervase Markham]

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

[Jakob Bohm]

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.

[Gervase Markham]

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

[Dimitris Zacharopoulos]

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-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Peter Bowen]

On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via
dev-security-policy <dev-secur...@lists.mozilla.org> 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

[Dimitris Zacharopoulos]

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.

[Peter Bowen]

On Fri, May 5, 2017 at 11:58 AM, Dimitris Zacharopoulos via

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

[Dimitris Zacharopoulos]

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.

[Jakob Bohm]

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

[Peter Bowen]

On Fri, May 5, 2017 at 2:21 PM, Jakob Bohm via dev-security-policy
<dev-secur...@lists.mozilla.org> 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

[Gervase Markham]

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?

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

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

Gerv

[Gervase Markham]

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

[Dimitris Zacharopoulos]

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
<https://social.technet.microsoft.com/wiki/contents/articles/31633.microsoft-trusted-root-program-requirements.aspx>
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.

[Dimitris Zacharopoulos]

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.

[Jakob Bohm]

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

[Gervase Markham]

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

[Gervase Markham]

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

[Jakob Bohm]

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.

[Gervase Markham]

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

[Inigo Barreira]

What about those for gmail, Hotmail, etc.? Are out of scope?

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

[Gervase Markham]

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

[Jakob Bohm]

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.

[Inigo Barreira]

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=startco...@lists.mozilla.org]
On Behalf Of Gervase Markham via dev-security-policy
Sent: viernes, 19 de mayo de 2017 16:38
To: mozilla-dev-s...@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?

[Jakob Bohm]

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

[Ryan Sleevi]

On Fri, May 19, 2017 at 11:04 AM, Jakob Bohm via dev-security-policy <
dev-secur...@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.

[Gervase Markham]

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

[Dimitris Zacharopoulos]

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=jsom...@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

[Gervase Markham]

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

I've adopted this version, to solve the clear and present problem. If
constraints are also required on dirName (above and beyond the general
requirement that information in a cert must be accurate) then we can
consider that separately.

Gerv