On 7/8/21 1:41 PM, Viktor Dukhovni wrote: > On Thu, Jul 08, 2021 at 02:12:51PM +0000, Salz, Rich wrote: > >> A discussion started on the GitHub repo >> https://github.com/richsalz/draft-ietf-uta-rfc6125bis about what is >> allowed for the wildcard character, such as in DNS entries in >> subjectAltName. I am about to publish a new draft which takes the old >> adopted “diff” version and does a full version of 6125. The current >> draft says that a wildcard may be the first, or only, character in the >> left-most DNS name. >> >> Brian Smith and Ryan Sleevi started a discussion on the PR >> https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/1#discussion_r663206174 >> recommending that the doc should be the *only* character. For >> example, *.apps.example.com is okay, but *apps.example.com is not. >> >> I’d like to know what the WG thinks. As we’re not really using GitHub >> for discussion, please comment on this list. > > If (and presumably givent that) support for wildcard names is to > continue to exist, the syntax should be as narrow as possible. So > "only" would be the best choice. > > That said, it'be really super if various applications profiles decided > to do away with wildcard certificates entirely. Their $$$ cost > advantage is long gone, and otherwise they just damage security by > enabling cross application protocol attacks, and damage availability by > encouraging simultaneous updates of certificates across independent > service endpoints (e.g. multiple MX hosts sharing a wildcard cert). > > So the sooner we can get rid of wildcard certificates entirely, the > better. They've outlived their usefulness.
Jeff Hodges and I had hoped to push for deprecating wildcard certs when working on RFC 6125 10+ years ago, but the world wasn't ready for it then. Are we ready now? What would be the impact (postive and negative) of deprecating them? Peter _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
