Clarification about trust anchor limitations

[vsassmann]

Hello,

I would like to ask about the requirement from HAIP 1.0:

6.1.1. Issuer identification and key resolution to validate an issued Credential
This specification mandates the support for X.509 certificate-based key resolution to validate the issuer signature of an SD-JWT VC. This MUST be supported by all entities (Issuer, Wallet, Verifier). The SD-JWT VC MUST contain the credential issuer's signing certificate along with a trust chain in the x5c JOSE header parameter as described in section 3.5 of [I-D.ietf-oauth-sd-jwt-vc]. The X.509 certificate of the trust anchor MUST NOT be included in the x5c JOSE header of the SD-JWT VC. The X.509 certificate signing the request MUST NOT be self-signed.

We believe we have identified a situation where this might not be desired.

In some ecosystems, it might be desirable to have the leaf X.509 certificate as a trust anchor. We are currently discussing whether this could be the case in EUDIW. From our understanding, this might be possible in EUDIW.

If this were the case, including the signing certificate (which would also be the trust anchor) in the x5c would violate HAIP because of:

... The X.509 certificate of the trust anchor MUST NOT be included in the x5c JOSE header of the SD-JWT VC. The X.509 certificate signing the request MUST NOT be self-signed. ...

On the other hand, not including the signing certificate would also violate HAIP:

... The SD-JWT VC MUST contain the credential issuer's signing certificate...

In that case, it might be necessary to specify in the EUDIW ecosystem that HAIP should be used except for this condition.
Was this intentional, or did we overlook something?

[c2bo]

In some ecosystems, it might be desirable to have the leaf X.509 certificate as a trust anchor. We are currently discussing whether this could be the case in EUDIW. From our understanding, this might be possible in EUDIW.

When would you do that and why couldn't you have root cert -> signing cert as a chain in that case? Generally speaking, I'd always try to have at least 1 layer of chaining so the certificate that is used actively for signing is not the trust anchor and that is what HAIP is also asking for.

[nklomp]

In addition to the above, could you explain the EUDIW use case that conflicts with current spec text? I cannot see how you could end up with a non chain in EUDIW

[vsassmann]

Thanks for your responses. 


Regarding the question:



When would you do that and why couldn't you have root cert -> signing cert as a chain in that case? Generally speaking, I'd always try to have at least 1 layer of chaining so the certificate that is used actively for signing is not the trust anchor and that is what HAIP is also asking for.

Why do we think this is allowed in EUDIW
First of all, why do we think that a certificate used to sign an attestation could be used as a trust anchor?

1. In the ARF, there is a definition of a trust anchor:> A trust anchor is a combination of a public key and the identifier of the associated entity and may be used to verify signatures created by that entity.


From our understanding, using the signing certificate as a trust anchor is allowed by this definition.

2. Also from the ARF, chapter 6.6.3.6:

Note that the Provider may use an intermediate signing certificate to sign the PID or attestation, and use the trust anchor to sign the signing certificate, instead of signing the PID or attestation directly with the trust anchor.

From this wording, we conclude that the Provider can also sign the PID or attestation directly with the trust anchor.

Why do we think someone might want to use the signing certificate as a trust anchor

If the certificates that the PID or attestation provider uses for signing are issued by a third-party certification authority, the PID or attestation provider might want to “pin” only the certificates that were issued directly to them and for which they possess the corresponding private keys.

If the PID provider were to use an intermediate certificate as a trust anchor, for which they do not possess the private key, there could be a risk that the certification authority might issue another signing certificate under the same intermediate certificate to a different party. Therefore, another party could maliciously issue PIDs that would technically be verifiable against the trust anchor (i.e., the intermediate certificate) published by the PID provider.

Also, to answer:

In addition to the above, could you explain the EUDIW use case that conflicts with current spec text? I cannot see how you could end up with a non chain in EUDIW

We do not expect that, in general, a non-chain certificate would be used in EUDIW. However, based on the specification text, if the PID Provider were to use the signing certificate as a trust anchor (which, according to our conclusion above, we believe might be possible), the specification would require them to both:

• include the certificate in the x5c (because it is the signing certificate), and
• not include the certificate in the x5c (because it also serves as the trust anchor).

That's where we see the conflict with the current spec.

We might be missing something or misinterpreting parts of the specification or ARF. If that is the case, we apologize for any confusion caused.

[nklomp]

I don't get it. The LOTL or LOTE are always qualified. Which means the issuer of the certificates for these entities are QTSPs. That is (the lists) you trust anchors and these are by definition issued by (intermediate) CAs, so you will always have a chain.

Seperate from that it would be a very bad approach to use a signing cert as a root IMO. AFAIK exactly the reason why it was removed from HAIP, to ensure you have proper chain validation against your trustchains instead of relying on the chain in the header only.

[dBucik]

@nklomp
How are LOTL and LOTE related to the original issue? Can't the issuer of an attestation be a QTSP at the same time?

I would probably summarise the original issue as this:

From HAIP:

the signing certificate must be represented in x5c,
the trust anchor must not appear in x5c,
therefore the signer cannot itself be the trust anchor.

From EUDIW ARF

Note that the Provider may use an intermediate signing certificate to sign the PID or attestation, and use the trust anchor to sign the signing certificate, instead of signing the PID or attestation directly with the trust anchor.

