/AWS1/IF_KMS=>SIGN()¶
About Sign¶
Creates a digital signature for a message or message digest by using the private key in an asymmetric signing KMS key. To verify the signature, use the Verify operation, or use the public key in the same asymmetric KMS key outside of KMS. For information about asymmetric KMS keys, see Asymmetric KMS keys in the Key Management Service Developer Guide.
Digital signatures are generated and verified by using asymmetric key pair, such as an RSA, ECC, or ML-DSA pair that is represented by an asymmetric KMS key. The key owner (or an authorized user) uses their private key to sign a message. Anyone with the public key can verify that the message was signed with that particular private key and that the message hasn't changed since it was signed.
To use the Sign operation, provide the following information:
-
Use the
KeyIdparameter to identify an asymmetric KMS key with aKeyUsagevalue ofSIGN_VERIFY. To get theKeyUsagevalue of a KMS key, use the DescribeKey operation. The caller must havekms:Signpermission on the KMS key. -
Use the
Messageparameter to specify the message or message digest to sign. You can submit messages of up to 4096 bytes. To sign a larger message, generate a hash digest of the message, and then provide the hash digest in theMessageparameter. To indicate whether the message is a full message, a digest, or an ML-DSA EXTERNAL_MU, use theMessageTypeparameter. -
Choose a signing algorithm that is compatible with the KMS key.
When signing a message, be sure to record the KMS key and the signing algorithm. This information is required to verify the signature.
Best practices recommend that you limit the time during which any signature is effective. This deters an attack where the actor uses a signed message to establish validity repeatedly or long after the message is superseded. Signatures do not include a timestamp, but you can include a timestamp in the signed message to help you detect when its time to refresh the signature.
To verify the signature that this operation generates, use the Verify operation. Or use the GetPublicKey operation to download the public key and then use the public key to verify the signature outside of KMS.
The KMS key that you use for this operation must be in a compatible key state. For details, see Key states of KMS keys in the Key Management Service Developer Guide.
Cross-account use: Yes. To perform this operation with a KMS key in a different Amazon Web Services account, specify
the key ARN or alias ARN in the value of the KeyId parameter.
Required permissions: kms:Sign (key policy)
Related operations: Verify
Eventual consistency: The KMS API follows an eventual consistency model. For more information, see KMS eventual consistency.
Method Signature¶
METHODS /AWS1/IF_KMS~SIGN
IMPORTING
!IV_KEYID TYPE /AWS1/KMSKEYIDTYPE OPTIONAL
!IV_MESSAGE TYPE /AWS1/KMSPLAINTEXTTYPE OPTIONAL
!IV_MESSAGETYPE TYPE /AWS1/KMSMESSAGETYPE OPTIONAL
!IT_GRANTTOKENS TYPE /AWS1/CL_KMSGRANTTOKENLIST_W=>TT_GRANTTOKENLIST OPTIONAL
!IV_SIGNINGALGORITHM TYPE /AWS1/KMSSIGNINGALGORITHMSPEC OPTIONAL
!IV_DRYRUN TYPE /AWS1/KMSNULLABLEBOOLEANTYPE OPTIONAL
RETURNING
VALUE(OO_OUTPUT) TYPE REF TO /aws1/cl_kmssignresponse
RAISING
/AWS1/CX_KMSDEPENDENCYTMOUTEX
/AWS1/CX_KMSDISABLEDEXCEPTION
/AWS1/CX_KMSDRYRUNOPERATIONEX
/AWS1/CX_KMSINVGRANTTOKENEX
/AWS1/CX_KMSINVALIDKEYUSAGEEX
/AWS1/CX_KMSKEYUNAVAILEX
/AWS1/CX_KMSKMSINTERNALEX
/AWS1/CX_KMSKMSINVALIDSTATEEX
/AWS1/CX_KMSNOTFOUNDEXCEPTION
/AWS1/CX_KMSCLIENTEXC
/AWS1/CX_KMSSERVEREXC
/AWS1/CX_RT_TECHNICAL_GENERIC
/AWS1/CX_RT_SERVICE_GENERIC.
IMPORTING¶
Required arguments:¶
iv_keyid TYPE /AWS1/KMSKEYIDTYPE /AWS1/KMSKEYIDTYPE¶
Identifies an asymmetric KMS key. KMS uses the private key in the asymmetric KMS key to sign the message. The
KeyUsagetype of the KMS key must beSIGN_VERIFY. To find theKeyUsageof a KMS key, use the DescribeKey operation.To specify a KMS key, use its key ID, key ARN, alias name, or alias ARN. When using an alias name, prefix it with
"alias/". To specify a KMS key in a different Amazon Web Services account, you must use the key ARN or alias ARN.For example:
Key ID:
1234abcd-12ab-34cd-56ef-1234567890abKey ARN:
arn:aws:kms:us-east-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890abAlias name:
alias/ExampleAliasAlias ARN:
arn:aws:kms:us-east-2:111122223333:alias/ExampleAliasTo get the key ID and key ARN for a KMS key, use ListKeys or DescribeKey. To get the alias name and alias ARN, use ListAliases.
iv_message TYPE /AWS1/KMSPLAINTEXTTYPE /AWS1/KMSPLAINTEXTTYPE¶
Specifies the message or message digest to sign. Messages can be 0-4096 bytes. To sign a larger message, provide a message digest.
If you provide a message digest, use the
DIGESTvalue ofMessageTypeto prevent the digest from being hashed again while signing.
iv_signingalgorithm TYPE /AWS1/KMSSIGNINGALGORITHMSPEC /AWS1/KMSSIGNINGALGORITHMSPEC¶
Specifies the signing algorithm to use when signing the message.
Choose an algorithm that is compatible with the type and size of the specified asymmetric KMS key. When signing with RSA key pairs, RSASSA-PSS algorithms are preferred. We include RSASSA-PKCS1-v1_5 algorithms for compatibility with existing applications.
Optional arguments:¶
iv_messagetype TYPE /AWS1/KMSMESSAGETYPE /AWS1/KMSMESSAGETYPE¶
Tells KMS whether the value of the
Messageparameter should be hashed as part of the signing algorithm. UseRAWfor unhashed messages; useDIGESTfor message digests, which are already hashed; useEXTERNAL_MUfor 64-byte representative μ used in ML-DSA signing as defined in NIST FIPS 204 Section 6.2.When the value of
MessageTypeisRAW, KMS uses the standard signing algorithm, which begins with a hash function. When the value isDIGEST, KMS skips the hashing step in the signing algorithm. When the value isEXTERNAL_MUKMS skips the concatenated hashing of the public key hash and the message done in the ML-DSA signing algorithm.Use the
DIGESTorEXTERNAL_MUvalue only when the value of theMessageparameter is a message digest. If you use theDIGESTvalue with an unhashed message, the security of the signing operation can be compromised.When using ECC_NIST_EDWARDS25519 KMS keys:
ED25519_SHA_512 signing algorithm requires KMS
MessageType:RAWED25519_PH_SHA_512 signing algorithm requires KMS
MessageType:DIGESTWhen the value of
MessageTypeisDIGEST, the length of theMessagevalue must match the length of hashed messages for the specified signing algorithm.When the value of
MessageTypeisEXTERNAL_MUthe length of theMessagevalue must be 64 bytes.You can submit a message digest and omit the
MessageTypeor specifyRAWso the digest is hashed again while signing. However, this can cause verification failures when verifying with a system that assumes a single hash.The hashing algorithm that
Signuses is based on theSigningAlgorithmvalue.
Signing algorithms that end in SHA_256 use the SHA_256 hashing algorithm.
Signing algorithms that end in SHA_384 use the SHA_384 hashing algorithm.
Signing algorithms that end in SHA_512 use the SHA_512 hashing algorithm.
Signing algorithms that end in SHAKE_256 use the SHAKE_256 hashing algorithm.
SM2DSA uses the SM3 hashing algorithm. For details, see Offline verification with SM2 key pairs.
it_granttokens TYPE /AWS1/CL_KMSGRANTTOKENLIST_W=>TT_GRANTTOKENLIST TT_GRANTTOKENLIST¶
A list of grant tokens.
Use a grant token when your permission to call this operation comes from a new grant that has not yet achieved eventual consistency. For more information, see Grant token and Using a grant token in the Key Management Service Developer Guide.
iv_dryrun TYPE /AWS1/KMSNULLABLEBOOLEANTYPE /AWS1/KMSNULLABLEBOOLEANTYPE¶
Checks if your request will succeed.
DryRunis an optional parameter.To learn more about how to use this parameter, see Testing your permissions in the Key Management Service Developer Guide.
RETURNING¶
oo_output TYPE REF TO /aws1/cl_kmssignresponse /AWS1/CL_KMSSIGNRESPONSE¶
Domain /AWS1/RT_ACCOUNT_ID Primitive Type NUMC
Examples¶
Syntax Example¶
This is an example of the syntax for calling the method. It includes every possible argument and initializes every possible value. The data provided is not necessarily semantically accurate (for example the value "string" may be provided for something that is intended to be an instance ID, or in some cases two arguments may be mutually exclusive). The syntax shows the ABAP syntax for creating the various data structures.
DATA(lo_result) = lo_client->sign(
it_granttokens = VALUE /aws1/cl_kmsgranttokenlist_w=>tt_granttokenlist(
( new /aws1/cl_kmsgranttokenlist_w( |string| ) )
)
iv_dryrun = ABAP_TRUE
iv_keyid = |string|
iv_message = '5347567362473873563239796247513D'
iv_messagetype = |string|
iv_signingalgorithm = |string|
).
This is an example of reading all possible response values
lo_result = lo_result.
IF lo_result IS NOT INITIAL.
lv_keyidtype = lo_result->get_keyid( ).
lv_ciphertexttype = lo_result->get_signature( ).
lv_signingalgorithmspec = lo_result->get_signingalgorithm( ).
ENDIF.
To digitally sign a message digest with an asymmetric KMS key.¶
This operation uses the private key in an asymmetric RSA signing KMS key to generate a digital signature for a message digest. In this example, a large message was hashed and the resulting digest is provided in the Message parameter. To tell KMS not to hash the message again, the MessageType field is set to DIGEST
DATA(lo_result) = lo_client->sign(
iv_keyid = |alias/RSA_signing_key|
iv_message = '3C6D6573736167652064696765737420746F206265207369676E65643E'
iv_messagetype = |DIGEST|
iv_signingalgorithm = |RSASSA_PKCS1_V1_5_SHA_256|
).
To digitally sign a message with an asymmetric KMS key.¶
This operation uses the private key in an asymmetric elliptic curve (ECC) KMS key to generate a digital signature for a given message.
DATA(lo_result) = lo_client->sign(
iv_keyid = |alias/ECC_signing_key|
iv_message = '3C6D65737361676520746F206265207369676E65643E'
iv_messagetype = |RAW|
iv_signingalgorithm = |ECDSA_SHA_384|
).