[BUG] CreateKeyAsync only Creates keys with default size/curve and ignores key options input

[ventimdg-msft]

Library name and version

Azure.Security.KeyVault.Keys 4.7.0

Describe the bug

public virtual async Task<Response> CreateKeyAsync(string name, KeyType keyType, CreateKeyOptions keyOptions = default, CancellationToken cancellationToken = default)

This function says that it "Creates and stores a new key in Key Vault. The create key operation can be used to create any key type in Azure Key Vault." However, the KeyOptions are not parsed correctly, causing RSA/Oct keys to always have default size and ECC keys to always have the default Curve, regardless if it is set in the options.

the call to var parameters = new KeyRequestParameters(keyType, keyOptions); navigates here

In this code, the is no parsing of the keytype to determine whether key size or curve needs to be set. This results in all keys created with the function to return keys with a default size/curve

Expected behavior

If you put in a key type and define the key options, a key is created of the input type with the size/curve defined in the key options input

Actual behavior

Key of proper type is created, but KeySize/Curve input in the options is dropped if it is included and default value is used

Reproduction Steps

Call this function with any key options and observe that the size/curve will not change in the returned key

public virtual async Task<Response> CreateKeyAsync(string name, KeyType keyType, CreateKeyOptions keyOptions = default, CancellationToken cancellationToken = default)

Environment

NET 4.7.2 and NET8

[github-actions]

Hi @ventimdg-msft, I'm an AI Support assistant here to help with your issue. While the Azure SDK team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.

• The current implementation of CreateKeyAsync does not parse the key options to override the default size or curve. This behavior means that even if you set a custom value in the CreateKeyOptions, the constructed KeyRequestParameters ignore it.
• Verify that the CreateKeyOptions instance is initialized with the correct properties (e.g. KeySize for RSA keys or Curve for ECC keys) and that these properties align with the values supported by the service.
• For guidance on how client options are intended to be used when customizing client behavior, see the discussion on configuring service clients using ClientOptions: Client options.
• This behavior is consistent with the current implementation in this release, so when a non-default key size or curve is required, the input options may need to be validated prior to calling CreateKeyAsync to ensure they are correctly set.

The Azure SDK team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!

[jsquire]

Looking this over, this is a docs issue with CreateKey and CreateKeyAsync which should clearly indicate that only the base key options are considered when creating keys. For key types that support an extended property set, such as RSA keys with key size and exponent, the named overload should be called. For example, CreateRsaKey.

[heaths]

The type-specific overloads are there to guide customers to create a valid key lest the service return HTTP 400 with an error message that may not always be helpful. This was more of an "escape hatch" function to create any key and, thus, it was probably an oversight that I didn't define or parse all possible options from CreateKeyOptions.

That said, this should generally not be the function you call to create a key. As mentioned above, it's an escape hatch added to hypothetically support different key types the service might add; though, not sure how: even though KeyType may be an extensible enum - I don't recall for sure off hand since I haven't worked on this in over a year - the CreateKeyOptions may not define necessary parameters.