I'm reading through the mailing list threads and working to identity the
remaining open issues. Jeff and I might post additional, focused
requests for feedback in the near future, so stay tuned. However, I
think that our working copy addresses nearly all the feedback that's
been posted during and after the IETF Last Call, so we plan to publish a
revised I-D as soon as possible.
This message covers the open issue of wildcard matching, specifically
matching of component fragments (e.g., foo*.example.com).
RFC 2818 states:
Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., *.a.com matches foo.a.com but
not bar.foo.a.com. f*.com matches foo.com but not bar.com.
Version -01 of draft-saintandre-tls-server-id-check (August 31, 2009)
had this text:
A dNSName MAY contain the wildcard character '*' (ASCII 42). The
wildcard character applies only to the left-most (least significant)
domain name component or component fragment and matches any single
component or component fragment. For instance, a dNSName of
*.example.com matches foo.example.com but not bar.foo.example.com or
example.com itself; similarly, a dNSName of baz*.example.net matches
baz1.example.net and baz2.example.net but not qux.example.net or
example.net itself.
Version -02 of draft-saintandre-tls-server-id-check (October 2, 2009)
had this modified text:
Unless otherwise specified by an application protocol, the dNSName
MAY contain one instance of the wildcard character '*'. The wildcard
character applies only to the left-most domain name component and
matches any single component (thus a dNSName of *.example.com matches
foo.example.com but not bar.foo.example.com or example.com itself).
The wildcard character is not allowed in component fragments (thus a
dNSName of baz*.example.net is not allowed and shall not be taken to
match baz1.example.net and baz2.example.net).
And version -09 has similar text:
A client employing this specification's rules MAY match the reference
identifier against a presented identifier containing one instance of
the wildcard character '*', but only as the left-most label of the
domain name, e.g. *.example.com (following the definition of "label"
from [DNS]).
If such a wildcard identifier is presented, the wildcard MUST be used
to match only the one position-wise corresponding label (thus
*.example.com matches foo.example.com but not bar.foo.example.com or
example.com). The client MUST fail to match a presented identifier
in which the wildcard character is contained within a label fragment
(e.g., baz*.example.net is not allowed and MUST NOT be taken to match
baz1.example.net and baz2.example.net), or in which the wildcard
character does not comprise the left-most label in the presented
identifier (e.g., neither bar.*.example.net nor bar.f*o.example.net
are allowed).
If I recall correctly, I added that the rule against matching of
component fragments in response to feedback from Alexey Melnikov, who
was reporting on discussion within the IESG, perhaps regarding
draft-ietf-sip-domain-certs (now RFC 5922), which states:
###
Implementations MUST NOT match any form of wildcard, such as a
leading "." or "*." with any other DNS label or sequence of
labels. For example, "*.example.com" matches only
"*.example.com" but not "foo.example.com". Similarly,
".example.com" matches only ".example.com", and does not match
"foo.example.com".
RFC 2818 [7] (HTTP over TLS) allows the dNSName component to
contain a wildcard; e.g., "DNS:*.example.com". RFC 5280
[6], while not disallowing this explicitly, leaves the
interpretation of wildcards to the individual specification.
RFC 3261 [2] does not provide any guidelines on the presence
of wildcards in certificates. Through the rule above, this
document prohibits such wildcards in certificates for SIP
domains.
###
On the topic of wildcard matching, Martin Rex posted as follows on
September 16...
<http://www.ietf.org/mail-archive/web/certid/current/msg00337.html>
###
(e.g., baz*.example.net is not allowed and MUST NOT be taken to match
baz1.example.net and baz2.example.net)
This is in clear contradiction to the wildcard matching specified
in rfc-2818 Section 3.1. And without any rationale for this U-Turn,
that seems to be entirely inappropriate for a BCP.
In my implementation of RFC-2818 wildcard matching, I deliberately
ignore DNS names that contain more than one wildcard character,
have a wildcard character in different but the leftmost label
or have a wildcard character and less than 3 DNS labels.
But I certainly do the substring match specified in rfc-2818
and I'm not going to remove the substring match from my
implementation without a convincing rationale...
What exactly is the benefit of allowing a full wildcard match but
prohibiting a partial/substring wildcard match of the leftmost label?
###
Martin Rex also posted as follows in that same thread:
<http://www.ietf.org/mail-archive/web/certid/current/msg00345.html>
###
Partial wildcard match will allow you to use one single server cert
for a server farm behind a load-balancing NAT with hostnames such as
"www1.example.com", "www2.example.com", ... "wwwNN.,example.com"
by using the pattern "www*.example.com" that will neither match
"kdc.example.com", "ldap.example.com", nor "imap.example.com"
To me, that seems significantly more useful than only a full
wildcard match. The current draft could be read to mean (without a
single word of rationale) that partial wildcard matching is so much more
dangerous than full wildcard matching that MUST NOT be used by anyone
anymore. If this is not removed from the draft, this will result in a
completely inconsistent behaviour within the installed based causing
headaches with no ends to end-users, admins and helpdesks--for those
servers that actively use this sensible alternative to full wildcard
certs as specified in rfc-2818.
###
What is the sense of this list regarding wildcard matching on component
fragments? Martin has made his arguments so I'm especially interested in
feedback from other folks.
Thanks!
Peter
--
Peter Saint-Andre
https://stpeter.im/
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
