Subject: [Uta] Wildcards

From: "Salz, Rich" <[email-masked]>
Date: Thu, 8 Jul 2021 14:12:51 +0000

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.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 8 Jul 2021 16:02:22 +0100

Hi Rich,

On 08/07/2021 15:12, Salz, Rich wrote:
>
> A discussion started on the GitHub repo 
> https://github.com/richsalz/draft-ietf-uta-rfc6125bis 
> <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 
> <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.
>
I think only "*.apps.example.com" was intended, so I am in favour of 
this change.

Best Regards,

Alexey

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 8 Jul 2021 10:17:33 -0600

> I think only "*.apps.example.com" was intended, so I am in favour of

When we published RFC 6125 (see §6.4.3), we weren't able to get that
far, but I agree that this would be best.

Peter

---

From: Jim Fenton <[email-masked]>
Date: Thu, 08 Jul 2021 09:31:05 -0700

> 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* characte…

I would expect subjectAltName to have the same constraints as DNS entries have, which only allow wildcards for full labels, so I support only allowing *.apps.example.com.

-Jim

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 8 Jul 2021 17:06:01 +0000

In anticipation of consensus around "only * as the left-most label," I created a PR; https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/9

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 8 Jul 2021 15:41:00 -0400

On Thu, Jul 08, 2021 at 02:12:51PM +0000, Salz, Rich wrote:

> https://github.com/richsalz/draft-ietf-uta-rfc6125bis about what is
> recommending that the doc should be the *only* character.  For

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.

-- 
    Viktor.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 8 Jul 2021 13:52:42 -0600

> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 8 Jul 2021 17:47:10 -0400

> then. Are we ready now? What would be the impact (postive and negative)

Not surprisingly, I'd like to see that happen, but I don't know how we'd
get the users on board.  The reasons to drop support are all technical,
but users tend to go for convenience, even when both less secure and
less reliable.

Can "the industry" (CAs, software vendors, ...) unite behind getting the
users to accept the right, but arguably less convenient, tradeoff?

With cert lifecycles increasingly automated and short-term, and manual
processes going away, this feels like almost the right time to try to
make the case, but it is likely still difficult.

-- 
    Viktor.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 8 Jul 2021 18:52:15 -0400

> users to accept the right, but arguably less convenient, tradeoff?

No. I think deprecating wildcards would be a bad outcome for users and for
server operators.

While I agree there are legitimate concerns about wildcards, I would not be
supportive of trying to remove them, which was the same position shared
years ago. The concerns being highlighted are things that I would prefer to
be better addressed via ALPN and SRVNames, the former which can (and is)
deployed today, the latter of which suffers from a number of (tractable)
issues [1]. The discussions many years ago centered around wildcards
focused fairly heavily on "DNS used for phishing", which is an important
problem, but certificates are not the right layer for that. For those
wanting to argue against wildcards, I think it would be beneficial to more
clearly articulate the risks; not because I disagree that there are risks,
but because the discussion benefits from a shared understanding.

