On Fri, Jul 9, 2021 at 3:03 PM Tony Finch <d...@dotat.at> wrote: > My understanding is that PKIX wildcard matching originally used glob(3), > (with . as the separator instead of /) which is both more relaxed and more > restricted than DNS wildcards. >
I'm not aware of any implementations with that semantics. At the time of RFC 2818, the primary implementations (Netscape and Microsoft) had slightly different implementations, and SSLeay did not provide any form of name matching. Netscape's implementation used their regular expression engine rather than glob(3), which... was spectacularly unfortunate [1]. Microsoft, and later, Apple (both since fixed), used equivalents of strchr() to implement wildcard matching. I realize this is mostly pedantry, but trying to make sure this useful knowledge is archived somewhere, and because it does affect some of the conclusions re: comparisons to DNS semantics :) [1] https://www.mozilla.org/en-US/security/advisories/mfsa2009-43/ > So any description of wildcards should (still) emphasize that even though > PKIX and DNS wildcards (now) have the same syntax, they still don't have > the same semantics. > Are you suggesting that it should continue to emphasize that it only matches a single domain label, or a more explicit comparison to the DNS semantics? If the latter, are you thinking by incorporating and referencing RFC 4592 [2]? Is there text to propose, given that RFC 4592 largely monkey patches RFC 1034, rather than reads as an algorithm to itself? [2] https://datatracker.ietf.org/doc/html/rfc4592#section-2.1.1
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
