On Mon, Nov 27, 2017 at 8:29 PM, Jakob Bohm via dev-security-policy < [email protected]> wrote:
> On 27/11/2017 19:37, Nick Lamb wrote: > >> On Fri, 24 Nov 2017 12:25:40 +0000 >> Gervase Markham via dev-security-policy >> <[email protected]> wrote: >> >> Validate example.com -> add "www.example.com": seems fine to me, and a >>> reasonable accommodation to a common customer desire. >>> >>> Validate www.example.com -> add "example.com": not at all fine. >>> >>> Validate *.example.com -> add "example.com": still dodgy IMO. >>> >> >> >> All of these can be a problem, and I would like us to have as the end >> goal forbidding all these practices, but I recognise that it's >> unrealistic to achieve that in the short term. >> >> The thing is, extraneous names on a certificate present a subtle >> security flaw, even if control over those names was validated properly >> >> Extraneous names can appear in a CSR as a result of the applicant >> making a bad security choice. But that's not our domain here, bad >> choices by Relying Parties or Applicants are their problem. Bad choices >> by the CAs can harm everybody and we should be trying to move things in >> the right direction on that front. >> >> > The inclusion of example.com with *.example.com is a long standing > standard practice based on the fact that most subscribers don't realize > that *.example.com doesn't already cover example.com. The validations > needed for *.example.com are a full superset of those needed for > example.com, with the sole exception that the formal wording of the CAA > specification allows a domain to set up CAA records that allow > *.example.com but prohibit example.com. One could reasonably discuss if > this is a bug in the CAA specification, but until then, CAs are formally > required to check for the scenario and reject the application. > > The inclusion of example.com with www.example.com is a tradition, but it > would be good if CAs allowed applicants to deselect it in the rare cases > where they don't intend to use it. > > While your scenario below sounds compelling, it is very much a contrived > scenario of the type usually used to trick organizations into making bad > policy decisions. > > Due to the cost of publicly trusted certificates, many organizations > could, in the same scenario, obtain just the *.example.com + example.com > certificate and install it on both servers. Hi Jakob, Please note the discussion is not about whether it's problematic to include both, but how you validate. I don't believe anyone has suggested it's not OK to include both, merely to ensure that the validation performed is appropriate for both. It's absolutely intentional that CAA can allow *.example.com and disallow example.com. This is not something "One could reasonably discuss if this is a bug", because it's an explicit intentional design choice documented within the RFC. This isn't even subtle - it's called out. It's not about being a 'contrived scenario' either - it's about ensuring the appropriate level of validation. As to your remarks about cost, I think that's about an argument about a decade out of date, nor particularly germane to the level of security we should expect from the CA ecosystem. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
