Post–Quantum Cryptography in ADSS Server–⁠Interoperability Validation

The practical deployment of Post-Quantum Cryptography is often related to algorithms, but the real conversation also needs to include how the algorithms are encoded into real-world structures.

Deeper than that, structural compliance alone is insufficient; interoperability needs to be demonstrated against independent cryptographic toolchains. This blog will delve into the topic of interoperability where PQC is concerned.

This is the second blog in a series. In the first article, I examined how ADSS Server integrates ML-DSA and ML-KEM into X.509 and CMS structures in accordance with RFC 9881 and RFC 9882.

In release 8.4 of ADSS Server, we performed cross-validation testing using:

• OpenSSL 3.6.1
• Bouncy Castle 1.83

This article walks through the validation process and the results.

1. Test Environment

Document this clearly — engineers care.

Example:

• ADSS Server 8.4
• ML-DSA-44 test hierarchies
• OpenSSL 3.6.1 (built with PQC support)
• Bouncy Castle 1.83
• Windows x86_64 test environment

No ADSS-specific validation tools were used during verification.

This reinforces independence.

2. X.509 Certificate Validation

2.1 Certificate Inspection (OpenSSL)

Example command:

openssl x509 -in ML-DSA-44_DocSig.cer -text -noout

What we verify:

• signatureAlgorithm OID
• subjectPublicKeyInfo.algorithm OID
• Public key length
• Certificate chain fields

Include output excerpt such as:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            1d:1d:9e:26:0f:18:b0:51:50:49:65:fc:df:14:3b:41
        Signature Algorithm: ML-DSA-44
        Issuer: C=GB, CN=ML-DSA-44_RootCA
        Validity
            Not Before: Feb  9 11:32:31 2026 GMT
            Not After : Feb  9 11:32:31 2027 GMT
        Subject: C=GB, CN=ML-DSA-44_DocSig
        Subject Public Key Info:
            Public Key Algorithm: ML-DSA-44
                ML-DSA-44 Public-Key:
                pub:
                    fd:e8:69:cb:58:81:9f:8d:5b:d5:9f:f2:0a:3f:0d:bc:
                                     ...... 
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier:
                83:95:36:A5:8C:47:0C:04:56:A0:5B:92:25:24:0C:D8:D5:4D:C8:4D
            X509v3 Subject Key Identifier:
                FB:72:1C:D2:89:7A:B6:41:C6:88:91:91:F5:10:12:DD:84:EC:6B:7C
    Signature Algorithm: ML-DSA-44
    Signature Value:
        66:cc:4e:c0:62:76:33:af:6f:9d:d8:ab:87:be:cb:c8:57:84:ea:54:d4:c8:4f:97:
                        ..............

This confirms that:

• OpenSSL recognises the ML-DSA OID.
• The certificate’s AlgorithmIdentifier fields are correctly encoded.
• The SubjectPublicKeyInfo structure is parsed without ASN.1 errors.
• The public key length matches the selected ML-DSA parameter set.

Parsing is often the first failure point when ASN.1 encoding is incorrect. No structural errors were encountered.

2.2 Certificate Path Validation

Then validate chain:

openssl verify -CAfile ML-DSA-44_RootCA.cer ML-DSA-44_DocSig.cer

Expected result:

ML-DSA-44_DocSig.cer: OK

This demonstrates that:

• OpenSSL successfully built the PKIX certification path.
• ML-DSA signatures were cryptographically verified.
• The trust anchor model remains unchanged.
• No classical fallback mechanisms were required.

Importantly, PKIX path validation logic did not require modification. Only the signature primitive differed.

This confirms that ML-DSA integrates cleanly into the existing RFC 5280 trust model.

3. CRL Validation

Inspect CRL:

openssl crl -in ML-DSA-44_RootCA.crl -text -noout

Include output excerpt such as:

Certificate Revocation List (CRL):
    Version 2 (0x1)
    Signature Algorithm: ML-DSA-44
    Issuer: C=GB, CN=ML-DSA-44_RootCA
    Last Update: Feb  9 11:06:01 2026 GMT
    Next Update: Feb 10 11:06:01 2026 GMT
    CRL extensions:
        X509v3 Authority Key Identifier:
            83:95:36:A5:8C:47:0C:04:56:A0:5B:92:25:24:0C:D8:D5:4D:C8:4D
        X509v3 CRL Number:
            1
No Revoked Certificates.
    Signature Algorithm: ML-DSA-44
    Signature Value:
        7d:56:c5:53:22:60:69:de:04:c4:f7:08:3d:84:2c:60:12:d7:34:f7:49:ad:62:77:
        39:d1:8f:11:33:f3:82:26:96:ff:25:98:af:97:fb:48:fb:4e:07:79:5d:b1:6e:f5:
        a1:81:19:5a:2a:8a:91:ec:7a:4a:84:92:7d:6e:a8:25:93:4c:4f:4c:29:7c:c8:89:
        48:f4:92:cf:fd:9d:d2:dd:4e:fb:a2:71:96:c1:9e:86:ac:2b:1f:fc:a2:8f:de:df:

The CRL parsed correctly, displaying:

• ML-DSA signature algorithm identifier
• Valid issuer fields
• Properly encoded revoked certificate entries

To validate revocation processing:

openssl verify -crl_check -CRLfile ML-DSA-44_RootCA.crl -CAfile
ML-DSA-44_RootCA.cer  ML-DSA-44_DocSig.cer

