Jim Fenton <fen...@bluepopcorn.net> wrote: > 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. >
I agree. Consider an implementation/deployment that cannot maintain a frequently-updated copy of the PSL. It might instead rely on different mechanisms to enforce that bad wildcards aren't issued. For example, it may enforce Certificate Transparency and some kind of revocation (perhaps OCSP stapling) and then as part of its CA policy, it might force CAs that issue bad wildcard certificates to revoke those. Also the PSL has different classifications of entries. There are some that are high-risk and most-likely never going to change, like *.com. So it might enforce part of the PSL in code but rely on policy mechanisms like CT + revocation to handle the rest. We should decide whether rejecting bad wildcards like *.com is actually relevant for RFC 6125. Logically, before RFC 6125 becomes relevant in certificate validation, the certificate should be otherwise "valid." An implementation would parse a certificate and apply name constraints and do other validation prior to doing any steps regarding RFC 6125. I would expect a certificate with an invalid wildcard like *.com would be rejected as part of that earlier validation. If an implementation doesn't want to support wildcards at all then it can/should reject the certificate during that earlier processing. If it wants to check against the PSL then it should do so during that earlier processing. If we get to the part of validation where RFC 6125 is relevant then we already know the wildcard dNSName subjectAltName entry is valid. Given that, RFC 6125 just needs to specify how to match, syntactically, a wildcard against a reference identifier. (I think this is compatible with what Ryan Sleevi wrote in this thread.) Cheers, Brian
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
