Support XML DSIG identifiers

[Simon Gaeremynck]

It appears that algorithms can be identified using an XML DSIG identifier. e.g. http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 rather than the short-hand HS256.

‌

In the JWT token, the header looks as follows:

{
  "alg": "http://www.w3.org/2001/04/xmldsig-more#hmac-sha256",
  "typ": "JWT"
}

I had not seen this before until suddenly our integration stopped working, but it appears that the specs do allow for it.

Section 4.1.1 of the JWS Spec:

The "alg" (algorithm) Header Parameter identifies the cryptographic
algorithm used to secure the JWS. The JWS Signature value is not
valid if the "alg" value does not represent a supported algorithm or
if there is not a key for use with that algorithm associated with the
party that digitally signed or MACed the content. "alg" values
should either be registered in the IANA "JSON Web Signature and
Encryption Algorithms" registry established by [JWA] or be a value
that contains a Collision-Resistant Name. The "alg" value is a case-
sensitive ASCII string containing a StringOrURI value. This Header
Parameter MUST be present and MUST be understood and processed by
implementations.

A list of defined "alg" values for this use can be found in the IANA
"JSON Web Signature and Encryption Algorithms" registry established
by [JWA]; the initial contents of this registry are the values
defined in Section 3.1 of [JWA].

Section 3.1 of JWA:

This has a table listing out HS256, RS256, etc… but also refers to appendix A.1

Appendix A.1:

Digital Signature/MAC Algorithm Identifier Cross-Reference

This section contains a table cross-referencing the JWS digital
signature and MAC "alg" (algorithm) values defined in this
specification with the equivalent identifiers used by other standards
and software packages.

+-------------------------------------------------------------------+
| JWS | XML DSIG | JCA | OID |
+-------------------------------------------------------------------+
| HS256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 | HmacSHA256 | 1.2.840.113549.2.9 |
+-------------------------------------------------------------------+
| HS384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384 | HmacSHA384 | 1.2.840.113549.2.10 |
+-------------------------------------------------------------------+
| HS512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512 | HmacSHA512 | 1.2.840.113549.2.11 |
+-------------------------------------------------------------------+
| RS256 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 | SHA256withRSA | 1.2.840.113549.1.1.11 |
+-------------------------------------------------------------------+
| RS384 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha384 | SHA384withRSA | 1.2.840.113549.1.1.12 |
+-------------------------------------------------------------------+
| RS512 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 | SHA512withRSA | 1.2.840.113549.1.1.13 |
+-------------------------------------------------------------------+
| ES256 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256 | SHA256withECDSA | 1.2.840.10045.4.3.2 |
+-------------------------------------------------------------------+
| ES384 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384 | SHA384withECDSA | 1.2.840.10045.4.3.3 |
+-------------------------------------------------------------------+
| ES512 | http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512 | SHA512withECDSA | 1.2.840.10045.4.3.4 |
+-------------------------------------------------------------------+
| PS256 | http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1 | SHA256withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
| PS384 | http://www.w3.org/2007/05/xmldsig-more#sha384-rsa-MGF1 | SHA384withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+
| PS512 | http://www.w3.org/2007/05/xmldsig-more#sha512-rsa-MGF1 | SHA512withRSAandMGF1 | 1.2.840.113549.1.1.10 |
+-------------------------------------------------------------------+

[Brian Campbell]

That table is only an informational cross-reference. The XML DSIG identifiers are not valid JOSE alg identifiers (nor are the Java names or OIDs).

[Simon Gaeremynck]

I definitely don’t have enough expertise to dispute that, but section 4.1.1 seems to indicate that it does allow URIs?

The "alg" value is a case-sensitive ASCII string containing a StringOrURI value.

FWIW, I agree that using the XML DSIG identifiers is weird, but the third party we’re integrating with seems to insist they’re following the spec?

[Brian Campbell]

The general format of the alg value allowing for a URI in no way means that a particular URI is defined to have meaning.

Note that the JOSE alg registry https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms has the defined algs and points to the spec in which they were defined.

I don’t know what else to tell you. http://www.w3.org/2001/04/xmldsig-more#hmac-sha256 is not a legit JWS algorithm and any expectation that it would interoperate is misplaced at best.

‌

‌

[Brian Campbell]

In initialization somewhere, you could probably get the JWS AlgorithmFactory from AlgorithmFactoryFactory and register a little wrapper around HmacUsingShaAlgorithm.HmacSha256 that returns the xmldsig uri for getAlgorithmIdentifier() to make things work without asking the third party to change. But it’d be better to have them fix their stuff IMHO.

‌

[Simon Gaeremynck]

Thank you for the iana link, hopefully that helps convince them. We implemented exactly the workaround you mentioned for now, but will ask them to change again.

I think this issue can be closed as a Won’t fix as it seems out-of-line with the spec.