On Fri, Aug 23, 2024 at 10:14 AM Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> 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://username@xxxxxxxxxxx > > 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. > 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? 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 -- You received this message because you are subscribed to the Google Groups "openssl-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe@xxxxxxxxxxx. To view this discussion on the web visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/CAMO4%3DdpZTMSuqiHShxdgj838E%3DewFuPYiYseAqoPVs42EeAHzQ%40mail.gmail.com.
