In my dealings with JOSE at $dayjob, it has felt like someone looked at X.509 and Kerberos and decided that their problem is ASN.1.
Yes, X.509 and Kerberos have problems and some of them come down to ASN.1. But somehow having “it’s JSON!” as the focus of the grand new signature/access token/encryption standard did not lead to a perfect world.
Does anybody has a decent list of sources for that?
At work we mostly use governments’ cipher recommendations that we cross reference to ensure good results. For example taking US (NIST) + Germany (BSI) does usually result in a seemingly good list.
They still list some controversial ones (like NIST curves), but overall, that’s usually a reasonable choice to justify to management/auditors.
CNSA 1.0 is a good suite if you plan on selling to the US government, as the algorithms specified there are all FIPS-able.
If you don’t care about selling to the US government, or oppose the US government using your software, you can stick to the non-NIST suite of ciphers (ChaCha, Poly1305, Salsa20, BLAKE2b, etc.). Those are all good, except for the lack of a NIST stamp of approval.
X25519 and Ed25519 used to be on the non-NIST list, but FIPS 186-5 added Ed25519 to the FIPS suite.
Generally, you’ll want to consult a cryptography expert for whatever you’re building that uses cryptography. Even a 30 minute call to describe your use case and solicit algorithm recommendations can save you a lot of headache down the road.
A cryptographer you hire will also be able to give you more nuanced guidance; i.e. how to fit within specific bandwidth or performance benchmarks while still hitting or exceeding some security threshold.
But if you’re looking for blanket guidance, you already have enough from NIST + BSI to make an informed decision.
The article provides a list of recommend algorithms.
Depending on which algorithms you choose to support/not support, you might be in violation of the RFCs. But sadly that’s somewhat of a requirement to get even a moderately-secure version of “JWT” (the actual proper formal name is “JOSE” – JavaScript Object Signing and Encryption – of which JWT is but one piece).
In my dealings with JOSE at $dayjob, it has felt like someone looked at X.509 and Kerberos and decided that their problem is ASN.1.
Yes, X.509 and Kerberos have problems and some of them come down to ASN.1. But somehow having “it’s JSON!” as the focus of the grand new signature/access token/encryption standard did not lead to a perfect world.
Does anybody has a decent list of sources for that?
At work we mostly use governments’ cipher recommendations that we cross reference to ensure good results. For example taking US (NIST) + Germany (BSI) does usually result in a seemingly good list. They still list some controversial ones (like NIST curves), but overall, that’s usually a reasonable choice to justify to management/auditors.
CNSA 1.0 is a good suite if you plan on selling to the US government, as the algorithms specified there are all FIPS-able.
If you don’t care about selling to the US government, or oppose the US government using your software, you can stick to the non-NIST suite of ciphers (ChaCha, Poly1305, Salsa20, BLAKE2b, etc.). Those are all good, except for the lack of a NIST stamp of approval.
X25519 and Ed25519 used to be on the non-NIST list, but FIPS 186-5 added Ed25519 to the FIPS suite.
Generally, you’ll want to consult a cryptography expert for whatever you’re building that uses cryptography. Even a 30 minute call to describe your use case and solicit algorithm recommendations can save you a lot of headache down the road.
A cryptographer you hire will also be able to give you more nuanced guidance; i.e. how to fit within specific bandwidth or performance benchmarks while still hitting or exceeding some security threshold.
But if you’re looking for blanket guidance, you already have enough from NIST + BSI to make an informed decision.
The article provides a list of recommend algorithms.
Depending on which algorithms you choose to support/not support, you might be in violation of the RFCs. But sadly that’s somewhat of a requirement to get even a moderately-secure version of “JWT” (the actual proper formal name is “JOSE” – JavaScript Object Signing and Encryption – of which JWT is but one piece).
Correct on all points.
Thankfully, the RFC police aren’t going to break down our doors for making the JOSE working group sad.
[Comment removed by author]