Skip to content

Extend CMS to support CAdES beyond Baseline-B #18491

@ljaenicke

Description

@ljaenicke

We are using OpenSSL to create digital signatures for firmware (code signing) and would like to add additional features. One important feature would be the use of additional time stamps to allow verification of the date of signature (as described in CAdES Baseline-T). It would be useful to also support CAdES up to Baseline-LT (including OCSP or CRL to proof that the signing certificate was not revoced) an Baseline-LTA to extend with updated signatures and algorithms.
Details can be found in the ETSI documentation, for example ETSI EN 319 122-1 V1.1.5.

I have implemented a proof of concept for verification of CAdES up to Baseline-LTA in
https://github.com/PHOENIXCONTACT/openssl/tree/CAdES_development
The PoC includes the following elements:

  • Add "codesigning" as specific purpose to correctly handle certificates with that extension setting
  • Add respective OIDs
  • Read the embedded timestamp as of CAdES Baseline-T and use it instead of the current time
  • Add verification of additional signature extensions up to CAdES Baseline LTA
  • Experimental: move the handling of timestamps from PKCS7 to CMS code (I ran into rsassa-pss not supported with openssl ts -verify #7904 when testing with RSASSA-PSS in the timestamps)

The PoC currently handles verification only, I created signatures for testing with the https://github.com/esig/dss tools,

Now:
I would be willing to develop the PoC into production quality. It however does only make sense to invest the time if the features (or a subset thereof) will actually be added to the code base. In addition, the PoC implements just one way to do it. It may be very helpful to have a discussion on how to implement such features.

  • Verification of Baseline-T seems to be more or less straight forward, Verification up to Baseline-LTA in a full style may become very complex as multiple additonal signatures may be need to be verified and according to the ETSI standard a verfication policy would be needed. I have hardcoded a specific policy.

  • The PoC does not include generation of signatures in the style of Baseline-T or higher. These signatures cannot just be generated by using certificate but need to include timestamps and retrieval of CRLs or OCSP responses. Currently the openssl/apps are specialized to perform just one task (signing, timestamping, ...).

  1. Generating more complex CAdES signatures could be designed into one special app, which would then mixing elements of cms, ts, and so on.
  2. It would also be possible to for example extend the ts utility to extend a Baseline-B to a Baseline-T signature.
  3. Finally creating Baseline LT/LTA signatures would be even more complex and hardly possible without a working PKI providing OCSP/CRL for download from the respecitve endpoints mentioned in the certificates. This might be very difficult to setup in a "make test" environment.

So, there are a lot of issues that should be discussed before moving on with developing such features.

Metadata

Metadata

Assignees

No one assigned

    Labels

    inactiveThis label should not be applied to open issues anymore.triaged: featureThe issue/pr requests/adds a feature

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions