On Mon, Jul 12, 2021 at 2:08 PM Jim Fenton <fen...@bluepopcorn.net> wrote:
> 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.
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.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
