URI name constraint fails when URI contains a userinfo component

[Jacob Persson]

We are creating certificates with a SAN URI containing a userinfo component:

X509v3 Subject Alternative Name:
            URI:wireapp://user...@example.com

This produces valid certificates until we add a name constraint limiting the permitted URI's:

X509v3 Name Constraints: critical
            Permitted:
            DNS:example.com
            DNS:localhost
            URI:example.com
            URI:localhost

With this addition openssl verification fails with

error 47 at 0 depth lookup: permitted subtree violation
error cert.pem: verification failed

Shouldn't the userinfo component of an URI be ignored when applying URI name constraints?

openssl version: OpenSSL 1.1.1q  5 Jul 2022

[Viktor Dukhovni]

On Thu, Aug 22, 2024 at 06:31:15AM -0700, 'Jacob Persson' via openssl-users wrote:

> We are creating certificates with a SAN URI containing a userinfo component:
>
> X509v3 Subject Alternative Name:
> URI:wireapp://user...@example.com

What is the purpose of the "username" here? I see nothing in any of

rfc5280, rfc6125, rfc9525

that assigns any meaning to the username part of a URI in X.509
certificates. Best I can tell, if present, it should ignored!

https://datatracker.ietf.org/doc/html/rfc9525#section-7.2

The URI-ID type is a subjectAltName entry of type
uniformResourceIdentifier as defined in [PKIX]. For the purposes of
this specification, the URI-ID MUST include both a "scheme" and a
"host" component that matches the "reg-name" rule; if the entry does
not include both, it is not a valid URI-ID and MUST be ignored. Any
other components are ignored because only the "scheme" and "host"
components are used for certificate matching as specified under
Section 6.

https://datatracker.ietf.org/doc/html/rfc9525#section-6

At a high level, the client verifies the application service's
identity by performing the following actions:

1. The client constructs a list of reference identifiers it would
find acceptable based on the source domain and, if applicable, the
type of service to which the client is connecting.

2. The server provides its presented identifiers in the form of a PKIX
certificate.

3. The client checks each of its reference identifiers against the
server's presented identifiers for the purpose of finding a match.
When checking a reference identifier against a presented identifier,
the client matches the source domain of the identifiers and,
optionally, their application service type.

> This produces valid certificates until we add a name constraint limiting
> the permitted URI's:
>
> X509v3 Name Constraints: critical
> Permitted:
> DNS:example.com
> DNS:localhost
> URI:example.com
> URI:localhost
>
> With this addition openssl verification fails with
>
> error 47 at 0 depth lookup: permitted subtree violation
> error cert.pem: verification failed
>
> Shouldn't the userinfo component of an URI be ignored when applying URI
> name constraints?

So, while likely you have a point when saying that name constraints
should ignore the username, I think it is reasonable to question whether
the username should be used in the first place. The relying application
can be expected to look only at the scheme and hostname, and then that's
all that should be in the SAN?

FWIW, I also don't see any "wireapp" URI scheme in the IANA registry:

https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

and no associated reference to a specification of how "wireapp" clients
are expected to employ URI-IDs in certificates. :-(

> openssl version: OpenSSL 1.1.1q 5 Jul 2022

At this point the behaviour of 1.1.1 (EOL) is unlikely to change in its
treatment of URI-IDs in certificates, even if some changes are made in
response to the question you've raised.

--
Viktor.

[Jacob Persson]

On Fri, Aug 23, 2024 at 10:14 AM Viktor Dukhovni
<openss...@dukhovni.org> wrote:
>
> On Thu, Aug 22, 2024 at 06:31:15AM -0700, 'Jacob Persson' via openssl-users wrote:
>
> > We are creating certificates with a SAN URI containing a userinfo component:
> >
> > X509v3 Subject Alternative Name:
> > URI:wireapp://user...@example.com
>
> What is the purpose of the "username" here? I see nothing in any of
>
> rfc5280, rfc6125, rfc9525
>
> that assigns any meaning to the username part of a URI in X.509
> certificates. Best I can tell, if present, it should ignored!
>
> https://datatracker.ietf.org/doc/html/rfc9525#section-7.2

The username identifies a wire user within a domain but the meaning
and validation
of that is happening inside our client application.

That is valid point and we could of course consider moving the user
identifier to
another place, but it's important for us that it is present within the
certificate for
additional verification checks which happens at the application level.

> FWIW, I also don't see any "wireapp" URI scheme in the IANA registry:
>
> https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
>
> and no associated reference to a specification of how "wireapp" clients
> are expected to employ URI-IDs in certificates. :-(

True, we haven't registered the scheme yet.

> > openssl version: OpenSSL 1.1.1q 5 Jul 2022
>
> At this point the behaviour of 1.1.1 (EOL) is unlikely to change in its
> treatment of URI-IDs in certificates, even if some changes are made in
> response to the question you've raised.

I understand that 1.1.1 (EOL) is unlikely to change but we have also observed
the same behaviour in the more recent versions like 3.3.1.

But if I understood correctly the fact that the userinfo component is
not ignored
could be considered a bug in openssl, should I open a Github Issue for that?

/Jacob

[Viktor Dukhovni]

On Fri, Aug 23, 2024 at 02:11:42PM +0200, 'Jacob Persson' via openssl-users wrote:

> > that assigns any meaning to the username part of a URI in X.509
> > certificates. Best I can tell, if present, it should ignored!
> >
> > https://datatracker.ietf.org/doc/html/rfc9525#section-7.2
>
> The username identifies a wire user within a domain but the meaning
> and validation
> of that is happening inside our client application.

A more appropriate application-specific SAN might have been an
"otherName" variant under some suitable OID arc, where you control
the semantics of the SAN (but would also then need (and be free) to
implement both the validation and any name constraint checks).

> > and no associated reference to a specification of how "wireapp" clients
> > are expected to employ URI-IDs in certificates. :-(
>
> True, we haven't registered the scheme yet.

If this is at all likely to be relevant to a broader community, or just
to avoid conflicts, it might make sense to register the scheme.

> I understand that 1.1.1 (EOL) is unlikely to change but we have also observed
> the same behaviour in the more recent versions like 3.3.1.

As expected.

> But if I understood correctly the fact that the userinfo component is
> not ignored could be considered a bug in openssl, should I open a
> Github Issue for that?

By all means. This will not guarantee prompt remediation, the issue is
rather a corner case, but if you're also able to contribute a robust fix
(parse the URI authority to strip the username and port), then it might get
adopted.

Note that not all schemes encode an authority, (e.g.
mailto:user@domain), so your code would apply only
to URIs of the form:

scheme://user@host[:port][/path...]

You should also check whether other aspects of matching URI "reference"
identifiers with "presented" URI SANs in the certificate matches RFCs
5280 and 6125.

--
Viktor.