Support for multiple certification scenarios and self-signing

[bgrieder]

This is a complete rewrite of the Certify operation to extend its usage and support self-signing

There are now 4 possibilities for generating a certificate

1. Provide a Certificate Signing Request (CSR)
   using -certificate-signing-request
2. Provide a public key id to certify
   using -public-key-id-to-certify as well as a subject name
3. Provide an existing certificate id to re-certify
   using -certificate-id-to-re-certify
4. Generate a keypair then sign the public key to generate a certificate
   using -generate-key-pair as well as a subject name and an algorithm

The signer (issuer) is specified by providing an issuer private key id
using -issuer-private-key-id and/or
an issuer certificate id using -issuer-certificate-id. If only
one of these parameters is specified, the other one will be inferred
from the links of the cryptographic object behind the provided parameter.

If no signer is provided, the certificate will be self-signed.
It is not possible to self-sign a CSR.

[tbrezot]

What is the point of this message as it will appear in the server logs (if I am correct)? Is there a check in the ECDH operation to prevent this to happen? If yes I would remove this message. If no I would add it add still remove this message.

[tbrezot]

Shouldn't this bit behind a #[cfg(not(feature="fips"))]?

[ccorsin]

I played with the CLI and tried to perform the different actions - here is my retex :

Import

• Can we guess format from the file extension ?

  **As discussed, file extension is not relevant and could be misused.**
  

• Error not really explicit when missing format flag.

./target/debug/ckms certificates import /Users/celia-std/Documents/kms/crate/server/src/routes/google_cse/python/openssl/celia.corsin.p12
ERROR: failed parsing the object from the json file: invalid type: integer `0`, expected struct TTLV at line 1 column 1

manu: Let --format argument be now required.

• When importing a pkcs12 with -f flag and missing password, I have : (error not so explicit)

❯ ./target/debug/ckms certificates import /Users/celia-std/Documents/kms/crate/server/src/routes/google_cse/python/openssl/celia.corsin.p12 -f pkcs12
ERROR: REST Request Failed: /kmip/2_1: Unexpected server error: error:11800071:PKCS12 routines:PKCS12_parse:mac verify failure:../crypto/pkcs12/p12_kiss.c:67:

manu: Here is the new server response:

ERROR: REST Request Failed: /kmip/2_1: Certificate error: Unable to parse PKCS12 file: (bad/missing password?). ErrorStack([Error { code: 293601393, library: "PKCS12 routines", function: "PKCS12_parse", reason: "mac verify failure", file: "../crypto/pkcs12/p12_kiss.c", line: 67 }])

• When adding right password, I have : (-> I am not able to import my pkcs12 cert created from my Mac)

./target/debug/ckms certificates import /Users/celia-std/Documents/kms/crate/server/src/routes/google_cse/python/openssl/celia.corsin.p12 -f pkcs12 -p hello
ERROR: REST Request Failed: /kmip/2_1: Unexpected server error: error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:349:Global default library context, Algorithm (RC2-40-CBC : 0), Properties ()

manu: I believe the Openssl library installed on your machine and required by the server is incorrect. Otherwise I could verified than macos server was correctly answering:

cargo run -p cosmian_kms_cli -- certificates import ./crate/server/src/routes/google_cse/python/openssl/ca.p12 -f pkcs12 --pkcs12-password secret

The private key in the PKCS12 file was imported with id: 304e625e-c8ca-45e9-a1fe-c3bf2bded7b9

Certify

• when subject name has wrong format - error not so explicit:

./target/debug/ckms certificates certify -g --subject-name celia --algorithm nist-p521
ERROR: Not Supported: subject name value missing for identifier celia

manu: I've changed it into:

ERROR: Not Supported: Missing or invalid x509 certificate `subject name` value for identifier celia

• (naive mistake) - I created a sym key with the KMS - and after tried to certify it (non sense), I got Rust panicking :

❯ ./target/debug/ckms certificates certify -p 050242ac-5276-4aad-bd25-fee5e905bdf3 -t celia_tag -s CN=celia
    thread 'main' panicked at /Users/celia-std/Documents/kms/crate/cli/src/actions/certificates/certify.rs:367:14:
    failed creating certificate: RequestFailed("/kmip/2_1: Unexpected server error: Invalid Certify request for object type SymmetricKey")
    stack backtrace:
       0: _rust_begin_unwind
       1: core::panicking::panic_fmt
       2: core::result::unwrap_failed
       3: core::result::Result<T,E>::expect
       4: cosmian_kms_cli::actions::certificates::certify::CertifyAction::run::{{closure}}
       5: cosmian_kms_cli::actions::certificates::CertificatesCommands::process::{{closure}}
       6: ckms::main_::{{closure}}
       7: ckms::main::{{closure}}
       8: tokio::runtime::park::CachedParkThread::block_on::{{closure}}
       9: tokio::runtime::park::CachedParkThread::block_on
      10: tokio::runtime::context::blocking::BlockingRegionGuard::block_on
      11: tokio::runtime::scheduler::multi_thread::MultiThread::block_on::{{closure}}
      12: tokio::runtime::context::runtime::enter_runtime
      13: tokio::runtime::scheduler::multi_thread::MultiThread::block_on
      14: tokio::runtime::runtime::Runtime::block_on
      15: ckms::main
      16: core::ops::function::FnOnce::call_once
    note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

