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
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
