SKI and AKI need to be considered user input

[matgnt]

Hi team,

as part of a risk analysis of the DAPS server (see link for details)
Fraunhofer-AISEC/omejdn-server#74

I found out, that SKI and AKI are loaded from the extension of the certificate. In case of self-signed certificates, this needs to be considered user input and should not be trusted directly.
https://github.com/eclipse-tractusx/daps-registration-service/blob/main/src/main/java/org/eclipse/tractusx/dapsreg/util/Certutil.java#L51

Flow

Since the clientId is not a secret and can be gathered from any EDC interaction (it is part of the DAPS token), this is not a secret. It could happen, that someone elses account / certificate is overwritten and this other party does not get a valid DAPS token any more.

I did not check all the portal checks which happen before the registration service is called. It is good though, that there are checks as well.

---

Matthias Binzer
Robert Bosch GmbH

[dvasunin]

We re-create SKI using public key from the certificate and compare it with SKI bundled. If they differ we deny request

[matgnt]

The fix mentioned by @dvasunin seems to be part of PR #46

[SebastianBezold]

#46 did indeed contain multiple fixes, but from commit messages it was not really clear, which change fixed what issue.
#50, #51 and #52 have been merged to fix the issues that are not related to this one here.
@dvasunin, will there be another dedicated PR to address the SKI topic?