[API Proposal]: Support for ITU-T X.509 Alternative Signature

[dorssel]

Background and motivation

ITU-T Recommendation X.509 (10/2019) Section 9.8 specifies an additional signature to be embedded in the certificate to transition to PQ. It is different from composite signatures (draft-ietf-lamps-pq-composite-sigs) in that it allows clients that are not yet PQ-aware to understand the certificate as an old (classic RSA/ECC) certificate, while modern clients can use/verify both signatures (much like composite signatures).

The use case is different: composite signatures are better when you want to enforce PQ (more like a "critical" extension), whereas alternative signatures are opt-in ("non-critical" extension).

E.g., Bouncy Castle has support for this. It does not require crypto-library support in the sense that the library should handle the additional certificate extensions. The additional signature can be added by managed code (where the signature itself is created by the crypto-library, of course), and likewise for verification.

API Proposal

namespace System.Security.Cryptography.X509Certificates;

public class X509SignatureGenerator
{
    public static CreateForAlternativeSignature(CompositeMLDsa key);
}

I don't think additional API is required. And this utilizes the existing CompositeMLDsa keys, although it will be used differently: when signing (CertificateRequest.Create, etc.), the signature generator class would be recognized as "For Alternative Signatures", which would use the MLDsa key part for the ITU-T certificate extensions, followed by the outer "classical" signature.

Of course, certificate validation (e.g. X509Chain) should recognize the ITU-T certificate extensions for alternative signatures and validate the signature.

API Usage

CompositeMLDsa compositeKey;
signatureGenerator = X509SignatureGenerator.CreateForAlternativeSignature(compositeKey);
CertificateRequest request;
request.CreateSigningRequest(signatureGenerator);
request.Create(signatureGenerator);

Alternative Designs

Alternatively, the user could generate a normal CompositeMLDsa certificate request (not implemented yet, but already planned) and manually add the id-ce-altSignatureAlgorithm extension (or set a flag), after which the certificate would use the CompositeMLDsa key just as a container for essentially two independent key parts.

Risks

I don't see breaking changes in the existing API, but certificate validation is touched everywhere in the code.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[bartonjs]

.NET doesn't do X.509 signature verification -- we count on the underlying OS to do that for us. Just at a cursory glance, I don't see any support in OpenSSL for these extensions (they've included the extensions OIDs in their known-oids list (https://github.com/openssl/openssl/blob/7e05e8d6a3fa53ab18d30cdea18cfe93c7a366ec/include/openssl/obj_mac.h#L2903-L2916), but I don't see any code using them).

I don't think the indicated API would be sufficient, because using alternative signatures requires:

• Creating and adding a subjectAltPublicKeyInfo extension
• Creating and adding an altSignatureAlgorithm extension
• Taking the proto-certificate at that point, building it into a truncated Certificate (tbsCertificate and (outer) signatureAlgorithm, but no signature... if I read that correctly), generating the signature thereof
• Taking the previous signature and creating an altSignatureValue extension, and adding it to the builder/request-info
• Then now signing that.

X509SignatureGenerator is just a wrapper over underlying SignData methods, it doesn't assemble the tbsCertificate (the caller does). So X509SignatureGenerator can't implement the alternative signing algorithm... that's the caller's job. So that would be something like CertificateRequest.AddAlternativeSignature(KeyType alternativeKey), to do all of that above work. Of course, as mentioned, right now there doesn't seem to be support in the underlying OS libraries to verify it...

---

Alternatively, the user could generate a normal CompositeMLDsa certificate request (not implemented yet, but already planned)

That shipped as part of .NET 10... https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.x509certificates.certificaterequest.-ctor?view=net-10.0#system-security-cryptography-x509certificates-certificaterequest-ctor(system-security-cryptography-x509certificates-x500distinguishedname-system-security-cryptography-compositemldsa)

It's [Experimental] in 10, but the API is there.