Support URI in SAN

[taniwha3]

SPIFFE uses URI instead of DNS in the SAN. The webpki library currently does not support URI.

I propose we add support for it.

https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md#2-spiffe-id

[dbgilley]

I would also love to see support for this, both for URIs and for other kinds of SAN entries like email addresses.

[djc]

@dbgilley can you talk about your use cases in more detail? Would help us prioritize these features.

[dbgilley]

Sure! I'm attempting to use mutual TLS to authenticate clients connecting to a server, and moreover to ensure that only specific clients (identified by name) are allowed access. It appears that the way to do this is to make use of EndEntityCert::verify_is_valid_for_subject_name, but since SubjectNameRef only supports IP addresses and DNS names I am having to fudge things by issuing certificates with a dummy domain name that contains the relevant client information — something like e.g. client-<identifier>.com. I would prefer to check the certificate against a URI because that would remove the need to translate client identifiers into valid DNS names as well as because it would be a better experience for clients if they ever inspected the certificate on their device with OpenSSL or similar.

[djc]

Thanks for the clarification. Would you be able to contribute some code towards this goal? We could probably provide some guidance on what needs to happen to make this work. (Are you using webpki directly or only via rustls?)

[cpu]

As part of the work required for landing CRL distribution point extension support I updated webpki to recognize URI type general names:

webpki/src/subject_name/verify.rs

Line 408 in 01c0e3e

UniformResourceIdentifier(untrusted::Input<'a>),

I think we mostly need to wire this through to the subject name handling code in name.rs, making sure we fully understand the semantics of how two URIs should be compared (e.g. heeding the warnings on the GeneralName type about naive Eq/PartialEq without the context of comparison.

I would be happy to help review 👍

[cpu]

(Are you using webpki directly or only via rustls?)

There's also a matching issue on the Rustls repo where I left some questions trying to understand the use-case better: rustls/rustls#1194 (comment)

[zaharidichev]

I second the comment by @dbgilley. It would be useful to be able to represent identities as Spiffe IDs.

[djc]

Maybe this is another case where we need to have enough public API/an extension point that allows people to build this on top of the more commonly used bits?

[zaharidichev]

Maybe this is another case where we need to have enough public API/an extension point that allows people to build this on top of the more commonly used bits?

Probably this is the case. However for this particular case (of SVIDs) it really seems that the limiting factor is that the ServerName cannot really represent a URI San. Is there apetite to get that contribution through?

[djc]

That's why I was wondering about an extension point for this, see rustls/rustls#816 (comment). In other words: I'm not sure there is appetite for a contribution that is specific to SPIFFE, but if we can enable a bunch of miscellaneous downstream use cases that would be interesting.