Quantum-resistant signing on AWS, Part 2: Enforce your ML-DSA algorithm policy with SCPs and IAM

What it is

AWS's worked example of enforcing a PQC algorithm policy: ML-DSA-65 and ML-DSA-87 approved, ML-DSA-44 excluded. The post says the exclusion is a standardization choice, not a security judgment. The mechanics work for any allow/deny split. The policy JSON did not survive in the fetched text, so the exact statements must be taken from the original post.

How it works

• KMS exposes three key specs (ML_DSA_44, ML_DSA_65, ML_DSA_87) that all sign with ML_DSA_SHAKE_256. Only kms:KeySpec can tell them apart.
• kms:KeySpec is evaluated on CreateKey, ReplicateKey, Sign, Verify and GetPublicKey. The post says testing confirmed it on all three usage actions.
• The condition value uses underscores: ML_DSA_44, not ML-DSA-44.
• The most robust single control is blocking creation. With no ML-DSA-44 KMS key, none can sign or become a certificate subject key.

flowchart TD
    A[Need to block ML-DSA-44] --> B{Surface}
    B -->|KMS keys| C[kms:KeySpec deny: SCP / IAM / boundary / key policy]
    B -->|Private CA| D[No condition key]
    B -->|ACM import, IAM upload| E[Not algorithm-aware]
    D --> F[Restrict who creates CAs, pin algorithm in pipeline]
    E --> G[Deny import/upload unless required]
    F --> H[CloudTrail + Config drift detection]
    G --> H

Preconditions / Affected

• SCPs do not apply to the management account, so keep ML-DSA-44-capable workloads out of it.
• These controls only cover AWS service APIs (KMS, Private CA, ACM). They cannot govern OpenSSL or application signing on EC2, containers or Lambda. They also cannot govern OpenSSH's ssh-mldsa44-ed25519.
• CloudFront, API Gateway and IAM Roles Anywhere are not covered.

What to do

• KMS creation and use: attach a kms:KeySpec deny at the org root or an OU as an SCP. Include kms:ReplicateKey in the creation deny for multi-Region keys.
• Usage deny: limit it to kms:Sign, kms:Verify and kms:GetPublicKey. Do not use kms:*. It would also block DescribeKey, DisableKey and ScheduleKeyDeletion, locking you out of cleaning up the keys.
• Per-account flexibility: use permission boundaries. They only bind principals that carry them, so enforce attachment with an SCP.
• Deny iam:CreateRole, iam:CreateUser, iam:PutRolePermissionsBoundary and iam:PutUserPermissionsBoundary unless iam:PermissionsBoundary matches the approved boundary.
• Deny iam:DeleteRolePermissionsBoundary and iam:DeleteUserPermissionsBoundary outright.
• Periodically probe for non-conforming principals.
• Key policy backstop: the same deny works in a key policy, but it needs a Principal element, for example "Principal": {"AWS": "*"}.
• Private CA:
• acm-pca:CreateCertificateAuthority has no algorithm condition key. Deny it via SCP except for a trusted pipeline role.
• Hard-code the algorithm in that pipeline. Set KeyAlgorithm and SigningAlgorithm to the same value, such as ML_DSA_65. Private CA rejects ML_DSA_SHAKE_256.
• Pin the CSR key algorithm in the same pipeline. Private CA copies the CSR subject key without validating its algorithm.
• Don't rely on older AWS CLI help for valid values.
• Import and upload: deny acm:ImportCertificate and iam:UploadServerCertificate where not needed. AWS says iam:UploadServerCertificate is meant only for Regions or partitions without ACM.
• ACM leaf certificates: acm:KeyAlgorithm on acm:RequestCertificate can allow-list algorithms. Use StringNotEqualsIfExists to deny only requests that specify a bad algorithm. Plain StringNotEquals also denies requests that omit the key.
• ELB: listener APIs reference certificates only by ARN, so no SCP can inspect the algorithm. Control the certificate material instead. elasticloadbalancing:SecurityPolicy can constrain TLS policies.
• Detection:
• CloudTrail logs the KeySpec on kms:CreateKey and the signing algorithm on CreateCertificateAuthority.
• Listener events do not record the certificate's algorithm. Use AWS Config to evaluate bound or imported certificates.
• Finding existing keys: KMS has no server-side key-spec filter. Enumerate with ListKeys and DescribeKey, or query AWS Config.

Caveats

• Naming the excluded variant is default-allow: a new variant stays usable until you add it to the deny. The alternative is StringNotEquals against the approved list, which blocks new variants until approved. Part 1's family-level SCP uses that shape, denying any signing key whose spec isn't ML_DSA_*. The post pairs the deny-list with detection and periodic review.
• A blanket root SCP has no exception path and can break IaC or tests.
• Before disabling or deleting existing keys, confirm they signed nothing you still need to verify. Deletion makes verification impossible.
• ACM and ELB do not accept ML-DSA certificates at the time of writing, so those controls are forward-looking. The post tells you to validate them before relying on them.
• The policies are illustrative. Test them outside production.