From HLRs

(ISSU_01a) PID Providers and Attestation Providers SHALL support the OpenID4VCI protocol specified in [OpenID4VCI], as profiled in Sections 4 and 6 of [HAIP], and with additions and changes as documented in this Annex (see e.g. this Topic and Topic 9) and in Technical Specification 3. Note: For clarity: in [HAIP] v1.0, Section 6 implies that PID Providers and Attestation Providers must comply with the applicable requirements in [OpenID4VCI] Annex A.2 when issuing an attestation in ISO/IEC 18013-5-compliant format, and with the applicable requirements in [OpenID4VCI] Annex A.3 when issuing an attestation in SD-JWT VC format.

So these are ultimately in conflict.

[gfour]

This sounds like the ARF proposes a best practice with "may", while still allowing for the other choice to be made. Maybe HAIP can relax the constraint and suggest that "the trust anchor must not appear in x5c unless the trust anchor coincides with the signing certificate"?

[nklomp]

How are LOTL and LOTE related to the original issue? Can't the issuer of an attestation be a QTSP at the same time?

LOTL is related, because it lists the CA's of QTSPs. No CA would ever use their root certificates for the use cases you describe. Heck the CA certificates have special extensions to denote these are CA's. You take a trustanchor based on your legal framework and use case. Whether these are documents, PIDs, QEAAs, you will have CAs, which can be intermediate at that point. No one should ever be using these to directly sign documents or (Q)EAAs/PIDs.

That would be a very bad approach, as signing documents/PIDs/QEAA have a complete different security posture from having a cert (CA) than can sign certificates, which likely is offline even. There is also a reason why you see multiple (intermediate) CAs when you look at a trustchain of a QTSP. Why would any CA take these risks and directly sign with their root CA? Not to mention that I doubt you would pass conformance assessment if you were doing that as QTSP.

So instead of relaxing that in HAIP, IMO the respective text should be properly adjusted.
I personally do not see any possibility of not having a chain in a regulated environment or High Assurance usecase as the anchor as far as I can see will always be at least one up from the certificate signing.

[nklomp]

The potential exemption I could see is for PID providers, TS 119 412-6 does allow for a PID provider to be self-certified

[vsassmann]

@nklomp thank you for the discussion.

First of all, I would like to ensure that we have a common understanding of the situation we are trying to describe.
The situation is illustrated in the diagram below:

                +----------------------+
                |  Root Certificate    |
                |  (Certification CA)  |
                +----------+-----------+
                           |
                           v
                +--------------------------+
                | Intermediate Certificate |
                |        (CA)              |
                +-----------+--------------+
                            |
                            v
                +--------------------------+
                |      Leaf Certificate    |
                |   (PID Provider's        |
                |   signing certificate)   |
                +-----------+--------------+
                            |
                            |  uses private key
                            v
                +--------------------------+
                |    Signed PID (JWT/VC)   |
                |  (issued by PID Provider)|
                +--------------------------+

In this scenario, the PID Provider has been issued a signing certificate by a Certification Authority (CA). This CA issues certificates with the appropriate profile that allows them to be used for signing PIDs.
The PID Provider possesses the private key corresponding to this leaf certificate and uses it to sign PIDs.
Since the PID Provider does not possess the private key of the intermediate certificate, it uses the leaf certificate as the trust anchor in the EUDIW List of Trusted Entities (LoTE). This approach is necessary because other certificates issued by the same CA could belong to different PID Providers.

                +--------------------------------------+
                |        Trusted Entities List         |
                +--------------------------------------+
                |                                      |
                |  +--------------------------------+  |
                |  |  Entity: PID Provider          |  |
                |  +--------------------------------+  |
                |  |  Provider identifier: 12345    |  |
                |  |                                |  |
                |  |  Trust Anchor (Leaf Cert):     |  |
                |  |  +--------------------------+  |  |
                |  |  |  Leaf Certificate        |  |  |
                |  |  |  (PID Provider)          |  |  |
                |  |  +--------------------------+  |  |
                |  +--------------------------------+  |
                |                                      |
                +--------------------------------------+

                                   |
                                   | used to validate
                                   v
                     +-----------------------------+
                     |        Signed PID           |
                     |       Issued by:  12345     |
                     |   (contains x5c header)     |
                     +-----------------------------+

Now, suppose a relying party receives such a PID. It must verify that it was indeed issued by the listed PID Provider.
To do so, the relying party retrieves the LoTE, finds the corresponding record for the PID Provider, and obtains the associated signing certificate. If the certificate used to sign the PID matches this registered certificate, the relying party can trust that the PID was issued by the correct PID Provider.
However, it is unclear to us what data should be included in the x5c header in order to also comply with HAIP in this scenario. From our perspective, the trust anchor is the leaf (signing) certificate itself, and no additional certificates are strictly necessary.

Does this mean that, even though the EUDIW model does not require the CA's intermediate and root certificates for trust establishment, they should still be included in the x5c header to satisfy HAIP requirements?

However, even if it were required to include these certificates in the x5c header in this scenario, wouldn’t HAIP be in conflict with ETSI TS 119 412-6 in cases where a PID Provider uses a self-signed certificate?