Adding QSC sig chain verification to test server

[pi-314159]

Currently, the signature of all server certificates installed on the interop test server is sha256WithRSAEncryption. I propose that we add some new ports that support QSC signature. For example, we can generate a Dilithium intermediate CA and use it to sign server certificates. By doing this, we can test the quantum-safe chain.

[baentsch]

Currently, the signature of all server certificates installed on the interop test server is sha256WithRSAEncryption.

How did you come to this conclusion? We (already should) have a full matrix of ports with all OQS KEM and OQS SIG algorithms generated by this code. Server certs on most ports should be OQS sigs, e.g., Dilithium2 starting at port 6086....

Doing a quick check using openssl s_client to one of those ports does seem to confirm this (is working as intended):

subject=CN=test.openquantumsafe.org
issuer=CN=oqstest_CA
---
No client certificate CA names sent
Peer signature type: dilithium2
---
SSL handshake has read 6416 bytes and written 1941 bytes
Verification: OK

These are also sizes in line with a Dilithium2 sig being used, not an RSA one. What am I overlooking?

[pi-314159]

@baentsch I mean the signature algorithm, not the public key algorithm.

Below is one of the server certificates (public key algorithm dilithium2) installed on the interop server, and you can see the signature algorithm is sha256WithRSAEncryption because it is signed by an RSA certificate authority

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            33:e2:92:c8:fc:5a:e4:df:39:df:97:a2:5e:30:43:bd:65:47:6e:3e
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = oqstest_CA
        Validity
            Not Before: Oct 25 13:20:14 2023 GMT
            Not After : Oct 24 13:20:14 2024 GMT
        Subject: CN = test.openquantumsafe.org
        Subject Public Key Info:
            Public Key Algorithm: dilithium2
                dilithium2 Public-Key:
                pub:
                    d2:1e:25:21:ed:49:eb:c4:24:ab:35:86:91:5c:cb:
                    ...
                    83:46:ef:3a:07:c7:84
        X509v3 extensions:
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Alternative Name:
                DNS:test.openquantumsafe.org
            X509v3 Subject Key Identifier:
                E7:FE:2E:E4:2B:75:51:CF:D7:97:E7:51:97:B3:A4:71:5A:69:74:50
            X509v3 Authority Key Identifier:
                keyid:14:42:56:96:91:45:12:67:8F:F9:FA:9E:FF:CF:1C:C1:9B:21:56:EA

    Signature Algorithm: sha256WithRSAEncryption
         49:4d:17:e1:ae:ff:96:6d:99:89:6b:60:9a:34:59:ce:2e:9a:
         d8:8b:70:1e:c8:3b:89:7e:95:2d:42:6e:e8:49:8a:17:66:0b:
         42:52:27:55:87:42:eb:4e:e7:bd:a5:39:ec:c7:af:08:18:3d:
         57:ed:66:c4:79:a2:1d:6c:03:ac:63:03:cf:28:23:ff:3e:98:
         e4:96:7f:10:0c:5f:c2:17:78:92:18:3e:14:64:54:9f:93:d2:
         59:32:8b:d9:7a:5e:6a:73:49:ae:1f:e3:17:24:ef:44:73:4d:
         cc:ea:ff:ac:02:df:5b:b3:8f:fd:2f:52:bc:a0:d6:d8:16:6f:
         67:88:5b:ba:49:54:91:72:2a:fb:00:c5:54:8b:6c:84:ff:5d:
         87:34:70:06:27:44:7d:7d:a5:f9:49:72:db:46:57:31:58:a8:
         d9:f8:26:27:41:71:65:df:87:a8:9f:51:15:40:ad:ae:8c:a1:
         b0:d1:2b:48:e5:0e:0b:d3:da:63:70:df:2f:94:db:8e:be:17:
         27:e1:f9:46:d3:5b:e6:56:ac:b7:72:4e:1b:3f:33:cc:a4:a0:
         e0:71:b9:25:30:db:8d:93:1c:48:36:a6:33:dc:c2:4f:04:ad:
         05:35:ab:44:66:5f:7d:d0:bd:e5:3c:0b:1a:98:a4:13:5e:b2:
         25:95:32:c8:98:24:e5:e7:09:4e:56:24:e1:7f:5e:8f:75:1f:
         48:ab:b7:7c:43:40:f6:49:9c:8f:db:1d:b3:0d:ea:c9:32:96:
         32:88:51:00:37:fc:e2:2b:7e:9a:13:ac:a9:1c:4c:8b:17:f1:
         32:9d:8b:41:3a:11:f0:54:08:fc:f2:f5:83:39:21:c4:47:a0:
         60:58:58:4e:44:61:f8:d5:07:b5:98:9c:0d:eb:7d:7b:65:a4:
         5d:09:0e:0c:63:99:91:95:99:65:ee:51:16:62:6f:2c:18:70:
         f6:c0:99:e7:fc:a6:8a:1a:49:a6:2f:a2:ea:f3:99:2d:b2:aa:
         f2:48:fe:2a:3e:f3:b9:f9:3e:97:16:81:36:a2:fb:7f:d9:42:
         74:df:b9:f3:9a:7c:c3:b6:6c:54:ba:ab:98:e0:da:b2:bd:9a:
         ee:86:78:9b:f7:11:d9:fd:62:8f:e2:56:79:a7:63:db:f6:40:
         47:ac:ee:29:ee:aa:e4:57:28:b1:f4:af:c4:52:53:15:81:aa:
         51:4f:8a:45:32:55:7f:83:85:95:5b:50:b5:30:c9:ae:80:89:
         17:bb:fb:09:b8:02:9f:32:8f:ca:37:45:26:56:ee:40:e4:25:
         fa:a3:c6:77:40:24:d1:0d:05:5f:3d:8d:dd:84:b8:c7:0b:bb:
         9e:98:8d:c6:4d:37:64:eb

