Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support URI in SAN #9

Open
taniwha3 opened this issue Nov 2, 2022 · 10 comments
Open

Support URI in SAN #9

taniwha3 opened this issue Nov 2, 2022 · 10 comments

Comments

@taniwha3
Copy link

taniwha3 commented Nov 2, 2022

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
Copy link

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

@djc
Copy link
Member

djc commented Aug 23, 2023

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

@dbgilley
Copy link

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
Copy link
Member

djc commented Aug 24, 2023

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
Copy link
Member

cpu commented Aug 24, 2023

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

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
Copy link
Member

cpu commented Aug 24, 2023

(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
Copy link

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

@djc
Copy link
Member

djc commented Sep 15, 2023

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
Copy link

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
Copy link
Member

djc commented Sep 15, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants