[OAUTH-WG] -15 of SD-JWT: five comments related to Key Binding

[Denis <[e-mail]>]

In an email exchanged with the co-editors, the co-chairs at the SEC AD 
on January 21, Deb wrote :

         Can you please review the newly released draft and make simple,
    text comments for the things you believe are fixable
         (doing that on the list would be lovely)?

         The goal here is to make it easier for the authors to see and
    understand your comments.

According to Deb's email, I post a set of five issues all related to 
"Key Binding". Additional sets on different topics will follow.

Every comment contains a change text proposal.

1. Proposed rewording of the definition of the term "Key Binding" in 
Section 1.2

Clause 1.2 states:

  Key Binding:  Ability of the Holder to prove possession of an SD-JWT 
by proving control over a private key during the presentation.
       When utilizing Key Binding, an SD-JWT contains the public key 
corresponding to the private key controlled by the Holder
      (or a reference to this public key).

Change proposal:

Key Binding:  Ability of the Holder to prove possession of an SD-JWT by 
proving control over a private key during the presentation.
When utilizing Key Binding, an SD-JWT contains a public key (or a 
reference to this public key) that has been included by the Issuer
into the SD-JWT. In that case, the Verifier can verify that a private 
key corresponding to that public key has correctly been used
to compute a cryptographic checksum.


2. Proposed addition after the third paragraph of 4.1.2 (Key Binding)

The third paragraph of 4.1.2 (Key Binding) states:

        It is out of the scope of this document to describe how the 
Holder key pair is established.  For example, the Holder MAY create
        a key pair and provide a public key to the Issuer, the Issuer 
MAY create the key pair for the Holder, or Holder and Issuer MAY
        use pre-established key material.

After this paragraph, it is proposed to add the following paragraph:

    It is out of the scope of this document to specify how Verifiers can
    know whether appropriate means are effectively used
    to ensure that unintended parties do not learn the value of the
    private keys or whether private keys that are under the control
    of the Holder cannot be used for the benefit of other End-Users,
    with or without the End-User consent.

Some explanations about this text proposal addition.

An X509 Certificate is defined using ASN.1 and includes a "Certificate 
Policy" field. An X.509 Certificate Policy is composed of the following 
elements:
an OID to uniquely identified the policy and several QCStatements.

To draw a parallel with X.509 Certificates used in the context of 
Electronic Signatures, some Certificate Issuers will not issue a PKC if 
they have not been convinced
that the private key is managed by a SSCD (Secure Signature Creation 
Device). The fact that, a SCCD is supported can be indicated in the 
QCStatements
from the Certificate Policy field of an X.509 certificate. See: ETSI EN 
319 412-5 V2.4.1 (2023-09) Electronic Signatures and Infrastructures (ESI);
Certificate Profiles; Part 5: QCStatements.

https://www.etsi.org/deliver/etsi_en/319400_319499/31941205/02.04.01_60/en_31941205v020401p.pdf

It is expected that, later on, a field equivalent to a Certificate 
Policy will be defined  and when this field will be defined,
a Verifier will be able to use it to know how good (or how bad) private 
keys are managed by a Holder.

Currently, the set of claims that is currently defined in this document 
does not allow a Verifier to know the "digital credential policy"
under which the digital credential has been issued.

In the context of eIDAS 2.0, ETSI TC ESI is currently working on a 
document that will be called:

    Policy and Security requirements for Providers of Electronic
    Attestation of Attribute Services 

See: 
https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=63664


3. Proposed addition after the second paragraph from 9.5 (Key Binding)

The second paragraph from 9.5 (Key Binding) starts with:

    Without Key Binding, a Verifier (...)

After this second paragraph, it is proposed to add a third paragraph, 
starting with the opposite case:

    With Key Binding, a Verifier (...).

Text proposal:

    With Key Binding, a Verifier gets the proof that the private key
    which corresponds to the public key placed in a SD-JWT has been
    correctly used.


4. Proposed replacement of three paragraphs by two paragraphs in 9.5 
(Key Binding)

The 4 th paragraph from 9.5 (Key Binding) starts with:

        It is important that a Verifier does not make its security policy
        decisions based on data that can be influenced by an attacker. For
        this reason, when deciding whether Key Binding is required or not,
        Verifiers MUST NOT take into account whether the Holder has provided
        an SD-JWT+KB or a bare SD-JWT, since otherwise an attacker could
        strip the KB-JWT from an SD-JWT+KB and present the resulting SD-JWT.

        Furthermore, Verifiers should be aware that Key Binding information
        may have been added to an SD-JWT in a format that they do not
        recognize and therefore may not be able to tell whether the SD-JWT
        supports Key Binding or not.

        If a Verifier determines that Key Binding is required for a
        particular use case and the Holder presents either a bare SD-JWT or
        an SD-JWT+KB with an invalid Key Binding JWT, then the Verifier will
        reject the presentation when following the verification steps
        described in Section 7.3.


If the SD-JWT contains a public key, then the Holder MUST use Key 
Binding and the Verifier MUST verify that Key Binding is correctly 
supported.

It is thus proposed to replace these three paragraphs by the following 
two paragraphs:

    If Key Binding is required by a Verifier, the SD-JWT MUST contain a
    public key and a KB-JWT MUST be present.
    If an attacker strips the KB-JWT, this can be immediately detected
    by the Verifier.

    If a Verifier determines that Key Binding is required for a
    particular use case and the Holder presents either a SD-JWT without
    a public key in it
    or an SD-JWT with a public key in it but without a valid KB-JWT,
    then the Verifier will reject the presentation when following the
    verification steps
    described in Section 7.3.


5. Proposed addition of two sub-sections in 9.5 (Key Binding)

Afterwards, it is proposed to add two sub-sections:

    9.5.1 Attacks performed with the End-user consent

    If two End-Users accept to collaborate, one End-User can perform
    cryptographic computations for the benefit of another End-User.
    An example scenario is as follows: one End-user connects to a
    Verifier and receives back a challenge and a list of claim types
    that need
    to be presented to get an access. That End-User forwards to another
    End-User the challenge received from the Verifier, the name of the
    Verifier
    and the set of claim types and values that it wishes to present to
    the Verifier. It receives back from the other End-User the data
    structure
    that he needs to be granted an access by that Verifier.

    For example, an application specifically downloaded by the End-User
    would be able to use the private keys and perform cryptographic
    computations
    for the benefit of another End-User.

    9.5.2 Attacks performed without the End-user consent

    A malicious application would be able to use the private keys
    intended to be used by the Holder or be able to trick the key pair
    generation process used by the Holder.

    For example, if the private key is only protected by software, a
    virus would be able use the private key without the End-User being
    aware of it.
    As another example, the key pair generation process could be
    modified, so that the generated key pair can be known by a malicious
    application and then exported.

Denis