certificates
                                
                                
                                
                                    certificates copied to clipboard
                            
                            
                            
                        Improve URI policy configuration and matching
Hello!
- Vote on this issue by adding a 👍 reaction
 - If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)
 
Issue details
Policy rules for URIs can currently only be configured with an allowed domain. Other parts of the URI in a CSR can be anything, because no policy is enforced on the other parts. It is thus not possible to only allow a certificate to be signed with https:// as the URI scheme.
It would be good to be able to configure URI rules that also include the other parts of the URI, including the scheme, path, query and fragment, so that users can configure the URI rule with more details, resulting in more control over the certificates to be signed.
A couple considerations:
- For 
scheme, a match on normalized format (lowercase) will be performed. It could take an explicit wildcard (*). Not providing aschemeis like providing a wildcard. - For 
path, a string match keeping the case intact can be performed. It could take an explicit wildcard (*). Not providing apathis like providing a wildcard. - For 
query, a match on the same contents can be performed. It can be made independent of order. It could take an explicit wildcard (*). Not providing aqueryis like providing a wildcard. - For 
fragment, a match on the contents can be performed. It could take an explicit wildcard (*). Not providing afragmentis like providing a wildcard. - Not all parts are case-insensitive, so that needs to be accounted for.
 - Check if wildcard character (
*) makes sense. - Supporting a regex match might be a nice fit for URIs. They're harder to reason about, though.
 
Why is this needed?
To be able to enforce a specificscheme, path, query or fragment in a URI, so that certificates not adhering to the requirements won't be signed.
A related issue is https://github.com/smallstep/certificates/issues/1093, in which https://token.actions.githubusercontent.com#repo:tashian/oidctest:ref:refs/heads/main is requested as a URI SAN. In this case, it would've been nice to only allow the #repo:tashian/oidctest:ref:refs/heads/main fragment, for example.