manu: Replacing expect with map_err l367 of crate/cli/src/actions/certificates/certify.rs.

ERROR: Server error: failed creating certificate: RequestFailed("/kmip/2_1: Unexpected server error: Invalid Certify request for object type SymmetricKey")

• Same with private ec key for example :

❯ ./target/debug/ckms certificates certify -p ce7998f6-73a7-4374-aa45-c158643c3d0c -t celia_tag -s CN=celia
    thread 'main' panicked at /Users/celia-std/Documents/kms/crate/cli/src/actions/certificates/certify.rs:367:14:
    failed creating certificate: RequestFailed("/kmip/2_1: Unexpected server error: Invalid Certify request for object type PrivateKey")
    stack backtrace:
       0: _rust_begin_unwind
       1: core::panicking::panic_fmt
       2: core::result::unwrap_failed
       3: core::result::Result<T,E>::expect
       4: cosmian_kms_cli::actions::certificates::certify::CertifyAction::run::{{closure}}
       5: cosmian_kms_cli::actions::certificates::CertificatesCommands::process::{{closure}}
       6: ckms::main_::{{closure}}
       7: ckms::main::{{closure}}
       8: tokio::runtime::park::CachedParkThread::block_on::{{closure}}
       9: tokio::runtime::park::CachedParkThread::block_on
      10: tokio::runtime::context::blocking::BlockingRegionGuard::block_on
      11: tokio::runtime::scheduler::multi_thread::MultiThread::block_on::{{closure}}
      12: tokio::runtime::context::runtime::enter_runtime
      13: tokio::runtime::scheduler::multi_thread::MultiThread::block_on
      14: tokio::runtime::runtime::Runtime::block_on
      15: ckms::main
      16: core::ops::function::FnOnce::call_once
    note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

manu: Also fixed by replacing expect with map_err l367 of crate/cli/src/actions/certificates/certify.rs.

• If I try to use a key that was revoked (using the certificates revoke with tag command - see below, under revoke section) - I have this error :

❯ ./target/debug/ckms certificates certify -p 12ffb412-fba5-471c-b1ef-4658ccb8820c -t celia_tag -s CN=celia
    thread 'main' panicked at /Users/celia-std/Documents/kms/crate/cli/src/actions/certificates/certify.rs:367:14:
    failed creating certificate: RequestFailed("/kmip/2_1: Invalid Request: the cryptographic algorithm must be specified for key pair creation")
    stack backtrace:
       0: _rust_begin_unwind
       1: core::panicking::panic_fmt
       2: core::result::unwrap_failed
       3: core::result::Result<T,E>::expect
       4: cosmian_kms_cli::actions::certificates::certify::CertifyAction::run::{{closure}}
       5: cosmian_kms_cli::actions::certificates::CertificatesCommands::process::{{closure}}
       6: ckms::main_::{{closure}}
       7: ckms::main::{{closure}}
       8: tokio::runtime::park::CachedParkThread::block_on::{{closure}}
       9: tokio::runtime::park::CachedParkThread::block_on
      10: tokio::runtime::context::blocking::BlockingRegionGuard::block_on
      11: tokio::runtime::scheduler::multi_thread::MultiThread::block_on::{{closure}}
      12: tokio::runtime::context::runtime::enter_runtime
      13: tokio::runtime::scheduler::multi_thread::MultiThread::block_on
      14: tokio::runtime::runtime::Runtime::block_on
      15: ckms::main
      16: core::ops::function::FnOnce::call_once
    note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

manu: Same.

Decrypt

• When I try to decrypt with an invalid cert for decryption (same cert used to encrypt), I have: (error not so explicit)

[2024-05-30T08:11:24Z WARN  cosmian_kms_server::routes] 422 Unprocessable Entity - Item_Not_Found: e8c6545a-24c7-47c3-aaf1-691894fdc5e5

manu: New error message:

ERROR: Can't execute the query on the kms server: REST Request Failed: /kmip/2_1: Item_Not_Found: Decrypt: no available key found (must be an active symmetric key or private key) for object identifier 2335f73c-6c88-41e5-b115-fce8f7f10179