[pi-314159]

that doesn't mean the server cert is not PQ and does not trigger a PQ sig verification by a proper client checking (PQ) server sig during session setup

The server cert is PQ, but the certificate chain doesn't contain any quantum safe signature; this means we don't need oqs function to validate the certificate chain. For example, this go program can validate the current certificate chain at https://test.openquantumsafe.org:6088/

[baentsch]

Ah, apologies, now I understand what you're after: A full PQ cert chain to test cert verification software -- not necessarily TLS software (which the test server originally way meant for).

So two proposals for that:

1. Update https://github.com/open-quantum-safe/oqs-demos/tree/main/nginx/fulltest suitably to generate a cert chain with an intermediate of the same sig type & deploy this on the test server: This would not necessitate new ports, just extend each port's chain to achieve an "online PQ cert verification".
2. Use the artifacts generated by/stored at https://github.com/IETF-Hackathon/pqc-certificates for "offline PQ cert verification"

[pi-314159]

Thank you :D I prefer 1. tagging @bhess What do you think? This may need your help to generate an intermediate certificate.

[bhess]

I like the idea @pi-314159 and your proposal 1. @baentsch. So we would have a chain root (RSA) -> intermediate (QSC) -> end-entity (QSC). Would you envision each intermediate cert algorithm match with the end-entity algorithm (i.e. one intermediate cert for each port)?
The certs are generated by this script: https://github.com/open-quantum-safe/oqs-demos/blob/main/nginx/fulltest-provider/genconfig.py
@pi-314159 would you like to give it a go to extend the logic of the script? Otherwise I can give it a go prob. in the next 1-2 weeks.

[baentsch]

This change (1) should be rather straightforward. Please let me know whether you want to give it a try, @pi-314159 or whether I should do it. I cannot deploy it unfortunately as IBM prefers to keep control over their server, so we're dependent on @bhess for the deployment / usage test.

[pi-314159]

@bhess @baentsch Please check PR 242

[baentsch]

Merged open-quantum-safe/oqs-demos#242 . Please deploy, @bhess.

[bhess]

Up and running. Thanks for the PR @pi-314159!