Support XML DSIG alg values

[ronzeidman]

Some libraries use XML DSIG alg values in the jwt header (mostly .net standard library) instead of the standard JWS alg. meaning that instead of using "alg": "RS256" they're using "alg": "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256". Because of that I can't use this library to parse and validate tokens generated by these libraries. It's a pretty small fix to add this value table (located here https://datatracker.ietf.org/doc/html/rfc7518#appendix-A.1) to the enum to add support for it.

[bdemers]

@ronzeidman can you provide a pointer to the lib/framework that does this? (Ideally with some example code or pointer to similar)?

[lhazlewood]

Hrmmm - #493 (being done in the jwe branch) will allow you to plug in any custom signature algorithms that are not specification compliant.

The libraries that you refer to are not specification compliant - the cross-reference table that you listed is explicitly to help implementers know what algorithm to use in their programming language of choice when encountering the JWA/RFC identifier string. Those values are not intended to be used, nor are they specified in the RFC specifications to be used, as the actual values for the alg header.

It is very likely that the implementors of the libraries you mentioned are using the programming language specific value instead of the JWA/RFC required value as an oversight. That is, you should raise a bug report with those library authors that they are not specification compliant.

Because of this, it feels odd for JJWT - a specification compliant library - to add changes to our code base to facilitate working with non-compliant libraries. It seems those libraries are the ones that should be fixed because the RFC exists for these reasons.

[lhazlewood]

An analogous example of the original request:

This would be like JJWT - a Java library - to use the Java Cryptography Architecture identifier of HmacSHA256 (in your linked cross reference table) as the jwt alg value, and then expecting .NET library authors to support that value because its in the table.

RFCs exist specifically for cross-language/platform compatibility, and the respective .NET library authors are ignoring this very important point.

Hopefully that makes clear my particular viewpoint on this matter. I'm not saying we absolutely won't support those values, but it is really hard to justify adding code, test cases, and maintenance to address other library shortcomings that should be fixed there instead.

[nick-randal]

It was said that those libraries are not specification compliant but the link above states,

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.

other standards and software packages.

What is the downside of having a library that increases its flexibility by supporting an appendix that came straight out of the RFC?

XML DSIG is a valid specification and it is referenced in the appendix for a reason.
https://www.w3.org/TR/xmldsig-core2/

https://github.com/jwtk/jjwt/blob/master/api/src/main/java/io/jsonwebtoken/JwsHeader.java makes direct reference to section 4.1.1 in which it states

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

If XML DSIG is invalid then why does the spec allow for a URI?

[nick-randal]

@bdemers

This relies on Microsoft's System.IdentityModel.Jwt NuGet package. This package contains 4 DLLs widely in use:

• System.Identity.Tokens.Jwt
• Microsoft.IdentityModel.JsonWebTokens
• Microsoft.IdentityModel.Tokens
• Microsoft.IdentityModel.Logging

I put this example together using Linqpad which has a free version available to download.

var key = Encoding.UTF8.GetBytes("Don't tell anyone!");

var signingCredentials = new SigningCredentials(
	new SymmetricSecurityKey(key), 
	SecurityAlgorithms.HmacSha256Signature);

var token = new JwtSecurityToken(
	issuer: "example.org",
	audience: "1234567890abcdef",
	claims: new[]
	{
		new Claim(ClaimTypes.NameIdentifier, "Nick"),
		new Claim(ClaimTypes.Role, "Person"),
		new Claim(ClaimTypes.Email, "Nick@aol.com")
	},
	notBefore: DateTime.UtcNow,
	expires: DateTime.UtcNow.AddMinutes(2),
	signingCredentials: signingCredentials
);

// Create
var tokenHandler = new JwtSecurityTokenHandler();
var secureToken = tokenHandler.WriteToken(token).Dump("Generated Token");


// Verify

