Convert WebCrypto algorithm to JOSE alg

[jonathanstanley]

Suppose I get a CryptoKey that looks something like this:

const randomKey = {
  "type": "secret",
  "extractable": false,
  "algorithm": { "name": "AES-KW", "length": 256 },
  "usages": ["wrapKey", "unwrapKey"]
};

Now if I want to create a JWE with it:

const jwe = await new CompactEncrypt(encoder.encode('secret message'))
  .setProtectedHeader({ alg: "A256KW", enc: 'A256GCM' }) //bad to assume the algorithm will always be A256KW
  .encrypt(randomKey)

Since, I cannot extract the key to JWK, I don't see an great way to convert "algorithm" per WebCrypto to >>> "alg" per JOSE. ex: { "name": "AES-KW", "length": 256 } >>> A256KW

What I'd like to do is have a getAlgFromKey() something like this:

const jwe = await new CompactEncrypt(encoder.encode('secret message'))
  .setProtectedHeader({ alg: getAlgFromKey(randomKey), enc: 'A256GCM' }) //always works! 
  .encrypt(thirdPartyKey)

I think I pretty much want the opposite of this:

jose/src/runtime/browser/jwk_to_key.ts

Lines 7 to 106 in 5487311

	function subtleMapping(
	jwk: JWK,
	): { algorithm: RsaHashedImportParams | EcKeyAlgorithm | Algorithm; keyUsages: KeyUsage[] } {
	let algorithm: RsaHashedImportParams | EcKeyAlgorithm | Algorithm
	let keyUsages: KeyUsage[]
	switch (jwk.kty) {
	case 'oct': {
	switch (jwk.alg) {
	case 'HS256':
	case 'HS384':
	case 'HS512':
	algorithm = { name: 'HMAC', hash: { name: `SHA-${jwk.alg.substr(-3)}` } }
	keyUsages = ['sign', 'verify']
	break
	case 'A128CBC-HS256':
	case 'A192CBC-HS384':
	case 'A256CBC-HS512':
	throw new JOSENotSupported(`${jwk.alg} keys cannot be imported as CryptoKey instances`)
	case 'A128GCM':
	case 'A192GCM':
	case 'A256GCM':
	case 'A128GCMKW':
	case 'A192GCMKW':
	case 'A256GCMKW':
	algorithm = { name: 'AES-GCM' }
	keyUsages = ['encrypt', 'decrypt']
	break
	case 'A128KW':
	case 'A192KW':
	case 'A256KW':
	algorithm = { name: 'AES-KW' }
	keyUsages = ['wrapKey', 'unwrapKey']
	break
	case 'PBES2-HS256+A128KW':
	case 'PBES2-HS384+A192KW':
	case 'PBES2-HS512+A256KW':
	algorithm = { name: 'PBKDF2' }
	keyUsages = ['deriveBits']
	break
	default:
	throw new JOSENotSupported('unsupported or invalid JWK "alg" (Algorithm) Parameter value')
	}
	break
	}
	case 'RSA': {
	switch (jwk.alg) {
	case 'PS256':
	case 'PS384':
	case 'PS512':
	algorithm = { name: 'RSA-PSS', hash: { name: `SHA-${jwk.alg.substr(-3)}` } }
	keyUsages = jwk.d ? ['sign'] : ['verify']
	break
	case 'RS256':
	case 'RS384':
	case 'RS512':
	algorithm = { name: 'RSASSA-PKCS1-v1_5', hash: { name: `SHA-${jwk.alg.substr(-3)}` } }
	keyUsages = jwk.d ? ['sign'] : ['verify']
	break
	case 'RSA-OAEP':
	case 'RSA-OAEP-256':
	case 'RSA-OAEP-384':
	case 'RSA-OAEP-512':
	algorithm = {
	name: 'RSA-OAEP',
	hash: { name: `SHA-${parseInt(jwk.alg.substr(-3), 10) || 1}` },
	}
	keyUsages = jwk.d ? ['decrypt', 'unwrapKey'] : ['encrypt', 'wrapKey']
	break
	default:
	throw new JOSENotSupported('unsupported or invalid JWK "alg" (Algorithm) Parameter value')
	}
	break
	}
	case 'EC': {
	switch (jwk.alg) {
	case 'ES256':
	case 'ES384':
	case 'ES512':
	algorithm = { name: 'ECDSA', namedCurve: jwk.crv! }
	keyUsages = jwk.d ? ['sign'] : ['verify']
	break
	case 'ECDH-ES':
	case 'ECDH-ES+A128KW':
	case 'ECDH-ES+A192KW':
	case 'ECDH-ES+A256KW':
	algorithm = { name: 'ECDH', namedCurve: jwk.crv! }
	keyUsages = jwk.d ? ['deriveBits'] : []
	break
	default:
	throw new JOSENotSupported('unsupported or invalid JWK "alg" (Algorithm) Parameter value')
	}
	break
	}
	default:
	throw new JOSENotSupported('unsupported or invalid JWK "kty" (Key Type) Parameter value')
	}
	return { algorithm, keyUsages }
	}