While not disagreeing there are legitimate concerns, there are also very
legitimate cases that play an important role in some protocols, most
notably, HTTPS and browsers. The security principal of the Web is through
the notion of the Origin (RFC 6454, although supplanted/replaced in
implementations by https://fetch.spec.whatwg.org/#origin-header ).
Concisely, "scheme, host, port" make up the boundary for much of the Web
security model.

If you're developing a complex application on the Web, you inevitably need
different isolation boundaries for different elements: for example,
user-generated content may have a distinct origin and sandbox policy
applied to it versus developer-generated content. Or you may have disparate
teams working on the same logical application, and need ways to isolate
different content from interfering. Since schemes are few, and ports are,
for better or worse, a lost cause due to Enterprise firewalls, your only
option is through different hosts. Different hosts, even subdomains,
reflect different origins.

Thus, it's not uncommon for many websites to have many subdomains, all
fronted by the same logical server, whose sole purpose is not to provide
transport-level isolation, but rather logical separation at the Web
application boundary. Wildcards make that deployable at a scale that
subjectAltNames or distinct certificates are simply not.

Or, consider hosting websites, whether it be "github.io" - where many IETF
WGs host their own content, under distinct origins, all fronted by the same
service and certificate. There is no legitimate technical reason to require
those different hosts have different certificates; they fit within the same
operational and security threat boundary, nor would having millions of SANs
be in any way beneficial to users or the evolution of protocols such as
QUIC, which are rightfully cautious about the size of certificates.

Although those are examples of single-developer and multi-developer model,
it also benefits users. Consider solutions like Plex's home streaming,
which was the first (to my knowledge) provider in the space to fully
encrypt all of their user streaming. If you're not familiar with Plex [2],
a user sets up a media server on one of their devices, and can stream to
their other devices: whether on the same local network or via anywhere on
the Internet. Plex achieved this through a rather innovative DNS naming
scheme and the use of wildcards, which work around limitations with the
deployed reality of consumer networking equipment. In short, each user is
given a (single) wildcard certificate, which is valid for all names in the
form "*.[user-identifier].plex.tv". When they want to stream, whether on
LAN or remotely, Plex can offer names of the form
"192-168-0-1.[user-identifier].plex.tv" to resolve to 192.168.0.1 (for
example). This is an alternative to IP certificates, offers unique per-user
binding, and works for both local IPs and remote IPs, ensuring full HTTPS,
and working around issues with users' networking equipment (as best they
can). A non-wildcard certificate would require on-demand minting of
certificates regularly, for questionable benefits. Since Plex started doing
this, a number of other providers of IoT and IoT-like devices have adopted
similar solutions, including Western Digital.

I agree, it's concerning that "mail.example.com" can share a certificate
with "www.example.com", but that's no less true with wildcards than it is
with subjectAltNames. The solution for those cross-protocol considerations
is not to forbid wildcards, which does nothing to address the problem, but
to use SRVNames more widely in implementations, along with wider deployment
of ALPN to reduce cross-protocol / cross-boundary confusions.

[1] There are several reasons that SRVNames are not widely supported in
client software, and in particular, web browsers. Some of these are issues
that the IETF can tackle, and it's merely been a matter of resourcing and
prioritization between responding to CA incidents and more critical
priorities, versus the ability to do proactive improvements.

1. The specification (RFC 4985) is under-specified in key security critical
aspects, namely, how to express that "You cannot issue SRVNames at all"
(i.e. nameConstraints). RFC 5280 suffers some of this, with respect to URI
nameConstraints using a different syntax for subdomains than DNS
nameConstraints, but SRVNames fit in the uncanny valley where the language
is ambiguous as to whether the proper expression for "no issuance" is a
zero-length field (like DNS name constraints) or a single "." (like URI
name constraints).

2. The specification of nameConstraints (RFC 5280) itself makes it
dangerous to introduce new name types, because all existing nameConstrained
CAs will automatically be able to issue certificates using the new name
type, even if it's synonymous to an existing constraint. Concretely, if a
DNS nameConstraint exists restricting a CA to "foo.example", clients
supporting SRVNames would rightfully allow that CA to issue certificates
for any arbitrary service on "bar.example", because SRVNames are not
constrained. Put differently, nameConstraints are "default allow" (if
unspecified), rather than "default deny", a decision that is security
relevant.

Both of these are tractable problems, but by no means trivial to solve.
However, combined, they're why client implementations have not yet
introduced support for SRVNames: not wanting to allow otherwise constrained
CAs today to issue names they're not authorized for. This is the very
problem that began this work (commonName interaction with nameConstraints,
which is unspecified as well), and while I'd be very supportive of efforts
to resolve it, they're not something I have the bandwidth to draft drafts
for.

[2] https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/

---

From: "John Levine" <[email-masked]>
Date: 9 Jul 2021 00:54:09 -0400

It appears that Viktor Dukhovni  <[email-masked]> said:
>enabling cross application protocol attacks, ...

Sometimes yes, sometimes no.  Sometimes wildcard covers a handful of 
separate web sites, which is not great, but sometimes it covers
a group of closely related sites for which there is no other reasonable
way to handle the cert.

This one is mostly a joke to stress-test web spiders (it caused a lot
of excitement in Redmond WA) but there are plenty of real sites along
the same lines:

https://wild.web.sp.am

R's,
John

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 9 Jul 2021 13:19:39 +0000

I agree with the reasoning, but I think you have to deprecate before removal and therefore not in this draft.

We could update the security concerns and say MAY NOT about issuance perhaps. The text already says clients MAY use them.

They're still allowed in the WebPKI, and I am unsure of non-web uses.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 9 Jul 2021 11:50:54 -0400

On Thu, Jul 08, 2021 at 06:52:15PM -0400, Ryan Sleevi wrote:

> be better addressed via ALPN and SRVNames, [...]

Yes, there are some use-cases in which wildcards are used correctly, and
many where they are carelessly misused.  Perhaps it may suffice to more
strongly discourage such misuse.

For example, wildcards would be needed for Microsoft to support MTA-STS
for the various domains that are MX-hosted by *.mail.protection.outlook.com.

    nist.gov. IN MX 0 nist-gov.mail.protection.outlook.com.
    microsoft.com. IN MX 10 microsoft-com.mail.protection.outlook.com.
    ... a few hundred thousand more ...

These are spread over various data-centres, but just one wildcard cert
covers them all.  The customer-specific prefix makes it possible to bias
particular customers to particular sites, or move them as needed.

-- 
    Viktor.

---

From: Tony Finch <[email-masked]>
Date: Fri, 9 Jul 2021 20:02:44 +0100

Jim Fenton <[email-masked]> wrote:
>
> I would expect subjectAltName to have the same constraints as DNS
> entries have, which only allow wildcards for full labels, so I support
> only allowing *.apps.example.com.

Well, it's more complicated than that, because it isn't feasible to get
certificate wildcards to have the same semantics as DNS wildcards.

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.

It's more relaxed because glob() allows wildcards to appear anywhere. For
PKIX, the allowed position of wildcards has been gradually restricted over
time. This discussion is about restricting wildcards to just "*." at the
start of the name, like DNS wildcards.

The complication comes from how matching is done, which is more restricted
in PKIX than in the DNS. In the DNS, a wildcard matches any number of
labels at the start of the name. In glob() and in PKIX, the wildcard can
only match one label.

I don't think it is feasible or desirable to make PKIX wildcards match
multiple labels like DNS wildcards do.

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.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
Trafalgar: Mainly northerly 5 to 7, but easterly or northeasterly 6 to
gale 8 in far southeast, perhaps severe gale 9 later in far southeast.
Moderate or rough. Fair. Good.

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 9 Jul 2021 16:18:01 -0400

> 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/

> PKIX and DNS wildcards (now) have the same syntax, they still don't have

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

---

From: Tony Finch <[email-masked]>
Date: Fri, 9 Jul 2021 22:42:55 +0100

Ryan Sleevi <[email-masked]> wrote:
> I'm not aware of any implementations with that semantics.

To be honest, that's a vague memory from about 1998 :-) and I think I'm
remembering some clone-and-ack code rather than calls to literal glob(3)
because glob() wasn't very portable.

> RFC 4592 [2]?

I think the latter would be most helpful. I'm not sure if the text should
go in section 6.4.3 (spec) or 7.2 (security considerations), but it should
say something like:

: A wildcard in a presented identifier can only match exactly one label in
: a reference identifier. Note that this is not the same as DNS wildcard
: matching, where the "*" label always matches at least one whole
: label and sometimes more. See [RFC 1034] section 4.3.3 and [RFC 4592].

(quoting part of a sentence from RFC 1034 - and these references should be
informative)

And while I was looking at how this might fit into the draft, I spotted a
mistake in section 7.2. This sentence:

: Wildcard certificates automatically vouch for any and all host names
: within their domain.

should say something like:

: Wildcard certificates automatically vouch for any single-label host
: names within their domain, but not within subdomains.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
St Davids Head to Great Orme Head, including St Georges Channel:
Variable, mainly southeast, 2 to 4. Smooth or slight, occasionally
moderate later near st david's head. Showers. Good.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 10 Jul 2021 21:44:19 +0000

I am adding the following commit to https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/9 which I will merge if/when we have consensus.
Let me know if this is not ok.

