On 8 Jul 2021, at 7:12, Salz, Rich wrote: > I’d like to know what the WG thinks. As we’re not really using GitHub for > discussion, please comment on this list.
I made a comment on the pull request that is beyond editorial, so I’d like to bring that back to the list. Section 6.4.3 begins (essentially unchanged from RFC 6125): > A client employing this specification's rules MAY match the reference > identifier against a presented identifier whose DNS domain name portion > contains the wildcard character "*" I questioned the MAY in this sentence, because it seems to me that if recognizing wildcard certificates was entirely optional, then wildcards can’t be depended upon and are basically useless. Rich replied: > Clients must be free to ignore wildcards, because of things like > *.air-traffic-control.aero and others that are on the public suffix list. Does that then mean that there is an obligation on the part of certificate checkers to make sure that public suffixes aren’t wildcarded? I had expected that to be a responsibility of CAs to make sure that they don’t sign something inappropriate, besides the fact that the public suffix list isn’t officially maintained. Of course, certificate checkers are free to check the PSL to provide extra assurance if they want, but we shouldn’t create an expectation that they will do that. IMO we could change that from a MAY to a SHOULD. But any certificate that contains a SAN with a wildcarded public suffix should probably be considered completely invalid if a certificate checker is consulting the PSL. So if the SAN contains (*.com, www.example.org) it should be considered invalid for www.example.org as well, since it’s a malformed certificate. -Jim _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