Export

• Why -k flag for certificate-id ? (global remark for other commands too)

manu: Let us uniformize certificate-id shortcut to -c (in operations certify, destroy, encrypt, decrypt, export revoke, import_key and locate)*

• Why -i, --allow-revoked ? -i is also used for specifying IDS in other commands (certify for example). Why do we need a specific flag for revoked certs?

manu: Replace the -i to -r

• When exporting a revoked cert without the -i flag - error not so explicit:

ERROR: Get: REST Request Failed: /kmip/2_1: Item not found: e8c6545a-24c7-47c3-aaf1-691894fdc5e5

manu: New error message:

ERROR: Get: REST Request Failed: /kmip/2_1: Item not found: get_key: no available key found (must be an active or exportable KMIP object) for object identifier 2335f73c-6c88-41e5-b115-fce8f7f10179

• Why exporting after revokation is not the same as before revokation ? (JSON file added)

./target/debug/ckms certificates export -k e8c6545a-24c7-47c3-aaf1-691894fdc5e5 -f pem test
The certificate e8c6545a-24c7-47c3-aaf1-691894fdc5e5 of type Certificate was exported to "test"

./target/debug/ckms certificates export -k e8c6545a-24c7-47c3-aaf1-691894fdc5e5 -f pem -i test
The certificate e8c6545a-24c7-47c3-aaf1-691894fdc5e5 of type Certificate was exported to "test"
The attributes of the certificate e8c6545a-24c7-47c3-aaf1-691894fdc5e5 were exported to "test.attributes.json"

manu: No strong opinion about this. The JSON file brings details about related objects (through links), I suppose there is no point for those links when the object is revoked

Revoke

❯ ./target/debug/ckms certificates revoke --help
Revoke a certificate.

When a certificate is revoked, it can only be exported by the owner of the certificate, using the --allow-revoked flag on the export function.

Usage: ckms certificates revoke [OPTIONS] <REVOCATION_REASON>

Arguments:
      <REVOCATION_REASON>
              The reason for the revocation as a string

    Options:
      -k, --certificate-id <CERTIFICATE_ID>
              The certificate unique identifier of the certificate to revoke. If not specified, tags should be specified

      -t, --tag <TAG>
              Tag to use to retrieve the certificate when no certificate id is specified. To specify multiple tags, use the option multiple times

• Remove this phrase under -t ? To specify multiple tags, use the option multiple times (I think this make sense only for cert import/creation)

manu: Actually, you can revoke using only a tag

• When revoking a cert, the message should be Successfully revoked the certificate instead ?

❯ ./target/debug/ckms certificates revoke -t celia_tag test
Successfully revoked the key: ["celia_tag"].

manu: Replaced key by object (code reused for all object-revocation)

• It seems like the previous command deleted all the keys with this tag (hard to say about certs, because locate command does not fetch certs - see below) → Add a granularity to delete only elements of the command type ? (keys, or certs)

manu: Add an issue please
Celia : done - here : #258

Destroy

• Trying to destroy one of the revoked previous element, I got this error :

❯ ./target/debug/ckms certificates destroy -t celia_tag
ERROR: destroying the key ["celia_tag"] failed: REST Request Failed: /kmip/2_1: Invalid_Object_Type: This object does not have a key block

(RSA PUBLIC KEY)

❯ ./target/debug/ckms certificates destroy -k 6aafc830-eaa8-4b33-a562-2d47579df252
ERROR: destroying the key 6aafc830-eaa8-4b33-a562-2d47579df252 failed: REST Request Failed: /kmip/2_1: Invalid_Object_Type: This object does not have a key block

(EC PUBLIC KEY)

❯ ./target/debug/ckms certificates destroy -k d33630fe-ead4-43c3-873e-8257a59abe66
ERROR: destroying the key d33630fe-ead4-43c3-873e-8257a59abe66 failed: REST Request Failed: /kmip/2_1: Invalid_Object_Type: This object does not have a key block

manu: all fixed (same code used)

Random

• Certs are not located under the locate command - how to fetch their ids ?
  **
  manu: indeed, except by tag, we cannot locate certs since Certificate does not have KMIP attributes.
  In this PR feat(cli): add optional JSON output #257, we can find object by object_type (and then by Certificate).
  As a reminder, with Findex database, objects are not searchable by attributes
  **
• When we locate elements using a tag - could be useful to get the type of each element ? Currently only ids are displayed.
  **
  manu: that's true. This limitation comes from the KMIP operation Locate which returns only ids. We can use the --key-format-type or retrieve the object type for each id returned by Locate.
  One interesting command is ckms access-rights owned to get the full details of your objects (including object_type and key_format_type
  **