eu-digital-green-certificates / dgc-lib Goto Github PK

This project needs a CI setup to automatically build the lib.
Also it is required to publish the lib as maven package to GitHub Registry.

The dgc lib should be enhanced to download and verify business rules. The provisioning of valuesets should also be included.

The implementation should be similiar to the TrustListItem e.g. BusinessRulesItem,ValueSetItem, CountryListItem etc.

It was reported that the error handling for the REST Client is not ideal solved or document. The process how errors are highlighted must be improved to create an proper exception handling outside of the dgc lib. (e.g. for connection errors, verification errors etc.)

We need to setup automatic sonarcloud checks in CI.

Apparently, the Path for signerInformation has chaged to signerCertificate in the latest release of the Gateway: https://eu-digital-green-certificates.github.io/dgc-gateway/#/

The following code to get the signing algorithm is in error (row 100 and 101):

String signingAlgorithmName =   
new DefaultAlgorithmNameFinder().getAlgorithmName(signingCertificate.getSignatureAlgorithm());

There are 2 problems here

1. The signing algorithm of the private key is NOT necessarily the signing algorithm of the public key certificate. Example I have a public/private EC key pair, but the certificate of the public key is signed by the CA using an RSA key. The code above then attempts to use the EC key with the RSA algorithm used to sign the certificate, which is a complete mismatch.
2. If the signing algorithm is RSA-PSS, then the code above fails. This has to do with RSA-PSS using more complex parameter structure. The code above concludes that the algorithm is simply "RSAPSS" and this results in an exception in the next step.

I have altered this code in my own version of the class to:

ASN1ObjectIdentifier publicKeyAlgoOID = 
      signingCertificate.getSubjectPublicKeyInfo().getAlgorithm().getAlgorithm();
String signingAlgorithmName = null;
if (publicKeyAlgoOID.equals(PKCSObjectIdentifiers.rsaEncryption)) signingAlgorithmName = "SHA256WITHRSA";
if (publicKeyAlgoOID.equals(X9ObjectIdentifiers.id_ecPublicKey)) signingAlgorithmName = "SHA256WITHECDSA";
if (signingAlgorithmName == null) throw new RuntimeException("Public key must be RSA or EC");

To ensure reliability on dgc-lib we have to implement a set of Unit Tests.

TODO:

• Message Builder
• Message Parser
• Certificate Converter X509Certificate -> X509CertificateHolder
• Certificate Converter X509CertificateHolder -> X509Certificate
• Calculate Kid
• Calculate Cert Hash

Current Implementation

No Uploader for Validation Rules

Suggested Enhancement

Add an uploader for Validation Rules just like it already exists for DSC.

Expected Benefits

Comfortable way to upload validation Rules.

Current Implementation

When trying to validate a CSCA a DSC will be checked against the whole list of downloaded CSCA.

Suggested Enhancement

To improve performance it would make sense to search in the list of trusted CSCA for a matching CSCA by its Subject and then do the actual Issuer Check on the found certificate.

Expected Benefits

Improved performance.

We need a Connector for sending and receiving data from and to DGC Gateway. This Connector should be implemented as SpringBoot Service which can be injected in existing Spring Boot Applications.

AK:

• Download of Certificates (DSC)
• Validation of Certificates by CSCA Certs
• Validation of CSCA Certs by TrustAnchor (Local Keystore)
• Providing of Downloaded Keys to other Services
• Upload new DSC Certificates to DGC
• Unit Testing
• Documentation

This issue resolves eu-digital-green-certificates/dgca-verifier-service#2 and eu-digital-green-certificates/dgca-issuance-service#6

During the download of the DSCs, all inactive and revoked certificates should be removed/filtered out with a warning/info. The check should be done at first over an given OSCP endpoint of the related/matching CSCA, second the revocation list should be check over the CSCA endpoint.

To provide a trust anchor rollover feature, please enable the functionality to configure a second trust anchor and validate against two anchors. (Primary/secondary)

List of compliant national DGC gateways

