Support verifying JWT signatures, which use different encodings from ASN.1

[Nic0w]

Hi,

I have been trying to verify JSON Web Tokens' signature with webpki and it appears to be more complicated than it should be.

Quoting jwt.io :

JSON Web Tokens are an open, industry standard RFC7519 method for representing claims securely between two parties.

Mainly, JWT are used as part of authentication systems (OpenID Connect, OAuth2, ...) for Web applications, but not only.

RFC7515 (RFC for JSON Web Signature) describes how signature works for a JWT. Mainly, it states at page 45 (Appendix A, §3.1 that :

The result of the digital signature is the Elliptic Curve (EC) point (R, S), where R and S are unsigned integers.
[..]
The JWS Signature is the value R || S.

where || denotes the concatenation of two values.

Upon examination of ring's source code, it seems to me that this encoding method matches the expected input for *_FIXED signature algorithms. See function split_rs_fixed in ring.

However webpki only exposes the *_ASN1 version of such algorithms, meaning that one has to first encode R, S to a DER sequence of unsigned integers before trying to call verify_signature. That seems like a unnecessary step as it adds unneeded complexity. It is also prone to error if one is not familiar with DER encoding.

As such it would be nice if webpki would expose _FIXED versions of signature algorithms.

Thanks in advance,
Regards,

[briansmith]

I think we should:

1. Change SignatureAlgorithm like so:

pub struct SignatureAlgorithm {
    public_key_alg_id: AlgorithmIdentifier,
    signature_alg_id: AlgorithmIdentifier,
    verification_alg_asn1: &'static dyn signature::VerificationAlgorithm,
    verification_alg_fixed: &'static dyn signature::VerificationAlgorithm,
}

2. Rename EndEntityCert::verify_signature to verify_signature_asn1 and have it use the renamed verification_alg_asn1 during verification, and clarify the documentation about what format of signature this is for.
3. Add verify_signature_fixed that works analogously but which uses the new verification_alg_fixed field and document why format of signature this is for.

For RSA and ED25519 there would be no difference in the values of the _asn1 and _fixed fields.

WDYT?

[briansmith]

Also, I don't know if/where the JOSE specification says which EKU, KU, etc. should be used for such certificates, but presumably you also need a new API for building/verifying the certificate chain using the proper EKU, instead of the EKUs for TLS clients/servers.

[briansmith]

I've generalized this issue to be about adding JWT support. Here's what I expect to see from others before we make progress on this issue:

• Provide links to the parts of the JWT specifications that specify the extended key usage (EKU), key usage, and other aspects of a certificate that is to be used for JWT.
• Provide links to the parts of the JWT specifications that specify the forks of the signatures/keys.
• Test cases for all the signature algorithms that are to be supported, which include an actual JWT and the full certificate chain up to a (custom) root certificate.