Viktor Dukhovni <openssl-users <at> dukhovni.org> writes: > > On Tue, Apr 01, 2014 at 12:36:18PM -0400, Daniel Kahn Gillmor wrote: > > > I think the current best approach to this is the "public suffix > > list", http://publicsuffix.org/ it's a horrible kludge (a > > fully-enumerated list of all zones that are known to allow > > registration of sub-zones to the public), but it's better than just > > counting labels. > > > > there are a few C libraries that could be used to make this > > abstraction available to OpenSSL (if building against external > > libraries is OK) without requiring much extra work in OpenSSL > > itself. > > I, for one, would not want OpenSSL to employ such a complex and > fragile mechanism.
I, too, favor a KISS approach. A simple and self-contained algorithm to ensure RFC 6125 compliance can be the near-term goal. However, RFC 6125 makes a point of saying it only recommends client-side wildcard cert handling to accomodate existing infrastructure (i.e. backwards compat). So, a medium-term higher-order discussion can be on the sanity of continuing to support wildcards given the security implications, ambiguities in specifications, variability in client implementations, etc. Maybe that's a topic best suited for the uta wg. --mancha ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
