Algorithm and Encryption Algorithm attributes

[tplooker]

In some instances when JWM's are being used to bootstrap a connection or perform a key agreement, similar to how a TLS handshake operates. It is desirable for one party to communicate to the other the cryptographic algorithms they support to ensure a successful handshake.

As an example in OpenID Connect Discovery the following fields are used by an OP to communicate this information

• request_object_signing_alg_values_supported : OPTIONAL. JSON array containing a list of the JWS signing algorithms (alg values) supported by the OP for Request Objects, which are described in Section 6.1 of OpenID Connect Core 1.0 [OpenID.Core]. These algorithms are used both when the Request Object is passed by value (using the request parameter) and when it is passed by reference (using the request_uri parameter). Servers SHOULD support none and RS256.
• request_object_encryption_alg_values_supported : OPTIONAL. JSON array containing a list of the JWE encryption algorithms (alg values) supported by the OP for Request Objects. These algorithms are used both when the Request Object is passed by value and when it is passed by reference.
• request_object_encryption_enc_values_supported : OPTIONAL. JSON array containing a list of the JWE encryption algorithms (enc values) supported by the OP for Request Objects. These algorithms are used both when the Request Object is passed by value and when it is passed by reference.

This issue is to discuss whether public attributes should be defined in the JWM specification that enable the expression of this information and to what extent this functionality should be defined in the specification.

[kdenhartog]

I think these can be helpful for fail fast operations, but I'm also wondering how we might support this in our implementation.

the three options I came up with are:

• we load the list of algorithms supported dynamically from the KMS which generates a list to compare against

Some downsides to this approach is that it may not be possible to set the encryption algorithm order for selections during the negotiation similar to how TLS handles this.

Some advantages to this approach is that we can support architectures with pluggable algorithm support.

• we statically load the algorithms supported via a config file

The advantages here is that we can support a pluggable architecture, but need to perform a check to make sure the configured algorithms are supported in the KMS.

The alternative option is to not support this functionality and to send an error when a key type is used that isn't understood. This is similar to TLS handshake_failure error

[tplooker]

Yeah I agree, as attributes in the JWM what would we suggest as viable fields if we did pursue adding this functionality? OpenID Connect obviously splits this functionality into three fields, however I don't find their names that intuitive even though I understand their intent after reading about them

[tplooker]

When using encryption in the JWE the enc field is usually reserved for indicating the ciphertext encryption method. Is it safe to say the alg field is usually reserved for indicating KEK of the key used for the encryption?

[tplooker]

Following that logic do the three attribute names make sense.

• signing_algs - An array of valid JWAalg identifiers that indicate the supported signature verification methods the sender supports.
• encryption_algs - An array of valid JWA enc identifiers that indicate the support decryption methods the sender supports.
• kek_algs - An array of valid JWA alg identifiers that indicate the supported key agreement methods the sender supports.

[kdenhartog]

Yeah I agree, as attributes in the JWM what would we suggest as viable fields if we did pursue adding this functionality? OpenID Connect obviously splits this functionality into three fields, however I don't find their names that intuitive even though I understand their intent after reading about them

In this instance, I'm not opinionated about name. I'm not sure if we need 3 options either if we use profiling similar to what digital bazaar has in minimal cipher. I think the encryption and kek method can be rolled into one with crypto profiling. Such as crypto_profile: [recommended, FIPS]

When using encryption in the JWE the enc field is usually reserved for indicating the ciphertext encryption method. Is it safe to say the alg field is usually reserved for indicating KEK of the key used for the encryption?

I'm not sure what KEK stands for. "Alg" is always used to describe the method used to encrypt the content encryption key.

[tplooker]

In this instance, I'm not opinionated about name. I'm not sure if we need 3 options either if we use profiling similar to what digital bazaar has in minimal cipher. I think the encryption and kek method can be rolled into one with crypto profiling. Such as crypto_profile: [recommended, FIPS]

Im open to profiles, I believe they give developers less room to mess up implementations, but if we do that we will need to define a new registry to track what these mean in terms of how they translate to valid JWA identifiers?

I'm not sure what KEK stands for. "Alg" is always used to describe the method used to encrypt the content encryption key.

"Key Encryption Key", the term is used by minimal cipher and the encrypted data vaults specification. Unsure how standard this term is though.

[kdenhartog]

Im open to profiles, I believe they give developers less room to mess up implementations, but if we do that we will need to define a new registry to track what these mean in terms of how they translate to valid JWA identifiers?

That's probably the best thing to do in order to make sure everything is proper. I don't think it's absolutely necessary at this point. I feel like this may require an addition to the JWE/JWS spec though, so this may stretch outside the bounds of what we want to change.

"Key Encryption Key", the term is used by minimal cipher and the encrypted data vaults specification. Unsure how standard this term is though.

Gotcha. In that case I believe the answer is yes.