On Tuesday, April 19, 2016 at 10:15:16 AM UTC-7, Nick Lamb wrote: > Some more thoughts (my previous substantive comments are awaiting moderation > because I foolishly sent them before subscribing) > > 1. Historically other CAs in this family have issued certificates which abuse > wildcards, like this: > > https://crt.sh/?id=16640133&opt=cablint > > Over the several years this request has been floating, no-one from Symantec / > Verisign mentioned these violations. Can we expect the same from the root > which is to be granted EV in this request? Or has Symantec since put in place > an effective control against this sort of wildcard abuse? If so, when?
[Not a Symantec representative, just a party who has argued such certificates violate the BRs] Symantec has, based on discussions in the CA/B Forum, argued that this restriction is ambiguous, and thus chosen to interpret the Baseline Requirements in the most permissive fashion possible, despite many other CAs reading it and taking the strict approach, which is also consistent with the material advice of RFC 6125, and of the practical implementation of Chrome and Firefox (which explicitly prohibit such certificates) You can see discussion in the thread starting https://cabforum.org/pipermail/public/2016-March/006933.html , including the response from Symantec at https://cabforum.org/pipermail/public/2016-March/006940.html You can see that Peter Bowen, of Amazon, attempted to clarify the BRs to match what browsers expect, in https://cabforum.org/pipermail/public/2016-March/007051.html . However, this proposed clarification was removed in https://cabforum.org/pipermail/public/2016-April/007170.html (the actual ballot). As Peter noted, this was due to objections on the call - objections raised by Rick Andrews of Symantec. These objections and the discussion were noted in https://cabforum.org/pipermail/public/2016-April/007322.html The contention here drives from the two mentions of wildcards within the BRs, and Symantec's explanation that they view it as ambiguous. From the Definitions (Section 1.6.1 of BRs v1.3.4): "A Certificate containing an asterisk (*) in the left‐most position of any of the Subject Fully‐Qualified Domain Names contained in the Certificate." Section 3.2.2.6 documents a procedure for what to do if a wildcard appears "in the first label immediately to the left of a registry-controlled or public suffix" The interpretation Symantec has argued is that the definition of wildcard certificates is "A certificate with a wildcard in the first label" (e.g. permitting this), while the definition that some (but not all) browsers have taken is that a wildcard certificate is in "the left-most position", where position means character. Further, the Section 7.1.4.2.1 of the BRs uses the term "Wildcard FQDNs", a term not defined in the BRs, and arguably at odds, since an FQDN cannot contain a wildcard (since an FQDN is a valid hostname, and * is not a valid host name). As such, it would seem that Symantec is arguing that "foo-*.whatever.example.com" is definitionly not a wildcard certificate (according to the browsers definition) but is a wildcard FQDN, and such are permitted. In either event, the only objection to clarifying this ambiguity in the Forum was raised by Symantec, and as such, a ballot to correct this confusion has remained stalled. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
