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 <[email protected]> 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 <[email protected]> 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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
