Add Scaleway Key Manager KMS provider (scwkms)

[guillaume-ro-fr]

Name of feature:

Scaleway Key Manager (scwkms) KMS provider.

Adds a new go.step.sm/crypto/kms backend for Scaleway Key Manager, built on the official github.com/scaleway/scaleway-sdk-go SDK and modeled on the existing cloudkms / awskms providers.

It implements:

• apiv1.KeyManager: CreateKey, GetPublicKey, CreateSigner, Close
• crypto.Signer (digest-only signing, EC P-256/P-384 and RSA-PKCS1/RSA-PSS all SHA-256 except EC P-384/SHA-384)
• apiv1.Decrypter: RSA-OAEP-SHA256
• apiv1.KeyDeleter: DeleteKey

Pain or issue this feature alleviates:

step-ca / step users hosting keys on Scaleway had no way to use Scaleway Key Manager as a signing/decryption backend. This brings Scaleway to parity with the other cloud KMS providers (AWS, GCP, Azure), so a Scaleway-hosted key can back a
CA or signer through the same kms.New(...) entrypoint.

Why is this important to the project (if not answered above):

Broadens cloud KMS coverage with a popular European provider, using the same plugin model (self-registration via init() + apiv1.Register) and the same narrow-client/mock test pattern as the existing providers - no new conventions
introduced.

Is there documentation on how to use this feature? If so, where?

Package-level godoc on kms/scwkms. Usage mirrors the other providers via a
URI:

scwkms:key-id=<uuid>;region=<region>

with credentials resolved through the standard Scaleway precedence (config-file profile → env vars → explicit URI params: access-key, secret-key, project-id, organization-id, region, profile).

In what environments or workflows is this feature supported?

Anywhere the kms package is consumed (step-ca, step, step-kms-plugin) by blank-importing go.step.sm/crypto/kms/scwkms. Asymmetric signing keys (EC P-256/P-384, RSA-PKCS1 & RSA-PSS at 2048/3072/4096, all SHA-256) and RSA-OAEP-SHA256 decryption keys. Builds with and without the provider via the noscwkms build tag (stub registers a clear "compiled without Scaleway Key Manager support" error).

In what environments or workflows is this feature explicitly NOT supported (if any):

• Symmetric encryption and GenerateDataKey - out of scope (not part of the apiv1.KeyManager surface).
• Algorithms Scaleway does not offer: SHA-384/512 with RSA, ECDSA P-521, Ed25519 - these return an explicit error.
• RSA-OAEP with a non-SHA-256 hash or a label.

Note: the ECDSA signature DER-encoding and the RSA-PSS salt length cannot be validated by the mocked unit tests - they require a live integration test against a real Scaleway key to confirm signatures verify under the public key.
The signer defensively normalizes ECDSA signatures to ASN.1 DER to be correct regardless of Scaleway's wire format.

Non-standard public key PEM headers

The Scaleway Key Manager API returns public keys with non-standard PEM headers that pemutil.ParseKey does not accept out of the box:

• EC PUBLIC KEY - used for EC keys. The DER payload is a standard PKIX SubjectPublicKeyInfo; the header is rewritten to PUBLIC KEY before parsing with x509.ParsePKIXPublicKey.
• RSA PUBLIC KEY - used for RSA keys. The DER payload is a PKCS#1 RSAPublicKey structure; parsed directly with x509.ParsePKCS1PublicKey.

Both cases are handled in the parsePublicKeyPEM helper (scwkms.go), which is the single entry point for all PEM decoding in the package (GetPublicKey, Signer.preloadKey, Decrypter.preloadKey). Standard PUBLIC KEY headers pass through to pemutil.ParseKey unchanged.

Integration test results (step-kms-plugin)

Tested manually against a real Scaleway Key Manager account (region fr-par) using a custom build of step-kms-plugin with scwkms blank-imported and go.step.sm/crypto replaced with this branch.
All 8 supported key types were created and exercised with step-kms-plugin create followed by step-kms-plugin sign --verify:

Key type	Create	Sign + Verify
EC P-256 / SHA-256	✓	✓
EC P-384 / SHA-384	✓	✓
RSA-PKCS1 2048 / SHA-256	✓	✓
RSA-PKCS1 3072 / SHA-256	✓	✓
RSA-PKCS1 4096 / SHA-256	✓	✓
RSA-PSS 2048 / SHA-256	✓	✓
RSA-PSS 3072 / SHA-256	✓	✓
RSA-PSS 4096 / SHA-256	✓	✓

sign --verify confirms end-to-end correctness: the ECDSA signatures returned by Scaleway are already in ASN.1 DER format (the defensive raw → DER normalization path was not triggered), and the RSA-PSS salt length is compatible with Go's verifier.

Supporting links/other PRs/issues:

• Scaleway Key Manager API schema: https://www.scaleway.com/en/developers/api/key-manager/v1alpha1/
• SDK godoc: https://pkg.go.dev/github.com/scaleway/scaleway-sdk-go

Closes #1037

[CLAassistant]

All committers have signed the CLA.