On Sun, Nov 21, 2021 at 2:53 AM John Mattsson <john.matts...@ericsson.com>
wrote:
> John: I agree with Section 6.1.1 that the client need a limited set of
> reference
> identifiers. Reading 6.1. again, i think that the term "set" that you use
> might be better than list. Is the intention to forbid sets of reference
> identifiers such as:
>
>
>
> *.eaptlsserver.ssid-ipv6only.ietf112.ietf.org
>
>
>
> That seems too strict for general TLS (i.e., not only HTTPS), and too much
> of an implementation detail. Using a wildcard reference identifies seems
> like a better security solution than using a wildcard presentation
> identifier in some cases.
>
Ryan: Right now, the draft doesn't really speak at all to this being a
thing, other than saying you MUST NOT do it (although worded as a MUST of
the opposite). That is, the algorithm is defined as a reference identifier
being an explicit ("fully qualified") identifier, and the presented
identifiers being able to have wildcards.
What you're describing here is extracting, from the set of presented
identifiers, an acceptable reference identifier, and then re-attempting
validation. I think there's a lot of sharp corners there that are
non-obvious.
Using your example here, of a server set to accept any client presented
identifier in the form *.foo.example, a sharp edge here would be how to
handle when the presented identifier is also *.foo.example - is that an
acceptable match or not?
> John: Thinking a bit more, what I wanted to say was that there are use
> cases that are symmetrical in the way that any of the two nodes can start
> TLS. Such use cases can use the same certificate for both the TLS client
> and TLS server role. While TLS has a strict client and server roles, that
> division might not be done before one of the nodes sends a client hello.
> Unless there are any problems I don't see, I think it would be good if the
> document stated.
>
>
>
> "In some use cases the same certificate is used for both client and server
> roles. A server certificate following this specification MAY be used also
> as a client certificate.”
>
Sure, this is entirely reasonable text, but I don't think it addresses the
matching issue you've raised here with the server validating the DNS-ID of
the client.
The issue here is whether or not the server-validating-client has an
out-of-bands configuration comparable to what the client-validating-server
has, which is to say, something discrete not tied to/derived from the
certificate. Your example highlights that generally it's not a bounded set
of identifiers, but rather, some form of unbounded set derived from the
certificate, and that seems a somewhat separate algorithm, goal, and
process for validating. However, if the idea is the server has a discrete
set of unambiguous identities it'll accept, then sure, I agree, there's not
an inherent problem in using the same certificate for both (ignoring the
PKI management complexities, of course).
>
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
