It is outside of the scope of this document to appraise the effectiveness of the Key Binding mechanism

[Denisthemalice]

This issue is only intended to provide explanations for further text change proposals made in subsequent issues related to Key Binding.

Section 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.

Let us keep these sentences unchanged.

Now, let us pull on the thread from the right end.

Section 4 (Security Considerations) from [RFC7800] mentions that "possessing a key is only valuable if it is kept secret. Appropriate means must be used to ensure that unintended parties do not learn private key".

It is important to recall a definition for a private key from ISO/IEC 9798-1:

private key
key of an entity's asymmetric key pair that is kept secret and that should only be used by that entity

[SOURCE: ISO/IEC 9798-1:2010, 3.22]

The key sentences from RFC 7800 are true, but are restricted. They concentrate of the protection and the knowledge of the private key but they do not consider the use of the private key.

A smart card user can use of private present in his smart card but will never be able to know its value.

A difference should be made between :

1. the description of the cryptographic mechanism and
2. what can be achieved using this mechanism which is conditional on "appropriate means that MUST be used to ensure that unintended parties do not learn private key".

The proposed rewordings of this draft have been carefully thought to refer first to the description of the data elements that are needed and exchanged, while the 'proof of possession' concept has been separately addressed and expanded.

When considering threats that can reduce to nothing the effectiveness of this cryptographic ("binding") mechanism, there is the need to consider the presence of End-Users, that come in addition to Holders which are applications running using some hardware (and usually also using an OS).

An Holder cannot "give its consent", but an End-user (i.e. a human being) can. Attacks can be performed either without or with the End-user consent. Hence there is the need to :
(1) use the term "End-User" and
(2) make a difference between the term "Holder" (application) and the term "End-User".

The way to address the problem of the appraisal of the effectiveness of the Key Binding mechanism is to recognize that it is outside 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 the private keys that are supposed to be under the control of the Holder cannot be used for the benefit of other End-Users (with or without the End-User consent).

When proposing revised text, terms like 'ensure', 'legitimate Holder' or 'prove possession' that were present in this draft have been avoided. Hence, the following two sentences have not been retained:

Key Binding aims to ensure that the presenter of an SD-JWT credential is actually the legitimate Holder of the credential.
The Verifier requires that the Holder prove possession of that private key when presenting the SD-JWT credential.