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
