Add legacy SCEP compatibility options

[ArtWachowski]

Name of feature:

Opt-in legacy SCEP compatibility options for authenticated attribute verification and RSA digestEncryptionAlgorithm encoding.

Pain or issue this feature alleviates:

Some legacy SCEP clients are not fully interoperable with the default PKCS#7 behavior used by smallstep/certificates.

Two compatibility issues were identified while investigating smallstep/certificates#1723:

1. Some legacy clients sign PKCS#7 authenticated attributes in their original encoded order instead of DER SET order. This causes request verification to fail with crypto/rsa: verification error.

2. Some legacy clients expect SCEP CertRep responses using:

rsaEncryption (1.2.840.113549.1.1.1)

as the SignerInfo.digestEncryptionAlgorithm, rather than:

sha1WithRSAEncryption (1.2.840.113549.1.1.5)

when SHA-1 and RSA are used.

This change exposes two independent SCEP provisioner compatibility options:

allowUnsortedAuthenticatedAttributes

and

legacyRSADigestEncryptionAlgorithm

Both options are disabled by default.

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

This allows step-ca SCEP provisioners to interoperate with legacy SCEP implementations without changing behavior for existing deployments.

The compatibility behavior is explicitly opt-in and can be enabled only for provisioners that require it.

The changes were tested successfully against a legacy SCEP client based on strongSwan 5.0.2, where certificate enrollment previously failed.

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

The options are configured on an SCEP provisioner, for example:

{
    "allowUnsortedAuthenticatedAttributes": true,
    "legacyRSADigestEncryptionAlgorithm": true
}

allowUnsortedAuthenticatedAttributes enables compatibility when parsing and verifying incoming SCEP PKI messages.

legacyRSADigestEncryptionAlgorithm causes signed SCEP CertRep responses to use rsaEncryption as the PKCS#7 SignerInfo.digestEncryptionAlgorithm.

Both options may be enabled independently.

In what environments or workflows is this feature supported?

SCEP provisioners using step-ca.

The compatibility options are intended for interoperability with legacy SCEP clients whose PKCS#7 encoding or verification expectations differ from current DER/RSA conventions.

The implementation has been tested with a legacy client based on strongSwan 5.0.2.

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

Neither compatibility behavior is enabled globally.

Provisioners that do not explicitly configure these options retain the existing SCEP parsing, verification, and response-signing behavior.

The options are intended as targeted compatibility mechanisms rather than changes to the default SCEP behavior.

Supporting links/other PRs/issues:

• Addresses the interoperability problem reported in smallstep/certificates#1723.

• Related legacy SCEP interoperability discussion: strongswan/strongswan#2753.

• Depends on the corresponding smallstep/pkcs7 PR providing:

  • opt-in verification of authenticated attributes in their encoded order
  • support for honoring an explicitly configured SignedData encryption algorithm in AddSignerChain()

• Depends on the corresponding smallstep/scep PR exposing the authenticated-attribute verification option through ParsePKIMessage.

💔Thank you!

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Artur Wachowski seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}