I'm following the development of the DGC libraries with great interest and I'd like to thank the community for steadily improving the respositories. Currently I am trying to implement the DGCG connector for easier retrieval of trusted certificates and business rules. Sadly, I did not find any list of compliant national gateways at the moment. In a longer discussion (eu-digital-green-certificates/dgc-participating-countries#10) various implementations were mentioned, but I refuse to implement a different logic per country (or even provider) when there is an open standard.

Does anyone have a source with publicly available gateways (or at least one trustworthy source with a proper documentation)?

Sources I've already screened

• https://dgc.a-sit.at/ehn/ (sadly, no documentation)
• https://github.com/eu-digital-green-certificates
• https://github.com/ehn-dcc-development
• https://github.com/panzi/verify-ehc/blob/main/verify_ehc.py (great work!)

Describe the bug

After parsing a certificate the getSignature() method does not return a valid detached CMS signature.

Expected behaviour

getSignature() should return valid detached CMS signature to verify integrity of payload certificate.

Steps to reproduce the issue

1. Parse CMS Message with SignedMessageParser
2. getSignature() from parser
3. Parse with SignedMessageParser with signature from step 2 and raw data from certificate
4. --> Invalid CMS

Possible Fix

Correct implementation of detached signature when executing getSignature().

Issue

According to DCC Schema the version key of a DCC has to be named 'ver'
(cmp: https://github.com/eu-digital-green-certificates/ehn-dgc-schema/blob/d23e67eaaee1515b1fc91f768f0d46666123cb3e/DGC.schema.json#L14)
in current implementation of dgc-lib it is named 'version':

Current Implementation

The connector is using the DELETE /signerCertificate endpoint to revoke a certificate.

Suggested Enhancement

Optionally use the new alternative endpoint POST /signerCertificate/delete from eu-digital-green-certificates/dgc-gateway#64

The usage of this alternative endpoint should be configurable.

Expected Benefits

Users with clients behind Load Balancers which do not allow DELETE Request with Payload can also send revoke requests to DGCG.

Is dgc-lib encoding and decoding Base45 messages?
Might be my inexperience with the codebase, but I could just see Base64 encodings.

Isn't one of the requirement of the standard to encode and decode on Base45?

The DccTestBuilder is missing the option to set the now required field ma (testIdentifier).

    /**
     * test identifier.
     * @param testIdentifier id according to https://github.com/ehn-dcc-development/ehn-dcc-valuesets/blob/main/test-manf.json
     * @return builder
     */
    public DccTestBuilder testIdentifier(String testIdentifier) {
        testObject.set("ma", jsonNodeFactory.textNode(testIdentifier));
        requiredNotSet.remove(RequiredFields.ma);
        return this;
    }

The function calculateHash contains improper formatting of SHA256 hash. In case the hash starts with a zero byte 0x00 it gets stripped during the conversion to BigInteger. There is already insufficient check on this line. This might have already caused a real issue as observed in this (and the following) Slack messages.

The following code demonstrates the issue:

import java.math.BigInteger;
public class Main
{
    public static void main(String[] args) {
        byte[] certHashBytes = {(byte) 0x00, (byte) 0xdd, (byte) 0x44, (byte) 0x78,
                                 (byte) 0xb2, (byte) 0x0c, (byte) 0x02, (byte) 0x6a,
                                 (byte) 0x83, (byte) 0x51, (byte) 0x94, (byte) 0x9d,
                                 (byte) 0xfe, (byte) 0x21, (byte) 0x0c, (byte) 0xe2,
                                 (byte) 0x55, (byte) 0xa5, (byte) 0x1e, (byte) 0x61,
                                 (byte) 0x3f, (byte) 0x7c, (byte) 0x83, (byte) 0x27,
                                 (byte) 0xe4, (byte) 0x70, (byte) 0x9c, (byte) 0x1c,
                                 (byte) 0xb8, (byte) 0x65, (byte) 0xad, (byte) 0xb5};
                                 
        String hexString = new BigInteger(1, certHashBytes).toString(16);
        System.out.println(hexString);
        // prints
        // dd4478b20c026a8351949dfe210ce255a51e613f7c8327e4709c1cb865adb5
        // which is 62 chars long and not 64
    }
}

I'm not much of Javist myself, but checking an answer to SO question How to convert a byte array to a hex string in Java? I'd go probably with the Option 7 and use BouncyCastle, since it is used elsewhere in the dgc-lib, that is I'd do something like:

import org.bouncycastle.util.encoders.Hex;
...
    private String calculateHash(byte[] data) throws NoSuchAlgorithmException {
        byte[] digest = MessageDigest.getInstance("SHA-256").digest(data);
        return Hex.toHexString(digest);
    }

I've also ditched the cetrtHashBytes name in favor of digest since not just certificates are hashed using this function (and no need to retype the type). However, potential PR definitely has to add test cases for this.

Hello,

I have found the following problem. The line (DgcGatewayDownloadConnector.java, method updateIfRequired, line 105)

trustedCscaCertificateMap = trustedCscaCertificates.stream()
    .collect(Collectors.toMap((ca) -> ca.getSubject().toString(), (ca) -> ca));

throws exception java.lang.IllegalStateException: Duplicate key if trustedCscaCertificates contains two (or more) certificates
with same subject.

I am using development gateway. The problematic certificates returned by the gateway are

1. First

   • Subject: C=BB,ST=NRW,L=Test,O=MinistryOfTest,OU=DGCOperations,CN=CSCA_DGC_DE_01
   • SN: 522704455866195600131091134914499111884383337176

2. Second

   • Subject: C=BB,ST=NRW,L=Test,O=MinistryOfTest,OU=DGCOperations,CN=CSCA_DGC_DE_01
   • SN: 579131198531557717335939590388500291603260377746

Enhance DGC Lib TrustListItem by adding the Country and the Full Sha256Hash (Thumbprint).

Describe the bug

Trying to use this library as a Maven Dependency leads to Maven not being able to resolve the dependency. Both the POM and JAR download links (https://repo.maven.apache.org/maven2/eu/europa/ec/dgc/dgc-lib/0.5.1/dgc-lib-0.5.1.pom, https://repo.maven.apache.org/maven2/eu/europa/ec/dgc/dgc-lib/0.5.1/dgc-lib-0.5.1.jar) show 404.

Expected behaviour

Maven should find and download the dependency.

Steps to reproduce the issue

Included dependency in pom.xml in fresh Spring Boot project according to Usage.
Updated settings.xml with PAT and username according to settings.xml in source code.
tried mvnw install.

Technical details

• Host Machine OS (Windows/Linux/Mac): Windows 10