MAC ~/git/draft-ietf-uta-rfc6125bis$ g l1
commit d4dcbd397e1342c634f3ab19eb4bc52b4b7ef5e8 (HEAD -> simpler-wildcard)
Author: Rich Salz <[email-masked]>
Date:   Sat Jul 10 17:39:57 2021 -0400

    Clarify wildcard/DNS-wildcard differences
    
    Per the email discussion. Thanks Tony, Ryan, and Jim.
---
 draft-ietf-uta-rfc6125bis.md | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/draft-ietf-uta-rfc6125bis.md b/draft-ietf-uta-rfc6125bis.md
index a1aa0ee..71f305d 100644
--- a/draft-ietf-uta-rfc6125bis.md
+++ b/draft-ietf-uta-rfc6125bis.md
@@ -38,6 +38,7 @@ author:
 normative:
   DNS-CONCEPTS: RFC1034
   DNS-SRV: RFC2782
+  DNS-WILDCARDS: RFC4592
   IDNA-DEFS: RFC5890
   IDNA-PROTO: RFC5891
   LDAP-DN: RFC4514
@@ -1081,7 +1082,7 @@ The rules differ depending on whether the domain to be checked is a
 defined under {{names-dns}}).
 Furthermore, to meet the needs of clients that support presented
 identifiers containing the wildcard character `*`, we define a
-supplemental rule for so-called "wildcard certificates".
+supplemental rule for such "wildcard certificates".
 
 ### Checking of Traditional Domain Names {#verify-domain-trad}
 
@@ -1125,6 +1126,12 @@ provided these requirements are met:
 3. The wildcard character is not embedded in an A-label or U-label
    {{IDNA-DEFS}} of an internationalized domain name {{IDNA-PROTO}}.
 
+A wildcard in a presented identifier can only match exactly one label in
+a reference identifier. Note that this is not the same as DNS wildcard
+matching, where the `*` label always matches at least one whole
+label and sometimes more. See {{DNS-CONCEPTS, Section 4.3.3}}
+and {{DNS-WILDCARDS}}.
+
 For information regarding the security characteristics of wildcard certificates,
 see {{security-wildcards}}.
 
@@ -1246,8 +1253,9 @@ relevant information provided by the user or associated by the client).
 
 Wildcard certificates, those that have an identifier with
`*` as the left-most DNS label,
-automatically vouch for any and all host names
-within their domain. This can be convenient for administrators but
+automatically vouch for any single-label host names
+within their domain, but not multiple levels.
+This can be convenient for administrators but
 also poses the risk of vouching for rogue or buggy hosts. See for
 example {{Defeating-SSL}} (beginning at slide 91) and {{HTTPSbytes}}
 (slides 38-40).

---

From: Tony Finch <[email-masked]>
Date: Sun, 11 Jul 2021 19:05:19 +0100

> Let me know if this is not ok.

lgtm, thanks!

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
Hebrides: Northeast 3 to 5. Moderate, occasionally slight in east.
Showers, fog patches. Moderate or good, occasionally very poor.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 12 Jul 2021 10:00:48 +1000

> +label and sometimes more. See {{DNS-CONCEPTS, Section 4.3.3}}

The language in RFC 2818 is narrower than this.  It allows '*' to match only the first label.

