On Tue, Oct 22, 2019 at 6:31 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > I'm also not sure if I understand the wording correctly. Let's assume, an > > internal CA of company "mycompany" gets successfully validated for > > mycompany.example and receives a (possibly name constrained) certificate > > for its issuing CA from one of the root CAs. Can this internal CA issue > > certificates for every email address under @mycompany.example without > > further validation or is an internal validation process required? My > > opinion is, that such an internal validation process doesn't increase > > security, since mycompany controls the mailservers of mycompany and can > > anyhow validate everything. > > > > > Thanks Dimitris and Rufus. Would it satisfy your concern if the requirement > was changed to: > > The CA SHALL NOT delegate validation of the Base Domain Name (as defined in > the Baseline Requirements) portion of an email address. > I may be misunderstanding Rufus' concern, but it seemed slightly different? That is, taken in the whole of 2.2, the expectation is "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". If the CA has validated "mycompany.example", associated with account "mycompany", what is the expectation for 'localpart'? Interpretation 1) The CA MAY delegate validation of the localpart to 'mycompany'. However, 'mycompany' MUST take reasonable measure ... Interpretation 2) By validating 'mycompany' as to have control over 'mycompany.example', the CA has taken reasonable measure. No further validation requirements exist for the localpart, provided it is directed by the 'mycompany' account, as 'mycompany' is seen to implicitly have control over the MX records. I'm not sure Interpretation #2 fully holds (e.g. if the CA were using something like 3.2.2.4.6 or a non-DNS-based challenge), but I think it was trying to get at whether (CA || mycompany) needs to perform some validation step for 'localpart' once the validation for the domain part is done. As to Dimitris' case, I think you're spot on in understanding the problem. > Alternately, would this create an unacceptable loophole in the requirement > and if so, can you suggest a more secure alternative? My worry is that CAs will read this believing it permits more than intended. If the CA doesn't use "Base Domain Name" / "Authorization Domain Name", and only validates at the FQDN (i.e. the entire @domain), they may see this as being permitted to delegate. After all, they are not delegating validation of a Base Domain Name, they're delegating validation of an FQDN. """The CA SHALL NOT delegate validation of the domain portion of an email address. The CA MAY rely on validation the CA has performed for an Authorization Domain Name (as specified in the Baseline Requirements) as being valid for subdomains of that Authorization Domain Name.""" The point here is to make it explicit SHALL NOT. The following sentence does not conflict or limit that scope, but gives the CA limited additional permission to address the case Dimitris raised. The choice of "Authorization Domain Name" versus "Base Domain Name" is that a given FQDN may have multiple "Base Domain Names", due to how the Public Suffix List works. The Authorization Domain Name process was designed to find the most specific Base Domain Name, by pruning labels left-to-right. Rather than recreate that algorithm, I reused it here. The downside is that such a definition picks up CNAME chasing, which (similar to the remarks to Rufus), can be distinct from MX validation in some situations. However, it's a trade-off, and seems strictly improved over the status quo, and regardless, the documentation requirement that 2.2 places would cover those situations (hopefully). _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
