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.