update 3.5.5

[elarlang]

Spin-off from #2184

Current 3.5.5

#	Description	L1	L2	L3	CWE
3.5.5	[ADDED] Verify that only signing algorithms on an allowlist are allowed for a stateless token.	✓	✓	✓	757

---

@randomstuff via #2184 (comment)

Should we verify as well that in a given context either MAC or public-key signature are used but not both interchangeably (notably as a way to prevent JWT key confusion type attacks)?

I think this is what @jmanico is referring to when talking about "signature type abuse" but if that's the case, the requirement should be more explicit about this (i.e. don't mix MAC and signatures).

@jmanico via #2184 (comment)

Another type of historical signature type abuse is when you forcibly set the JWT signature type to "none" and bypass signature validation. This is less of an issue when you set up an allow list of legal signatures and use modern JWT libraries.

[ryarmst]

I would like to suggest the use of "Cryptographically Signed Token" in place of "Stateless Token" to further generalize. I assume there ought to be a corresponding documentation requirement, but this feels like it would coincide with V6.2.

[tghosth]

I would suggest:

#	Description	L1	L2	L3	CWE
3.5.5	[ADDED] Verify that only signing algorithms on an allow list can be used to create and verify Cryptographically Signed Token. The allow list should not include both symmetric and asymmetric algorithms and should not include the "None" algorithm.	✓	✓	✓	757

I don't think we need an explicit documentation requirement...

[elarlang]

Styling things:

• allow list > allowlist (based on Josh's previous edits)
• Cryptographically Signed Token > lowercase

Content: the requirement describes what should not be in allowlist, but it does not describe, what should be there. At the moment it's negative requirement and still not clear, what exactly is allowed and what is not.

[jmanico]

ADDED] Verify that only signing algorithms on an allowlist are allowed for a stateless token.

Some services support both HMAC's and Digital Signature Algorithms for various reasons (like when you are transitioning your token integrity method in a system to a new method, multi-tenant systems, etc).

HMAC's are cryptographic integrity algorithms and are not signing algorithms.

If you want to be generic, I suggest we drop the idea of "cryptographically signed", and instead just use "cryptographically authenticated" or "cryptographically secured" as a term.

[tghosth]

Ok so trying to respond to both elar and jim:

#	Description	L1	L2	L3	CWE
3.5.5	[ADDED] Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens. The allow list should include the permitted algorithms, ideally only either symmetric and asymmetric algorithms, and should not include the "None" algorithm. If both symmetric and asymmetric are needed, additional controls should prevent key confusion.	✓	✓	✓	757

[elarlang]

• "The allow list ..." - in first sentence there is "allowlist", in this one "allow list"
• "ideally only either symmetric and asymmetric" - is here "and" correct or it should be "or"?

ping @randomstuff

[tghosth]

🤦

#	Description	L1	L2	L3	CWE
3.5.5	[ADDED] Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens. The allowlist should include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and should not include the "None" algorithm. If both symmetric and asymmetric are needed, additional controls should prevent key confusion.	✓	✓	✓	757

[randomstuff]

Should we add "in a given context" or something like that? ("Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens in a given context.") It is fine to use symmetric algorithms in one context and asymmetric algorithms in another context.

[tghosth]

Yeah I agree with that

🤦

#	Description	L1	L2	L3	CWE
3.5.5	[ADDED] Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens, for a given context. The allowlist should include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and should not include the "None" algorithm. If both symmetric and asymmetric are needed, additional controls should prevent key confusion.	✓	✓	✓	757

[tghosth]

So the glossary says "Cryptographically Signed Token" but here we have used "cryptographically secured token".

Do we use "Cryptographically Signed Token" anywhere else

If no we should update the glossary and move on.

If yes, I think secured is more accurate than signed but we need to update to be consistent.

@elarlang

[elarlang]

This is more ping to @ryarmst and @randomstuff

[tghosth]

I don't think we need to bother them, I think secured is better anyway and we don't really use the term else where so I just committed 66adb0c and approved so if you are comfortable with that @elarlang then you can merge

[elarlang]

I merged it. If it needs further updates, we can improve it (again).