Microsoft.IdentityModel.Tokens.SecurityToken st;
var validation = new TokenValidationParameters() {
	ValidIssuer = "example.org",
	ValidAudience = "1234567890abcdef",
	IssuerSigningKey = new SymmetricSecurityKey(key) 
};

System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler jstHandler = new JwtSecurityTokenHandler();
jstHandler.MaximumTokenSizeInBytes = 2048;

jstHandler.ValidateToken(secureToken, validation, out st);

(st as JwtSecurityToken).Dump("Received Token");

[lhazlewood]

those libraries are not specification compliant but the link above states

As I stated above, that section is provided as help (only) to implementors so they can more easily identify how to implement the specification algorithms. It is in an Appendix, and therefore not part of the formal specification values. (It is is considered 'non normative' in RFC speak - it is added for help and clarity, not something that defines specification behavior.)

other standards and software packages

You said it yourself - other - is the key word here. Not this (the JWA) specification. That table is just there to be helpful, not to impose JWT construction requirements.

Here's another reason why it's rather clear the XML DSIG values were never intended to be supported in an actual JWT:

All of the JWT standard header names and values, and claim names have been thought of meticulously to be as small as absolutely possible while still being relatively readable.

• Instead of key_id, they use kid (saving only three characters!)
• Instead of initialization_vector they use iv
• Instead of ephemeral_public_key, they use epk
• Instead of SHA256withRSA or 1.2.840.113549.1.1.11 or http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 they use RS256.

Every single signature algorithm standard identifier is only 5 characters long.

They did this in a very calculating manner: JWTs are designed to be http headers and query parameter values, and sent over network protocols - they were designed from conception to be as efficient as possible (insofar as text payloads can be efficient). Using the XML DSIG value would completely blow apart their efficiency mandate - those values never were intended to be used in the actual JWT payload. Again, only as help to .NET library authors to know how to compute the signature, not what goes in the JWT itself.

This is pretty clear evidence that the .NET library authors to which you refer didn't 'Do the Right Thing' here because the XML DSIG URI values are 1) not using specification identifiers and 2) violate the design principles of minimal/efficient JWT construction. Regardless of how the JJWT team reacts to this particular request, someone should definitely open a bug report with them because they are definitely not 'Doing the Right Thing' in their library.

If XML DSIG is invalid then why does the spec allow for a URI?

