On Tue, Oct 22, 2019 at 4:23 PM Ryan Sleevi <r...@sleevi.com> wrote: > > 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. > > The "new" (it was already a Forbidden Practice) restriction on delegating domain validation doesn't change the language that applies here, which is that "...the CA takes reasonable measures..." and that "The CA's CP/CPS must clearly specify the procedure(s)...". Until there are BRs for S/MIME, CAs must define and document their email validation practices.
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.""" > > This is much better, thanks. The proposed change is: https://github.com/mozilla/pkipolicy/commit/0a63f457c059365103e48ad3eb409cd376903e51 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
