Peter Saint-Andre wrote: > > Jeff and I have been thinking about this independently today, and it > seems we're going in the same direction. Following Martin Rex's argument > to its logical conclusion has led me to believe that wildcards deserve > to be NOT RECOMMENDED in a best current practice document.
I'm certainly in favor of NOT RECOMMENDING the use of any wildcards to server admins (and to a lesser extent app protocol designers) in the security considerations section of the server-id-check document. I'm less inclined about recommending to implementations to not implement it at all (which is about utility functions of the TLS implementation for use by the application). Aside from pathological cases (like a DV-validated cert issued with DNS-ID="*", "*.*", "*.*.*" and extremely "liberal" TLS-client-implementations of rfc-2818), the risk about wildcard certs is more about the administrative procedures of the server & domain admins using such certs. Keep in mind that the security of all the servers in the domain vitally depend on responsible admins and reasonably safe procedures, and the matching rules described in server-id-check are hardly going to affect that. The other extreme, of server certificates that list several hundred DNS-IDs is not necessarily safer than a single wildcard. Rather than leaving the issue of wildcards as underspecified as rfc-2818, I would appreciate a few words of what is commonly available in current web browsers and could be implemented with minor effort and low complexity. -Martin _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