Does panva/JOSE have this somewhere that I missed? Would it be helpful for me to create it and submit a PR?

note: here are the explicit mappings. I believe this is the algorithm to alg mapping function in Chrome/blink.

[panva]

Hi @jonathanstanley

How would such API deal

• with CryptoKey algorithms that cannot be mapped to a single unique alg value?
• with CryptoKey algorithms that cannot be mapped to any JOSE algorithm?
• with CryptoKey algorithms that apply both to alg and enc algorithms but the result algorithm identifier not being the same?

How would such API work when node's KeyObject is passed in? It looks like a WebCrypto only API.

[panva]

I've intentionally gone away from automatically determining the algorithms to use based on the key object. It's better the developer makes conscious decision about the algorithms they want to use then if one is chosen for them. This looks like it would do what i've intentionally left out in v3.x

[jonathanstanley]

Thanks and interesting points.

I would expect an algFromKey() function to result in the exact same alg produced by crypto.subtle.exportKey("jwk",randomKey).alg (which already works for exportable keys, just need it also for non-exportable keys). Otherwise, throw error.

I agree that the enc should not be assumed and it's best that the developer make a conscious decision of which algorithm for the CEK to encrypt the content in a JWE.

However, since alg identifies the CryptoKey the developer has already chosen, inputting it again as a function parameter creates coupled-code that I would think preferable to avoid (DRY - Don't Repeat Yourself). For example, if I generate a key with {name:"AES-KW",length:128} and I want to create a JWE with that CryptoKey, I need to create a dedicated function and look up the mapping and then specify .setProtectedHeader{alg:"A128KW",...}. And if it ever changes in the future, such as to length 256, I have to remember to also change the JWE function to .setProtectedHeader{alg:"A256KW",...} or error.

But, it sounds like you've seen this leading to other problems and intentionally left it out, or perhaps I'm missing something? I could certainly imagine cases where the developer wants to insist that the key is a particular alg, and setting the parameter acts as a test to ensure the CryptoKey is compliant. But I can also see cases where the developer just wants to create the JWE from whatever CryptoKey provided and could use a function... perhaps /src/util/key_to_alg.ts Either way thanks as always @panva!

[panva]

It's just not possible to do this for all CryptoKey algorithms.

• ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW, ECDH-ES+A256KW all share the same key algorithm
• for dir encryption the same method should imo be usable for getting the enc value and that makes A128GCMKW, A192GCMKW, A256GCMKW, A128GCM, A192GCM, A256GCM all share the same key algorithm too
• PBES2-HS256+A128KW, PBES2-HS384+A192KW, PBES2-HS512+A256KW also share the same key algorithm (PBKDF2)

The Algorithm mappings from WebCrypto API spec does not cover everything either. Plus none of this can be applied to node crypto runtime where there's only key's type to go off of.

I think it's best to keep this in your own code knowing what key algorithms you will encounter and opt in to support in your application.