509_san_dns

[alenhorvat]

509_san_dns

is the same syntax supported as for TLS certificates? So:

• multiple domain names
• wildcard certificates

Thank you.

[jogu]

The relevant text is:

When the Client Identifier Prefix is x509_san_dns, the original Client Identifier (the part after the x509_san_dns: prefix) MUST be a DNS name and match a dNSName Subject Alternative Name (SAN) [RFC5280] entry in the leaf certificate passed with the request. <...> the FQDN of the redirect_uri value MUST match the Client Identifier without the prefix x509_san_dns:. Example Client Identifier: x509_san_dns:client.example.org.

I think "a DNS name" (where the definition may be coming from RFC5280, but I don't think I've actually found a clear definition) means a single hostname. So:

x509_san_dns:foo.example.com is good

x509_san_dns:*.example.com is not a wildcard, and x509_san_dns:foo.example.com,bar.example.com is (I think) not valid, or at least doesn't mean two hostnames.

I think listing multiple hostnames in the certificate is fine.

I'm not sure whether wildcard certificates are okay. Where is the wildcard behaviour for TLS certificates defined?

[alenhorvat]

https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3226-wildcard-domain-validation

Wildcard Certificate: A Certificate containing at least one Wildcard Domain Name in the Subject Alternative Names in the Certificate.

Wildcard Domain Name: A string starting with “*.” (U+002A ASTERISK, U+002E FULL STOP) immediately followed by a Fully-Qualified Domain Name.

And: https://cabforum.org/working-groups/server/baseline-requirements/requirements/#712712-subscriber-certificate-subject-alternative-name

For Subscriber Certificates, the Subject Alternative Name MUST be present and MUST contain at least one dNSName or iPAddress GeneralName. See below for further requirements about the permitted fields and their validation requirements.

Also for the common name:
If present, this attribute MUST contain exactly one entry that is one of the values contained in the Certificate’s subjectAltName extension (see Section 7.1.2.7.12)

So question is: what are the verification rules between information expressed in a TLS certificate and x509_san_dns?

[jogu]

(for clarify, I'm writing as a WG participant, not a chair, so this is my personal take)

As currently written, x509_san_dns:foo.example.com would be permitted with a certificate that listed both foo.example.com and bar.example.com in separate dnsName records in the SAN.

And given that (from the links you shared, thanks!) the behaviour of wildcards is not defined in RFC5280 (which is what the VP spec text points at) then if a certificate contains only a dnsName of *.example.com the only legal client id is x509_san_dns:*.example.com.

Other opinions welcome...

[alenhorvat]

then if a certificate contains only a dnsName of .example.com the only legal client id is x509_san_dns:.example.com.

This can increase the attack surface (dangling DNS, subdomain takeover) as there's no guarantee all subdomain services are equally protected.

IMO there are 2 points to address:

• explain better the matching rules for the three cases (and clarify explicitly that CN should not be used for identifier matching)
• define better the x509_san_dns rules

Note that in RFC5280 they don't forbid wildcard characters:

Finally, the semantics of subject alternative names that include
wildcard characters (e.g., as a placeholder for a set of names) are
not addressed by this specification. Applications with specific
requirements MAY use such names, but they must define the semantics.

[jogu]

We can probably do some clarifications in an errata and/or VP 1.1 if we don't break things.

Note that in RFC5280 they don't forbid wildcard characters:

They don't, but they also don't give them meaning. "Application" in that case I think means "a relevant specification" so I think the position in base VP is that * is treated as a literal *, not a wildcard.

Did you have any use cases where wildcards did need to work?

[alenhorvat]

My question is simple:

• what are the rules for the x509_san_dns matching when TLS certificates are wildcard certificates:
  a) match the URL you're visiting with the x509_san_dns value (in this case x509_san_dns name is misleading)
  b) match the x509_san_dns with the entry in the TLS certificate (question with matching rules pops up)
  c) both
  ?

[jogu]

My question is simple:

• what are the rules for the x509_san_dns matching when TLS certificates are wildcard certificates:
  a) match the URL you're visiting with the x509_san_dns value (in this case x509_san_dns name is misleading)
  b) match the x509_san_dns with the entry in the TLS certificate (question with matching rules pops up)
  c) both
  ?

"b" is the default position.

I'm not sure what "URL you're visiting" means - there is this language around redirect_uri / response_uri when using x509_san_dns:

If the Wallet can establish trust in the Client Identifier authenticated through the certificate, e.g. because the Client Identifier is contained in a list of trusted Client Identifiers, it may allow the client to freely choose the redirect_uri value. If not, the FQDN of the redirect_uri value MUST match the Client Identifier without the prefix x509_san_dns: