Separation of IACA Root Certificate and Document Signer Certificate

[dalebowie]

In my experimentation with this library, it seems there is a restriction that either of the following must be true:

1. The Issuer's Document Signer Certificate that is embedded within a credential is the same certificate as the IACA Root Certificate that they would share with a VICAL. I guess this doesn't explicitly violate the ISO 18013-5 standard, but in my opinion defeats the point of separating these two certificate profiles out.
2. All Verifiers know the Document Signer Certificates of all Issuers. This goes against what theVerifier constructor documentation implies and again defeats the point of having the two certificate profiles in the first place.

It feels like a solution to this might be to prepend the issuer certificate from a presented mdoc to the front of the list of certificates that go to verifyX509Chain. This would have to only be done in situations where the issuer certificate is not self-signed otherwise it defeats the purpose of having a trusted verifier list of certificates.

[siacomuzzi]

I don't know if I fully understand the query, but yes, the issuersRootCertificates property works for non-self-signed certificates. This is essentially a way to complete the embedded certificate chain (x5chain) by specifying the missing certificate authorities.

See implementation details.

If you are working with self-signed certificates, consider using the disableCertificateChainValidation flag:

const verifier = new Verifier([]);
const mdoc = await verifier.verify(encodedDeviceResponse, {
  disableCertificateChainValidation: true,
  // ...
});

[dalebowie]

Here's some sample code derived from the README to demonstrate this issue:

import { MDoc, Document, DeviceResponse, Verifier, DataItem } from "@auth0/mdl";
import * as crypto from "crypto";
import * as jose from 'jose';
(async () => {
    const cborx = await import("cbor-x");
    cborx.addExtension({
        Class: DataItem,
        tag: 24,
        encode: (instance: DataItem<any>, encode) => encode(instance.buffer),
        decode: (buffer: Uint8Array): object => new DataItem({ buffer }),
    });

    const devicePrivatePEM = "-----BEGIN PRIVATE KEY-----\nMC4CAQAwBQYDK2VwBCIEIKWuHzvetdYpe5cErlOrU1bipA0OFtbBpJBdXCzRIVbz\n-----END PRIVATE KEY-----";
    const devicePrivateKey = await jose.exportJWK(crypto.createPrivateKey({ key: devicePrivatePEM }));
    const devicePublicKey: jose.JWK = {
        kty: devicePrivateKey.kty,
        crv: devicePrivateKey.crv,
        x: devicePrivateKey.x,
    };

    // An example IACA Root Certificate that the Issuer has shared publicly via
    // a VICAL
    const issuer_iacaRootCertificate = "-----BEGIN CERTIFICATE-----\nMIIBizCCAT2gAwIBAgIULJ8NAuj+Bmp80cm36oRB8+lXf/IwBQYDK2VwMDsxCzAJ\nBgNVBAYTAlVTMQwwCgYDVQQKDANNREwxHjAcBgNVBAMMFUlBQ0EgUm9vdCBDZXJ0\naWZpY2F0ZTAeFw0yNTAxMTUyMjM3MjdaFw0yNjAxMTUyMjM3MjdaMDsxCzAJBgNV\nBAYTAlVTMQwwCgYDVQQKDANNREwxHjAcBgNVBAMMFUlBQ0EgUm9vdCBDZXJ0aWZp\nY2F0ZTAqMAUGAytlcAMhANslFC5TzNBT7pyb3UlZ/zi28p6fJfu7Z4k5gJXEZt9A\no1MwUTAdBgNVHQ4EFgQU++C6zWkwyAP5jLQPPpnI46f2GS4wHwYDVR0jBBgwFoAU\n++C6zWkwyAP5jLQPPpnI46f2GS4wDwYDVR0TAQH/BAUwAwEB/zAFBgMrZXADQQA/\nmjof4gBsWGUS3wIV/7Mk0X18fCaQFNO3kJ0TPBRudm3UeIFjzkE1JRdp467sAu+v\nRuI8zrBqKTihvyE3+SYB\n-----END CERTIFICATE-----";
    const issuer_iacaRootKey_pem = "-----BEGIN PRIVATE KEY-----\nMC4CAQAwBQYDK2VwBCIEIBTrddqB1sH79JSptJGe+gGf/n7HU7Vvb61rue0RPqG0\n-----END PRIVATE KEY-----";
    const issuer_iacaRootKey = await jose.exportJWK(crypto.createPrivateKey({ key: issuer_iacaRootKey_pem }));

    // An example Document Signing Certificate that has been signed by the IACA
    // Root Certificate above, but this is only included in the minted
    // credential and not separately shared publicly with Verifiers.
    const issuer_documentSigningCertificate = "-----BEGIN CERTIFICATE-----\nMIIBgTCCATOgAwIBAgIUbFaxgDYXY1svQUoxs+5s6VbTr4AwBQYDK2VwMDsxCzAJ\nBgNVBAYTAlVTMQwwCgYDVQQKDANNREwxHjAcBgNVBAMMFUlBQ0EgUm9vdCBDZXJ0\naWZpY2F0ZTAeFw0yNTAxMTUyMjM3MzNaFw0yNjAxMTUyMjM3MzNaMEIxCzAJBgNV\nBAYTAlVTMQwwCgYDVQQKDANNREwxJTAjBgNVBAMMHERvY3VtZW50IFNpZ25pbmcg\nQ2VydGlmaWNhdGUwKjAFBgMrZXADIQC0xLQFLnOjbb7/DAK3hCSpBfdH/U/hS/ll\nxDiFdZRWh6NCMEAwHQYDVR0OBBYEFMJLi7pQJ+HBgxnYE2ZL3fi9btiMMB8GA1Ud\nIwQYMBaAFPvgus1pMMgD+Yy0Dz6ZyOOn9hkuMAUGAytlcANBAIyKsZCDmE2OXbuk\nMVrc2pNdFRhG2giOimtuhaM3Fu5+HVvpnS/lzuJPgcib4bOS2xHlTCeEZEcx8eAU\naYScbAI=\n-----END CERTIFICATE-----";
    const issuer_documentSigningKey_pem = "-----BEGIN PRIVATE KEY-----\nMC4CAQAwBQYDK2VwBCIEIITBiHzi9TtoFsEanLlN0yD+WRWrozcnhrrAuRFnp3T0\n-----END PRIVATE KEY-----";
    const issuer_documentSigningKey = await jose.exportJWK(crypto.createPrivateKey({ key: issuer_documentSigningKey_pem }));

    const alg = "EdDSA";

    let i = 1;

    const scenarios = [
        {
            title: "One certificate",
            description: "Issuer publishes the certificate that is directly used for signing credentials for Verifiers to consume. This is not realistic given the ISO recommendation to keep the Document Signer Certificate lifetime to \"a few weeks\".",
            issuerPrivateKey: issuer_iacaRootKey,
            issuerCertificate: issuer_iacaRootCertificate,
            verifierTrustedCertificates: [ issuer_iacaRootCertificate ],
        },
        {
            title: "Trust IACA, use DocSigner",
            description: "Verifier trusts the IACA Root Certificate only. The Document Signer Certificate is used to mint credentials. This should work, however it currently fails.",
            issuerPrivateKey: issuer_documentSigningKey,
            issuerCertificate: issuer_documentSigningCertificate,
            verifierTrustedCertificates: [ issuer_iacaRootCertificate ],
        },
        {
            title: "Negative test scenario",
            description: "A negative test case to protect against with the proposed implementation. When the Document Signer Certificate is self-signed, the Verifier shouldn't automatically trust the certificate within the credential itself.",
            issuerPrivateKey: issuer_iacaRootKey,
            issuerCertificate: issuer_iacaRootCertificate,
            verifierTrustedCertificates: [  ],
        },
    ];
    for (const scenario of scenarios) {
        let issuerMDoc;
        let deviceResponseMDoc;

        /**
         * This is what the MDL issuer does to generate a credential:
         */
        {
            const document = new Document('org.iso.18013.5.1.mDL')
                .addIssuerNameSpace('org.iso.18013.5.1', {
                    family_name: 'Jones',
                    given_name: 'Ava',
                    birth_date: '2007-03-25',
                })
                .useDigestAlgorithm('SHA-256')
                .addValidityInfo({
                    signed: new Date(),
                })
                .addDeviceKeyInfo({ deviceKey: devicePublicKey });
            const signedDoc = await document.sign({
                issuerPrivateKey: scenario.issuerPrivateKey,
                issuerCertificate: scenario.issuerCertificate,
                alg,
            });

            issuerMDoc = new MDoc([signedDoc]).encode();
        }

        /**
         * This is what the DEVICE does to generate a response...
         */
        {
            let presentationDefinition = {
                id: 'family_name_only',
                input_descriptors: [
                    {
                    id: 'org.iso.18013.5.1.mDL',
                    format: { mso_mdoc: { alg: ['EdDSA', 'ES256'] } },
                    constraints: {
                        limit_disclosure: 'required',
                        fields: [{
                            path: ["$['org.iso.18013.5.1']['family_name']"],
                            intent_to_retain: false,
                        }],
                    },
                    },
                ],
            };

            deviceResponseMDoc = await DeviceResponse.from(issuerMDoc)
            .usingPresentationDefinition(presentationDefinition)
            .usingSessionTranscriptForOID4VP("", "", "", "")
            .authenticateWithSignature(devicePrivateKey, alg)
            .sign();

            const verifier = new Verifier(scenario.verifierTrustedCertificates);

            const diagnosticInfo = await verifier.getDiagnosticInformation(deviceResponseMDoc.encode(), {});
            console.log("Scenario " + i + ":", scenario.title);
            console.log("----");
            console.log(scenario.description);
            console.log("\nCurrent implementation: ", diagnosticInfo.issuerSignature, "\n");

            const augmented: string[] = [];
            if (diagnosticInfo.issuerCertificate) {
                augmented.push(diagnosticInfo.issuerCertificate.pem);
            }
            augmented.push(... JSON.parse(JSON.stringify(scenario.verifierTrustedCertificates)));
            const augmentedVerifier = new Verifier(augmented);
            const augDiagnosticInfo = await augmentedVerifier.getDiagnosticInformation(deviceResponseMDoc.encode(), {});
            console.log("Proposed implementation: ", augDiagnosticInfo.issuerSignature, "\n");
            i++;
        }
    }
})();

The output is as follows:

Scenario 1: One certificate
----
Issuer publishes the certificate that is directly used for signing credentials for Verifiers to consume. This is not realistic given the ISO recommendation to keep the Document Signer Certificate lifetime to "a few weeks".

Current implementation:  {
  alg: 'EdDSA',
  isValid: true,
  reasons: [],
  digests: { 'org.iso.18013.5.1': 5 }
} 

Proposed implementation:  {
  alg: 'EdDSA',
  isValid: true,
  reasons: [],
  digests: { 'org.iso.18013.5.1': 5 }
} 

Scenario 2: Trust IACA, use DocSigner
----
Verifier trusts the IACA Root Certificate only. The Document Signer Certificate is used to mint credentials. This should work, however it currently fails.

Current implementation:  {
  alg: 'EdDSA',
  isValid: false,
  reasons: [ 'No valid certificate paths found' ],
  digests: { 'org.iso.18013.5.1': 5 }
} 

Proposed implementation:  {
  alg: 'EdDSA',
  isValid: true,
  reasons: [],
  digests: { 'org.iso.18013.5.1': 5 }
} 

Scenario 3: Negative test scenario
----
A negative test case to protect against with the proposed implementation. When the Document Signer Certificate is self-signed, the Verifier shouldn't automatically trust the certificate within the credential itself.

Current implementation:  {
  alg: 'EdDSA',
  isValid: false,
  reasons: [ 'No valid certificate paths found' ],
  digests: { 'org.iso.18013.5.1': 5 }
} 

Proposed implementation:  {
  alg: 'EdDSA',
  isValid: true,
  reasons: [],
  digests: { 'org.iso.18013.5.1': 5 }
}

So basically scenario 1 is what the library supports today. Scenario 2 is the one that I think that needs to be addressed, but in doing so we wouldn't want scenario 3 to start working. Does that make sense?

[siacomuzzi]

Thank you for the very detailed explanation, I really appreciate it.

Scenario 2

This use case should be supported by the library.
Given that you are getting the 'No valid certificate paths found' error, and after a quick check I confirmed that issuer_iacaRootCertificate and issuer_documentSigningCertificate are completing the certificate chain, could you please confirm whether issuer_documentSigningKey_pem corresponds to issuer_documentSigningCertificate?
In any case, I will proceed to debug the certificate validation on my end.

Scenario 3

Self-signed certificates are not supported, that's why in your test results the "current implementation" is returning isValid: false. You have two options here:

• Include the self-signed certificate as part of the verifierTrustedCertificates array.
• Set the disableCertificateChainValidation: true in non-production environments.

[dalebowie]

Scenario 2... yes, they do correspond. I think these were the commands I used to generate the full chain and keys if you want to replace them just to make sure:

openssl req -x509 -newkey ed25519 -keyout IACA_key.pem -sha256 -out IACA_cert.pem -days 365 -nodes -subj "/C=US/O=MDL/CN=IACA Root Certificate"
openssl req -new -newkey ed25519 -keyout DocSigner_key.pem -sha256 -out DocSigner_req.pem -nodes -subj "/C=US/O=MDL/CN=Document Signing Certificate"
openssl x509 -req -in DocSigner_req.pem -CA IACA_cert.pem -CAkey IACA_key.pem -CAcreateserial -out DocSigner_cert.pem -days 365

Scenario 3... just to be clear, the only reason why I included this is because my proposed solution in the first comment would have made it validate successfully if care wasn't taken. Validation should always fail for this scenario both before and after the fix.

[siacomuzzi]

Scenario 2
I just found that the library we are using to validate the certificate chain is not supporting Ed25519 keys in certificate authority certs:

Unsupported signature algorithm: 1.3.101.112

https://github.com/PeculiarVentures/PKI.js/blob/91c596be220c5010b38415a68bd100942dfd321e/src/CryptoEngine/CryptoEngine.ts#L1434-L1451

If you update the command to generate the root certificate (replacing -newkey ed25519 with a supported type like -newkey rsa:2048), the verification will return the expected result.

openssl req -x509 -newkey rsa:2048 -keyout IACA_key.pem -sha256 -out IACA_cert.pem -days 365 -nodes -subj "/C=US/O=MDL/CN=IACA Root Certificate"

# another option (ecdsa-with-SHA512)
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:secp521r1 -keyout IACA_key.pem -sha512 -out IACA_cert.pem -days 365 -nodes -subj "/C=US/O=MDL/CN=IACA Root Certificate"

We need to improve the error messages. And maybe configure a different crypto engine to be used with PKIjs lib.

[dalebowie]

Good find with RSA working, but unfortunately that would be against B.1.2 of the ISO standard where the table refers to the public key algorithm being an elliptic curve for IACA root certificates.

[siacomuzzi]

Yeah, as I mentioned earlier, we need to configure a different crypto engine to add support for more elliptic curve algorithms, not just the 1.2.840.10045.4.* ones (like ecdsa-with-SHA512).

Regarding the ISO standard, it mentions the 1.2.840.10045.2.1 family, however, (and just fyi) please note that ed25519 does not belong to it.

[siacomuzzi]

I reviewed section B.1.2 of the ISO standard and updated your first OpenSSL command to comply with the IACA root certificate requirements (feedback is welcome):

openssl req -x509 -newkey ec:<(openssl ecparam -name secp521r1) \
  -keyout IACA_key.pem -out IACA_cert.pem -nodes -sha512 \
  -days 3650 -config openssl.cnf -extensions v3_req

where openssl.cnf file has the following content:

[ req ]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[ req_distinguished_name ]
C = US
O = MDL
CN = IACA Root Certificate

[ v3_req ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = critical, CA:true
keyUsage = critical, keyCertSign, cRLSign

You can run openssl x509 -in IACA_cert.pem -text -noout to list all certificate components.

Then, run the other 2 original commands:

openssl req -new -newkey ed25519 -keyout DocSigner_key.pem -sha256 -out DocSigner_req.pem -nodes -subj "/C=US/O=MDL/CN=Document Signing Certificate"
openssl x509 -req -in DocSigner_req.pem -CA IACA_cert.pem -CAkey IACA_key.pem -CAcreateserial -out DocSigner_cert.pem -days 365

By using these certificates, you'll be able to resolve scenario 2.