(Note that `*` will be rendered in text as "*" and HTML as a bare * in fixed-width font, which might not be visible.  Consider using explicit quotes: "*" instead.  I have an open ticket on xml2rfc about this point: https://trac.ietf.org/trac/xml2rfc/ticket/647 though that has spawned an interesting email chain.)

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Jul 2021 13:59:45 +0000

>    The language in RFC 2818 is narrower than this.  It allows '*' to match only the first label.

I don't think that makes the above text incorrect, since this draft says "only the first label"

>    (Note that `*` will be rendered in text as "*" and HTML as a bare * in fixed-width font, which might not be visible

I changed to use explicit quotes "\*"  Thanks.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 12 Jul 2021 11:06:50 -0700

> I’d like to know what the WG thinks.  As we’re not really using GitHub for discussion, please comment on this list.

I made a comment on the pull request that is beyond editorial, so I’d like to bring that back to the list.

Section 6.4.3 begins (essentially unchanged from RFC 6125):

> A client employing this specification's rules MAY match the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character "*"

I questioned the MAY in this sentence, because it seems to me that if recognizing wildcard certificates was entirely optional, then wildcards can’t be depended upon and are basically useless.

Rich replied:

> Clients must be free to ignore wildcards, because of things like *.air-traffic-control.aero and others that are on the public suffix list.

Does that then mean that there is an obligation on the part of certificate checkers to make sure that public suffixes aren’t wildcarded? I had expected that to be a responsibility of CAs to make sure that they don’t sign something inappropriate, besides the fact that the public suffix list isn’t officially maintained. Of course, certificate checkers are free to check the PSL to provide extra assurance if they want, but we shouldn’t create an expectation that they will do that. IMO we could change that from a MAY to a SHOULD.

But any certificate that contains a SAN with a wildcarded public suffix should probably be considered completely invalid if a certificate checker is consulting the PSL. So if the SAN contains (*.com, www.example.org) it should be considered invalid for www.example.org as well, since it’s a malformed certificate.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 12 Jul 2021 14:18:01 -0400

> On 12 Jul 2021, at 2:06 pm, Jim Fenton <[email-masked]> wrote:
> 

Indeed "MAY" is correct.  Clients are free to not support wildcards,
just as they're free to refuse to recognise certificates for particular
domains, or issued by particular CAs, or expiring too far in the future, ...

Support for wildcards in RFC 6125 is application-protocol specific, see
Appedix B.

Web browsers should expect to encounter and support wildcards.  Other
applications, or isolated networks, ... MAY choose to not support them.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Jul 2021 18:22:32 +0000

Appedix B.

Well, I want to make 6125bis be a Standard, not a best practices, so Appendix B is gone from my draft :)

But yes, I still want wildcards to be a MAY.  Perhaps a SHOULD.

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 12 Jul 2021 14:44:56 -0400

> But any certificate that contains a SAN with a wildcarded public suffix should probably be considered completely invalid if a certificate checker is consulting the PSL. So if the SAN contains (*.co…

So this is messy, for a few reasons:

* The PSL has an element of temporal skew to it (names come and go),
with clients only maintaining a singular copy. Certificates have
validity periods, but the validity period may overlap with the
contents of the PSL at the time, but not overlap with the contents of
the PSL as perceived by the client during that validity period.
* The PSL is not one-size-fits all. It primarily covers use cases
related to (Web) browser security, although it has been co-opted for
other purposes outside of that. However, it means entities that are
legitimate to have wildcards, and are legitimate to issue to, can
appear on the PSL. Earlier in the thread, I mentioned github.io as an
example of this, or the similar appspot.com. While the PSL's format
uses some distinction between these (the so called "ICANN" vs
"PRIVATE" sections), that's hardly representative of the various use
cases. This is further made messy by the types of gTLDs that can
exist, as reflected in the reference in the BRs to ICANN Specification
13.
* The distinction between "invalid syntax" and "invalid semantics".
We've consistently seen that the latter is significantly less likely /
more difficult for RPs to implement. The classic example of this was
perhaps how RFC 5280 defined the DNS-ID in terms of preferred name
syntax (LDH rule), while virtually every client simply treated it as
case-insensitive ASCII, allowing for a variety of invalid characters
(e.g. "_") to proliferate and gain usage.

The proposed handling (fail fast) that you're describing seems to fit
similar to the nameConstraints processing algorithm: where the
presence of an excluded name type causes a certificate chain to be
rejected (RFC 5280, Section 6.1.3, Item c). However, in practice,
client implementations that impose restrictions on wildcards (e.g. to
the ICANN section of the PSL) tend to apply it similar to the
processing of policy OIDs: that is, they process the DNS-ID in the
context of the name being validated against, rather than during
certificate parsing. With such a model, a SAN containing {*.com,
www.example.org} is valid for "www.example.org", but not valid for
"example.com"

Whether or not it's appropriate for certificate checkers, in some
degree, depends on your threat model with respect to the CAs issuing
these certificates. In the context of the Web PKI set of CAs complying
to browser requirements, there's a healthy amount of suspicion with
respect to CAs, because technical controls can and do fail. Recall
that during DigiNotar's incident, we saw such *.com and *.*.com
certificates being issued. So browser clients tend to implement this
as a line of defense against CA compromise or malfeasance, while also
having to balance the risk to interoperability and their users if they
fail to maintain regular updates (e.g. for modifications to the PSL).

So while I agree with you on not creating the obligation on
certificate checkers (that is, that this is primarily an issuance
policy), I disagree on the "fast fail" side, because there's greater
operational risk compared to the "when used" scenario.

---

From: Brian Smith <[email-masked]>
Date: Mon, 12 Jul 2021 13:19:38 -0700

Jim Fenton <[email-masked]> wrote:

> Rich replied:
>
> > Clients must be free to ignore wildcards, because of things like *.
> air-traffic-control.aero and others that are on the public suffix list.
>
> Does that then mean that there is an obligation on the part of certificate
> checkers to make sure that public suffixes aren’t wildcarded? I had
> expected that to be a responsibility of CAs to make sure that they don’t
> sign something inappropriate, besides the fact that the public suffix list
> isn’t officially maintained. Of course, certificate checkers are free to
> check the PSL to provide extra assurance if they want, but we shouldn’t
> create an expectation that they will do that. IMO we could change that from
> a MAY to a SHOULD.
>
> But any certificate that contains a SAN with a wildcarded public suffix
> should probably be considered completely invalid if a certificate checker
> is consulting the PSL. So if the SAN contains (*.com, www.example.org) it
> should be considered invalid for www.example.org as well, since it’s a
> malformed certificate.
>

I agree.

Consider an implementation/deployment that cannot maintain a
frequently-updated copy of the PSL. It might instead rely on different
mechanisms to enforce that bad wildcards aren't issued. For example, it may
enforce Certificate Transparency and some kind of revocation (perhaps OCSP
stapling) and then as part of its CA policy, it might force CAs that issue
bad wildcard certificates to revoke those. Also the PSL has different
classifications of entries. There are some that are high-risk and
most-likely never going to change, like *.com. So it might enforce part of
the PSL in code but rely on policy mechanisms like CT + revocation to
handle the rest.

We should decide whether rejecting bad wildcards like *.com is actually
relevant for RFC 6125. Logically, before RFC 6125 becomes relevant in
certificate validation, the certificate should be otherwise "valid." An
implementation would parse a certificate and apply name constraints and do
other validation prior to doing any steps regarding RFC 6125. I would
expect a certificate with an invalid wildcard like *.com would be rejected
as part of that earlier validation. If an implementation doesn't want to
support wildcards at all then it can/should reject the certificate during
that earlier processing. If it wants to check against the PSL then it
should do so during that earlier processing. If we get to the part of
validation where RFC 6125 is relevant then we already know the wildcard
dNSName subjectAltName entry is valid. Given that, RFC 6125 just needs to
specify how to match, syntactically, a wildcard against a reference
identifier. (I think this is compatible with what Ryan Sleevi wrote in this
thread.)

Cheers,
Brian

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 12 Jul 2021 16:40:50 -0400

On Mon, Jul 12, 2021 at 4:20 PM Brian Smith <[email-masked]> wrote:
> If we get to the part of validation where RFC 6125 is relevant then we already know the wildcard dNSName subjectAltName entry is valid. Given that, RFC 6125 just needs to specify how to match, syntactically, a wildcard against a reference identifier. (I think this is compatible with what Ryan Sleevi wrote in this thread.)

Right, I think we agree that 6125bis doesn't need to tackle that, but
it does sound like we disagree why.

It seems you're in favor of the "fail fail" scenario, which happens
before reaching 6125bis processing, and is rejected for all names
asserted.

I was arguing for a "fail if used" scenario, where it's only checked
after 6125bis comparisons have happened, and which certificate remains
valid for the other names it asserts.

---

From: Brian Smith <[email-masked]>
Date: Mon, 12 Jul 2021 14:14:39 -0700

Ryan Sleevi <[email-masked]> wrote:

> > If we get to the part of validation where RFC 6125 is relevant then we
> already know the wildcard dNSName subjectAltName entry is valid. Given
> that, RFC 6125 just needs to specify how to match, syntactically, a
> wildcard against a reference identifier. (I think this is compatible with
> what Ryan Sleevi wrote in this thread.)
>

I think the important point is that RFC 6125 can specify the syntax of a
wildcard, and we can specify how to match a reference ID against it,
without having to dive into determining whether the CA should have issued
that wildcard and/or what other validation of the wildcard needs to be
done. I.e. that further validation happens outside (before, after, or in
parallel to) RFC 6125 processing.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 12 Jul 2021 17:25:46 -0400

> parallel to) RFC 6125 processing.

Yes, just syntax and semantics, but not the operational outcome.  The
relying party learns that the CA has bound the public key to all
single-label subdomains of the domain that follows the "*" label.

What the relying party does with that information is not specified,
though in practice most RPs will do what is generally expected for the
application in question.  Many applications presently support wildcards.

Wildcards are still a bad when other options are available, and server
operators should avoid them whenever possible.

-- 
    Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Jul 2021 21:27:36 +0000

*   that further validation happens outside (before, after, or in parallel to) RFC 6125 processing.

It seems like it would be worthwhile for us to mention that in the beginning.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 12 Jul 2021 14:48:48 -0700

> It seems like it would be worthwhile for us to mention that in the 

Part of my problem is that I don’t know what the boundaries of RFC 
6125 are. If there’s further validation that happens elsewhere that 
this depends upon, it should be specific about what other RFCs define 
that validation.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 12 Jul 2021 17:57:20 -0400

> On 12 Jul 2021, at 5:48 pm, Jim Fenton <[email-masked]> wrote:
> 
> Part of my problem is that I don’t know what the boundaries of RFC 6125 are. If there’s further validation that happens elsewhere that this depends upon, it should be specific about what other RFCs define that validation.

Not everything is covered by RFCs, some decisions are a matter
of local policy, while others are part of de facto application
profiles.

In RFC6125, Appendix B attempted to curate information about
various extant applications.  If some of the affected applications
have since been updated by subsequent RFCs, those might now be in
scope.

The UTA WG may well be a reasonable forum in which to clarify the
expected treatment of wildcards in various applications.

It would be nice to see at least some applications (IMAP? SUBMIT?)
deprecate wildcards.  But if not, otherwise declare wildcards supported
(by clients) but discouraged (best not employed by servers whenever
possible).

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Jul 2021 22:05:56 +0000

I think the 6125 was explicit about what it covered, and I hope the new version will be more explicit: how to validate server “names” when using PKIX certs and TLS.

Everything else is out of scope. As Viktor said, it’s often local policy.  What RFC describes Chrome’s behavior?  And why should there be one?

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 13 Jul 2021 11:12:59 +1000

> says "only the first label"

Sort of.  The text I quoted does not.  You could say "can only match the leftmost label in ...".

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Jul 2021 13:21:30 +0000

>    Sort of.  The text I quoted does not.  You could say "can only match the leftmost label in ...".

Assuming we have consensus, the PR on this says that the wildcard character can only be the first label, so I think it's set.

---

From: Dan Ehrlich <[email-masked]>
Date: Tue, 13 Jul 2021 11:43:48 -0500

I think there is a growing consensus among network engineers that ICANN and
a few at IETF (at least a few years ago) weren't 100% honest regarding how
DNS wildcards work.

I think we can all agree that the RFCs keep it vague enough that no one can
say for sure how wildcards work. This was I think a point of contention in
fact when ICANN took over from IANA in 1998.

Another good example of what I think qualifies as deception in regards to
DNS is ccTLD vs gTLD.

For instance, is .ms gTLD (Microsoft uses it) or ccTLD (for the island
nation of Montserrat). No one knows...

On Tue, Jul 13, 2021 at 8:21 AM Salz, Rich <rsalz=
[email-masked]> wrote:

> Assuming we have consensus, the PR on this says that the wildcard
> character can only be the first label, so I think it's set.
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>