This confirms:

• The CRL signature was successfully verified using ML-DSA.
• Revocation status processing remains unchanged.
• No structural deviations from RFC 5280 CRL semantics occurred.

The only observable difference compared to classical CRLs is increased signature size and overall artefact size.

Operationally, revocation handling behaves identically.

4. CMS Signature Validation (RFC 9882)

CMS signatures were generated using by ADSS Server using ML-DSA and validated using OpenSSL.

4.1 CMS Signature Verification (OpenSSL)

openssl cms -verify -in ML-DSA-44_DocSig.cms -inform DER -CAfile
ML-DSA-44_RootCA.cer -out unsigned.txt

Expected output:

CMS Verification successful

This confirms that:

• The CMS SignedData structure was parsed correctly.
• The SignerInfo.signatureAlgorithm OID was recognised.
• The ML-DSA signature over signedAttrs was verified.
• No proprietary CMS attributes were introduced.

CMS interoperability is critical because document signing ecosystems depend heavily on strict ASN.1 conformance.

The validation demonstrates that RFC 9882 integration within ADSS Server is structurally correct and compatible with independent CMS implementations.

5. OCSP Response Validation

OCSP Response generated by ADSS Server is validated using OpenSSL command below:

openssl ocsp -respin ML-DSA-44_OCSP-Response.ber -text -noverify

Note: Long output so not included. One can execute above command using OCSP response shared in previous blog.

The BasicOCSPResponse structure parsed correctly, including:

• ResponseData
• SignatureAlgorithm (ML-DSA OID)
• BIT STRING signature value

This confirms:

• OpenSSL recognises ML-DSA for OCSP signature verification.
• PKIX-based OCSP semantics remain intact.
• No custom extensions or encoding adjustments were required.

OCSP is often sensitive to structural inconsistencies. Successful parsing and verification indicate full PKIX compatibility.

6. Timestamp Token Validation

Timestamp tokens generated by ADSS Server (CMS-based TST) were validated using:

openssl ts -reply -in ML-DSA-44_Timestamp-Token.pkcs7 -token_in -text

Output excerpt such as:

Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified

TST info:
Version: 1
Policy OID: 1.2.3.4.5
Hash Algorithm: sha256
Message data:
    0000 - a5 dd f8 f1 4e be a9 78-7b cb 50 a4 5b 37 a4 ff    ....N..x{.P.[7..
    0010 - 31 08 ca 38 00 7d 24 21-52 2f cd fc e6 1f 2e d8    1..8.}$!R/......
Serial number: 0xA109E38C4BC7
Time stamp: Feb  9 12:00:44 2026 GMT
Accuracy: unspecified
Ordering: no
Nonce: 0x0184F0F3
TSA: DirName:/C=GB/CN=ML-DSA-44_TSA
Extensions:

Successful validation confirms:

• TSTInfo was parsed correctly.
• The embedded CMS SignedData structure was valid.
• ML-DSA signature verification succeeded.
• Long-term validation (LTV) workflows remain structurally viable.

This is particularly important for regulated environments where timestamp validation must remain independent and verifiable decades into the future.

7. Bouncy Castle Validation

To validate Java ecosystem compatibility, we repeated testing using Bouncy Castle 1.83.

7.1 Certificate Validation

Using Bouncy Castle PKIX APIs:

• Loaded ML-DSA certificate chain.
• Constructed a CertPath.
• Executed PKIX path validation.

Results:

• No ASN.1 parsing exceptions.
• ML-DSA signatures verified successfully.
• Path validation completed without structural errors.

This confirms that Java-based PKI stacks can process ML-DSA certificates issued by ADSS Server.

7.2 CMS Validation

Using Bouncy Castle CMS APIs:

• Parsed CMSSignedData object.
• Extracted SignerInformation.
• Verified ML-DSA signature.

Results:

• Signature validated successfully.
• AlgorithmIdentifier was recognised.
• No compatibility issues observed.

This validates CMS interoperability in Java-based document processing environments.

8. What Was Actually Proven

This section is important — it elevates the blog above “it worked”.

We validated:

• ✓ Correct OID usage
• ✓ Correct ASN.1 encoding
• ✓ Proper BIT STRING / OCTET STRING handling
• ✓ PKIX path building compatibility
• ✓ CRL processing compatibility
• ✓ CMS parsing compatibility
• ✓ OCSP response validation
• ✓ Timestamp token validation

• No proprietary extensions.
• No ADSS-specific validation logic.
• No structural deviations.

9. Observations from Testing

Architect-level commentary:

• Signature verification time increases relative to ECDSA
• Artefact size increases
• Parsing logic unchanged
• PKIX validation semantics unchanged
• No compatibility regressions observed

Emphasise

The ecosystem impact is performance and size — not structure.

Conclusion

Interoperability is the primary barrier to PQC adoption.

The validation performed with OpenSSL 3.6.1 and Bouncy Castle 1.83 demonstrates that ADSS Server 8.4 generates ML-DSA-based artefacts that:

• Conform to RFC 9881 and RFC 9882
• Integrate into existing PKIX validation models
• Validate using mainstream cryptographic toolchains
• Require no proprietary modifications

In the next article in this series, I will examine performance benchmarking of ML-DSA-44 within ADSS Server, comparing classical and post-quantum operations under software-based workloads.