On 2016-04-20 15:48, Ryan Sleevi wrote:
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)
RFC 6125 has:
6.4.3. Checking of Wildcard Certificates
[...]
3. The client MAY match a presented identifier in which the wildcard
character is not the only character of the label (e.g.,
baz*.example.net and *baz.example.net and b*z.example.net would
be taken to match baz1.example.net and foobaz.example.net and
buzz.example.net, respectively). However, the client SHOULD NOT
attempt to match a presented identifier where the wildcard
character is embedded within an A-label or U-label [IDNA-DEFS] of
an internationalized domain name [IDNA-PROTO].
So the RFC seems to allow it to me, but a client can obviously decide
not to do it.
Kurt
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
