Hi Stefan

On 2020/08/20 17:24, Stefan Winter wrote:
The FQDN of the server itself would be in the Subject (CN=server.fqdn.example);

Simply looking at the subject breaks the case where a given server may have multiple valid FQDNs (i.e. the use case that subjectAlternativeName:dNSname is meant to solve), which I suspect is a fairly common use case.

For instance, we currently have certificates with subjectAlternativeName:dNSname in them:

        Subject: DC = net, DC = geant, DC = eduroam, C = ZA, O = Tertiary Education and Research Network of South Africa, CN = flr-cpt.eduroam.ac.za
             X509v3 Subject Alternative Name:
                DNS:flr-cpt.eduroam.ac.za, DNS:flr-jnb.eduroam.ac.za, DNS:eduroam-cpt-01.eduroam.ac.za, email:eduroam@tenet.ac.za

This is because we run a high-availability configuration with the FLR servers' IP addresses bound on loopbacks and able to swing between physical instances. The three DNS sANs are the canonical name of this instance (matching the subject, in accordance with public CA best practices), the canonical name of the other instance that we act as standby for, and the FQDN of the underlying host.

I see a similar thing in the hosted IdP:

        Subject: DC = net, DC = geant, DC = eduroam, C = NL, O = GEANT Association, CN = auth-1.hosted.eduroam.org
             X509v3 Subject Alternative Name:
                DNS:auth-1.hosted.eduroam.org, DNS:auth-2.hosted.eduroam.org, email:eduroam-ot@lists.geant.org

where the same certificate is presented whether I connect to auth-1 or auth-2.

Whether or not this is right for RadSec or indeed for the specific case of eduroam, it certainly matches user expectations which is what Fabian was getting at here:

I'm very skeptical about this point. I can't point to any RFC or so, but my gut-feeling says that sAN:DNS is used very often for multi-domain certificates. Not allowing multi-domain certificates would violate user expectations, and might also exclude some use-cases.

My gut feeling is that overloading the semantics of sAN:dNSname in anything other than very controlled circumstances with a very small community will lead to confusion, because the default interpretation of a newish person will be to match what web browsers do.

[1] This behaviour is "almost" like the semantically cleaner behaviour
of RFC7585 - except that the list of realms is in a dedicated
certificate extension called NAIRealm in the RFC, while here one would
overload sAN:DNS instead.

I'm interested in the use case for overloading sAN:dNSname rather than using sAN:otherName:NAIRealm?

- Guy
--