It allows for a URI in cases where the standard identifiers are not sufficient - for custom algorithm identifiers, and to avoid namespace collision (i.e. a foo value can collide between different JWT sender and receiver parties, but https://company.com/ns/foo will not). URIs are only intended to be used when a simple/minimal string cannot, and only when between different parties (i.e. if the same party is both sending and receiving with no chance of being used/seen by a 3rd party, foo is a fine value and better than the URI for efficiency reasons). This is also the reason #493 exists - to allow you to plug in your own custom signature algorithms when the RFC-standard identifiers are not used - then you can look up an algorithm implementation based on your custom URI and everything will still work.

But that's not the case in this particular scenario because the XML DSIG text values in the appendix do have an RFC-mandated string identifier, and those are in the actual specification body (JWA RFC, Section 3.1.

What is the downside of having a library that increases its flexibility by supporting an appendix

It adds code to maintain, test cases, and requires us to be responsible for anything related to that functionality now and in the future. In this particular case, it's pretty minimal, but if we implemented every non-specification-compliant feature requested, the library could be 1.5 to 2 times the size of what it is today. The other issue is that JJWT is by far the most popular library for Java used in 10s of thousands if not 100s of thousands of projects, and you would be surprised that even minimal requests can have a burden/impact that outlasts the initial innocuous intentions of the request.

Another reason is that it de-incentivizes everyone to not file a bug report with the .NET library authors. I gave copious reasons why they should fix their implementation - because they're definitely letting implementation details bubble up when the specification is very clear on these standard values - and if they don't fix it, then the next Node, Python, etc library team is going to be asked to add the same convenience feature. The reasons specs exist is specifically to avoid these types of extraneous work on language teams that are 'doing the right thing' already.

Anyway, all of this is a big mouthful to explain all the reasons why/how I believe things should be done. It does not mean we won't actually support the XML DSIG text values. I don't like the idea of curtailing to a framework that isn't doing what the spec clearly indicates, but I also see the value in helping people. It is after all, why we created JJWT and don't get paid for it. For us, being helpful often outweighs the burdens, but I'm personally 50/50 on the fence because it doesn't actually fix the root cause of the problem (.NET library implementation details).

Finally, I will say that #493 will allow you to support those XML DSIG values if the .NET library doesn't change - you can look at the text value, see that it corresponds to a .NET URI, and just return the JWA-standard SignatureAlgorithm instance. So at least there's that.

[nick-randal]

You have made some valid points and I appreciate brevity in values, however XML DSIG is supported in the JWA.

See https://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-01.html Section 3.5

it is permissible to use the algorithm identifiers defined in XML DSIG [RFC3275] and related specifications as alg values.

[lhazlewood]

Sorry, but that's not in the specification. You linked to a draft specification created in 2012. The formal/official specification removed that well before final adoption as an RFC. The official spec is here:

https://datatracker.ietf.org/doc/html/rfc7518

and it has no such language.

[nick-randal]

The JWA RC you reference about in section 3.1 literally says to see Appendix A.1. Its making direct reference to it.

See Appendix A.1 for 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.

[lhazlewood]

Yes, other being the key word 😉 I've explained that the Appendix exists to help implementors know how to compute the signature in their language of choice, not what the alg value is. It does not say anywhere in that document that they are supported values for the alg header parameter. Where do you see that explicitly?

If you look at the actual subsections defining the alg values and their behavior, e.g. https://datatracker.ietf.org/doc/html/rfc7518#section-3.3, XML DSIG isn't mentioned at all. But the standard 5-letter identifiers are. It's pretty clear, direct from the spec:

The following "alg" (algorithm) Header Parameter values are used to
indicate that the JWS Signature is a digital signature value computed
using the corresponding algorithm:

The only values defined are RS256, RS384 and RS512. Those are the actual values intended to be used in the JWT header itself. Same for the RSASSA-PSS section at https://datatracker.ietf.org/doc/html/rfc7518#section-3.5

If other values were intended to be supported, they would have indicated them as possible values in those exact sections. They don't, which is why the Appendix values are there for implementation detail help, not for actual specification values.

[nick-randal]

Please show me where it states explicitly those values are not supported. I am taking the document at face value. It makes direct reference to the appendix in the specification and I don't see how that relegates it to the land of anecdotal reference. Appendixes at there to keep text from being noisy and I don't see any definition of RFCs where it says that moving something to an appendix renders it irrelevant or optional.

Please direct me to the text that states, all values must be directly referenced and appendices render other values irrelevant. There are many RFCs that put valid and supported values in appendices. That is a choice by the documenter and not a classification.

[lhazlewood]

Please show me where it states explicitly those values are not supported

For the alg header for JWS explicitly, this section:

https://datatracker.ietf.org/doc/html/rfc7518#section-3.1

defines the only text alg values that are defined by the specification, from required to optional to recommended implementation requirements. If the spec intended the URIs to be used, don't you think they'd be in that section, with at least an Optional distinction?

Can they be supported? Yes, anyone can put URI values - including the XML DSIG ones - in the header. But if they were expected to be supported by libraries, they would be in Section 3.

Since they're not, why do you think JJWT should support them? Especially when the .NET library must support the specification RS256, RS384 and RS512 values anyway? Why do you think we should support something in a non-normative appendix when .NET isn't using something in the actual specification body? Shouldn't a bug/feature request be submitted to the .NET library authors instead?

[lhazlewood]

Also, for posterity. Section 3.1 says:

The table below is the set of "alg" (algorithm) Header Parameter
values defined by this specification for use with JWS, each of which
is explained in more detail in the following sections:

That's it. That's the only source of truth for alg values for use with JWS defined by the JWA specification. It says so right in that sentence.

Other values can be used (e.g. URIs), but they are not guaranteed to be supported by any libraries because they're not in the 3.1 table (which btw also has implementation guidance - optional, required, recommended).

The values in the Appendix, once again, are not values defined to be supported as alg values in the specification. They're only there to help library authors implement the signature algorithms using existing cryptographic framework references. I'm 100% confident that if you email the RFC 7518 team and ask they will corroborate this sentiment.

[bdemers]

@nick-randal

In your above example, if you update the alg value, does that fix the problem?

var signingCredentials = new SigningCredentials(
	new SymmetricSecurityKey(key), 
	SecurityAlgorithms.HmacSha256Signature);

to:

var signingCredentials = new SigningCredentials(
	new SymmetricSecurityKey(key), 
	SecurityAlgorithms.RsaSha256);

From:
https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/blob/b45a5b4cf4e918ca2b2c12ff1951f1be7b592bac/src/Microsoft.IdentityModel.Tokens/SecurityAlgorithms.cs#L104

Maybe this is partially a usage issue of that library?

It looks like the JWA constants are defined:

https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/blob/b45a5b4cf4e918ca2b2c12ff1951f1be7b592bac/src/Microsoft.IdentityModel.Tokens/SecurityAlgorithms.cs#L96-L109

Digging into this a little more, is the example code you provided from an existing project or a readme?

I don't spend much time in the .Net world, so I'm mostly making guesses, so let me know if I'm off base and we should contact the maintainers of the lib.

[lhazlewood]

@bdemers don't you mean:

from:

var signingCredentials = new SigningCredentials(
	new SymmetricSecurityKey(key), 
	SecurityAlgorithms.HmacSha256Signature);

to:

var signingCredentials = new SigningCredentials(
	new SymmetricSecurityKey(key), 
	SecurityAlgorithms.HmacSha256);

[nick-randal]

@bdemers I arbitrarily picked a signature key type. In further testing though I can confirm that the .net libraries understand both sets of codes.

@lhazlewood I don't agree with cherry picking an RFC or redefining what an appendix means. There are plenty of RFCs that move things like tables into an appendix to not clutter the text. RFC places no rules on how a writer structures their document nor do they state anywhere that I can find that an appendix is arbitrary information of no importance or that it is optional.

You keep skipping past that the section you continual reference, state to "see the Appendix A".

XML DSIG predates the JWA which would explain why MS supports both. Coming along after the fact and disregarding a pre-existing spec is your right. But I would not encourage anyone to use a library that has a narrow interpretation of a specification.
In the time that this thread has gone on, you could have implemented a simple key mapping lookup to redirect the URI to the JWA code that you insist is the one true code, which would have in turn exercised any existing unit tests available for the signature verification.

[lhazlewood]

@nick-randal No one is cherry-picking anything. I keep telling you See appendix A is a "cross-reference", not a standardized set of values for the JWA RFC. Cross-reference means "not in this document, but a pointer to other documents." If it's not standardized in this (JWA) document (Section 3), it's not part of the specification, plain and simple. It is saying something akin to "if you're not exactly sure of what we mean by RS256, you can look at the other identifiers in other programming languages/environments to find the corresponding algorithm".

The spec says:

equivalent identifiers used by other standards
and software packages

Equivalent does not mean expected/supported in this specification. Absolutely nowhere anywhere in the JWA RFC does it indicate that Appendix A.1 values are expected to be supported alg values.

There's no other way of stating it: Appendix A.1 is not normative (The word 'normative' is very specific in RFC contexts, and it matters). It is not part of defined values expected to be supported by implementations. It is a helpful section, not an indicator of what goes in a JWT alg value. You don't get to choose what implementations are expected to support - that is the entire purpose of Section 3.1

disregarding a pre-existing spec is your right

I'm not disregarding the XML DSIG spec. I am stating that absolutely nowhere in the JWA RFC does it indicate that implementors are expected to natively support any algorithm identifier than those defined in Section 3. You can 'add' to those values if you like, but at that point you're expanding on what the RFC defines.

I can't say it any more clearly than to use the specification's own words in Section 3.1:

The table below is the set of "alg" (algorithm) Header Parameter
values defined by this specification for use with JWS

This doesn't say "the table below and those in Appendix A.1". It says only "the table below". The cross reference is a link to be helpful, not to expand on the definition.

It seems like the only way to appease you is for me to reach out to the RFC committee, get word directly from them, and show you their direct response that only the values in 3.1 are expected to be supported natively by libraries.

you could have implemented a simple key mapping lookup to redirect the URI to the JWA code

Expect me to just code, write tests, and maintain a feature that literally no one has ever asked for in the 5 years this project has been active? And now that I think about it - that no one has ever asked for this - IMO is a much stronger indicator indicating this is simply user error related to a misunderstanding of RFC standard alg values as opposed to something a JWT-standard library should support.

I don't mean you any ill will or negativity or antagonism, truly - I am just confident that you are misinterpreting the RFC and/or are susceptible to legacy 'gotchas' from an older JWT library implementation. That the .NET library supports both means that the standard values should be used, and it seems like you don't need this in JJWT, no?

[lhazlewood]

FWIW, I have contacted the RFC Working Group and asked them to clarify the point about Appendix A.1 we are debating. We'll see what they say 😜

[nick-randal]

Not in this document...

It is literally in the document. The appendix is not a cross reference and its incorrect to decide that it is not relevant.

I don't need you to implement this. I am advocating for @ronzeidman who submitted this and indicating that Microsoft takes in both values and made the decision to output XML DSIG.

There is no expansion of functionality being asked for here, we are hashing over a key mapping. There are no new algorithms being introduced.

Also I'm advocating for interoperability which hurts no one. You have decided that Microsoft is wrong and they should change. This helps no one.

[nick-randal]

You should take a look at something like the TLS RFC which moves many portions of the document to multiple appendices.

[lhazlewood]

The appendix is not a cross reference and its incorrect to decide that it is not relevant.

Yes, it is! it says it literally in the RFC in the part of Section 3.1 that you like to point to:

See Appendix A.1 for 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.

It is literally a cross-reference of JWS-defined values (in 3.1) with non-JWS values defined in other specifications. There is no indicator whatsoever that those other values should be accepted/understood as JWS alg values. I genuinely don't understand why you believe the spec implies this, especially when it says it's a cross-reference.

Maybe switching up a bit will help illustrate this. Let me ask you this question:

If JJWT output HmacSHA256 for the alg value - a JCA identifier in the Appendix A.1. table - and that JWT was consumed by a .NET application, would you open a bug report/feature request with the Microsoft team that they should support JCA (Java) identifiers? They're in Appendix A.1 after all, right? So that should be added to Microsoft's library, right?

Microsoft takes in both values and made the decision to output XML DSIG.

Are you sure about that? If you change to the following:

var signingCredentials = new SigningCredentials(
	new SymmetricSecurityKey(key), 
	SecurityAlgorithms.HmacSha256);

It doesn't output HS256 as the alg value?

Also I'm advocating for interoperability which hurts no one. You have decided that Microsoft is wrong and they should change.

If Microsoft is the only one that outputs that value, that is the exact opposite of interoperability. Using the values in Section 3.1 that literally every other library (including Microsoft's apparently) are the values of interoperability.

And if you still don't believe me, wait until I link you to the answers to this debate that come direct from the IETF Working Group. There's no point in debating this particular point further because we both agree to disagree. The Working Group will have the last word on this, and I'll happily eat my words (and apologize) if they contradict me.

[ronzeidman]

Thanks for giving my issue so much thought. I agree with both approaches. Thing is I'm validating a token that was not generated by me and I have a very limited control on the other side's code. So even if Microsoft changes their library in a breaking way (probably won't happen since it'll change currently generated tokens in many places) banning the old "alg" values, I may encounter other people generating tokens in that old way. And since it's Microsoft standard Identity model I'm pretty sure it's common enough to be taken into consideration even if it's not 100% RFC compliant.
#493 is a good solution, when do you think it'll be officially part of the library?
Do you want me to create a simple PR with a lookup table in the enum (maybe add XML DSIG property to the enum and look there if we didn't find a mach over "value")?

[lhazlewood]

@ronzeidman #493 is actually already implemented in the jwe branch, and I'm working hard to finish that as soon as I'm able. It has taken a year of on/off work, but I've dedicated a lot of time in the last three weeks to it, so I hope to have it finished within a month. The tricky part of all of this is that JWE requires encoded keys in the JWK format, and that was a whole 'nuther (fairly large) specification that had to be implemented just for JWE to be spec-compliant. It was a ton of work.

As to modifying the enum, that wouldn't really work - because the interface-based approach is the only solution that allows plugging in of custom algorithms (with XML DSIG ID's or otherwise), the enum has already been deprecated in the jwe branch. We don't want to modify/add to the enum because we explicitly want to discourage its further use.

I very much appreciate you asking here first before working on a PR! We're very grateful for PRs, but really hate having to decline them because the requestor wasn't aware of current changes or codebase design issues (like the jwe work for example).

You might want to fork the latest JJWT release and add those changes locally for yourself until the jwe branch is merged if you need it before the jwe work is done - could be a month or so before we can merge it.

[bdemers]

(This comment was delayed due to a GH outage)

@ronzeidman any chance you can point me to the product or lib that created the token with the XML DSIG URL in it? Maybe I can help you track that down and get that lib to put the proper fix in?

Either way, I think #493 is the only path forward for this (which is part of the larger JWE support work that is going on)

As a short-term, ugly stop gap, you could probably, tweak the JSON parer to replace the XML DSIG names with the spec complaint name.

With Jackson you could setup a custom ObjectMapper

jjwt/extensions/jackson/src/main/java/io/jsonwebtoken/jackson/io/JacksonDeserializer.java

Line 82 in a4130dd

public JacksonDeserializer(ObjectMapper objectMapper) {

Or you could just implement a Deserializer (that wraps another implementation, like the Jackson one above), and replaces the alg value.

Either of these options would probably need some testing (Headers are also parsed before the JWT is validated, the same Deserializer would be used for the JWT payload as well), so this would only work if you are reasonably sure of the shape of your JWTs, and it's NOT a general-purpose fix.

[ronzeidman]

Thanks.
@bdemers I'm working with them to try and solve it, they're using the .net identity model, and they are also following this thread and trying to fix the issue on their side, so maybe it'll be solved soon, I'm just afraid of future integrations I may have that will require similar fixes.

As for workarounds, I tried altering the "alg" value in the encoded part of the header, but apparently the hash also validates the header so it's is failing. the only way I could make it work in a local test is to change the enum using reflection, and this I can't do in production.

If they'll not be able to alter their token generation I'll probably fork this repo and use it until the next version will release although no security auditor likes usage of forked or not released token parsing libraries :).

What issue should I monitor in order to get notified if the jwe branch gets released?

[lhazlewood]

@ronzeidman: @bdemers suggestion should work without requiring a fork:

Or you could just implement a Deserializer (that wraps another implementation, like the Jackson one above), and replaces the alg value.

I know it's not exactly obvious how to do this - is it possible for you to provide a test JWS string produced by the .NET library (with a test key)? If so either of us could create a quick code sample that demonstrates the technique and you could just use that.

If you can't provide a sample JWS and key, we can try to simulate it, but it's a bit harder to verify the functionality

[lhazlewood]

@ronzeidman The JWE work is being tracked under #113

[stale]

This issue has been automatically marked as stale due to inactivity for 60 or more days. It will be closed in 7 days if no further activity occurs.

[stale]

Closed due to inactivity.