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
