]> Cleverbase

mail@sanderdijkhuis.nl

Internet OpenID4VCI credential binding key derivation Using a distinct holder-binding key for each Credential improves unlinkability, but generating and storing many keys in a Wallet secure area can be expensive or impossible. This document defines a way to derive unlinkable P-256 Credential keys from one protected parent key while retaining the parent's key-protection properties. It specifies this mechanism as an extension to OpenID for Verifiable Credential Issuance (OpenID4VCI), allowing the Issuer to derive each child public key while only the Wallet can use the corresponding child private key. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction A Wallet can use distinct holder-binding keys for its Credentials to avoid giving Relying Parties a common correlation handle. An Issuer can nevertheless need assurance that these keys remain associated with a holder-binding key whose security properties it has already accepted. For example, an Issuer can accept a hardware-protected key when a Wallet presents a Person Identification Data credential, then issue mobile Driving Licence (mDL) Credentials bound to distinct child keys. The mDL keys appear unrelated to Relying Parties, while the Issuer can determine that they are derived from the previously accepted parent key. HDK relies on the assurance already established for that parent key rather than establishing the holder's identity itself. Generating and storing a separate secure area key pair for every Credential can also be expensive or impossible. HDK instead derives many P-256 child keys from one protected parent. Child-key operations can retain the parent's protections, including user authentication. This specification is limited to P-256 because it targets high-assurance Wallet ecosystems in which P-256 is widely supported by secure hardware and Credential formats. Other curves or key types require separate specification. During issuance, the Wallet and Issuer establish a shared secret using ephemeral X25519 keys. Together with the parent public key and Credential index, this determines each child key. The Issuer can derive the child public keys but not the corresponding private keys. Verifiers see ordinary P-256 keys and need no HDK support. identifies key management and Proof of Association (PoA) as challenges when issuing multiple single-use holder-binding keys in the EUDI Wallet setting. It discusses ARKG , including HDK, for deriving such keys and related-key PoA for associating them. This document defines a concrete OpenID4VCI mechanism for that design space. independently specifies multiplicative key blinding for signature keys; the construction here uses the same algebraic relation but adapts it for deterministic remote derivation of Credential keys. The interoperability differences are discussed in Interoperability Considerations. This version is a substantial rewrite of earlier versions and has not yet been reviewed by the stakeholders involved in that earlier work. The purpose of the rewrite is to specify the smallest possible extension to OpenID4VCI that makes HDK practical to use. A child key can itself be a parent, allowing hierarchical derivation.

Conventions and Encoding The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. a || b denotes byte-string concatenation. OS2IP and I2OSP are the octet-string/integer conversions defined in . base64(x) is unpadded base64url as defined in Section 5 of .

Cryptographic Dependencies This specification imports the following values and functions:

• From , the P-256 elliptic curve, its scalar and point representations, and its public-key validation rules. The P-256 group order is:
• ScalarMult(pk, k) is P-256 scalar multiplication as defined by . Received P-256 public keys MUST be validated as required by . When a P-256 public key pk is used as a byte string, it is encoded as the 65-byte uncompressed SEC 1 representation 0x04 || x || y.
• SHA-256(msg) is SHA-256 as defined by .
• GenerateX25519KeyPair() generates a fresh X25519 private key and its corresponding 32-byte public key, using X25519 as defined by .
• X25519(sk, pk) is the X25519 function defined by . Its 32-byte output is used directly as shared_secret. An all-zero output MUST be rejected.

Parent-Key Assurance The Wallet has a P-256 parent key pair (sk_parent, pk_parent) protected by its secure area. Before a Credential Request using HDK, the Issuer MUST already have established that pk_parent represents the intended Credential Holder and meets its requirements for key protection and user authentication. How this is established is out of scope. For example, it can be established by presentation of a Person Identification Data credential using OpenID4VP , or by proof of possession associated with a refresh token bound to pk_parent.

Credential Request For each request, the Wallet generates: and sends an hdk proof containing:

• parent: the P-256 parent public key as a JWK ; and
• pk_wallet: base64(pk_wallet).

For example: The Wallet MUST generate a fresh (sk_wallet, pk_wallet) for each request and retain sk_wallet until it processes the response.

Credential Response The Issuer generates: If shared_secret is all zero, the Issuer MUST reject the request. The Issuer returns base64(pk_issuer) once in the hdk response parameter: " }, { "credential": "" }, { "credential": "" } ] } ]]> Credential position is its zero-based HDK index. The Issuer MUST bind Credential i to the child public key for index i. A response MUST NOT contain more than 2^32 Credentials. The Wallet computes: If shared_secret is all zero, the Wallet MUST reject the response.

Child-Key Derivation Define: This is multiplicative key blinding, as used for ECDSA in . Its use here for remote child-key derivation serves a role related to ARKG , whose ARKG-P256 instance instead uses additive blinding. H returns an integer in 1..n-1. The small statistical bias from reduction modulo n - 1 is accepted for simplicity. For Credential i, where 0x00000000 <= i <= 0xffffffff: Because the blinding factor and sk_parent are non-zero modulo the prime n, sk_child is non-zero.

Hierarchical Derivation A child key pair MAY itself be used as a parent. For successive blinding factors b1 and b2:

Using a Child Key Child-key operations SHOULD receive protections equivalent to parent-key operations, including the same user-authentication policy. A secure area can derive sk_child internally, or use the equivalences below while continuing to operate with sk_parent.

ECDH For this section, ECDH(sk, pk) denotes P-256 ECDH as specified in , returning the 32-byte big-endian x-coordinate of ScalarMult(pk, sk). For the blinding factor b of a child: This allows b to be applied outside the secure area while the protected ECDH operation still uses sk_parent. pk MUST be validated before scalar multiplication; the result MUST also be validated if required by the ECDH interface.

ECDSA A secure area that supports multiplicative key blinding can derive and use the child key directly as described in . The remainder of this subsection describes an alternative that keeps the protected ECDSA operation on sk_parent. For the blinding factor b of the child, let: Then SHA256withECDSA(sk_child, msg) is equivalent to (r, s * b mod n), where: b^-1 is the inverse of b modulo n. NONEwithECDSA means ECDSA over the supplied 32-byte representative without hashing it again. Implementations MUST verify that their API has exactly this behavior. The resulting (r, s * b mod n) is an ordinary ECDSA signature under pk_child for msg. This ECDSA construction may be covered by patent claims in some jurisdictions or implementations. This document makes no determination about their validity or applicability. Deriving sk_child inside the secure area and signing with it is an alternative architecture and can have a different intellectual-property analysis.

OpenID4VCI Metadata Support is advertised with the hdk proof type in proof_types_supported : The hdk object in proof_types_supported is empty in this version of the specification; no proof-type-specific metadata parameters are currently defined. Implementations MUST NOT infer HDK support merely from P-256 support.

Interoperability Considerations The derivation in this document is not interoperable with either ARKG-P256 or the ECDSA construction in . ARKG-P256 uses additive blinding, P-256 ECDH, and ARKG-specific seed and key-handle structures. This document uses multiplicative blinding and an ephemeral X25519 exchange directly in OpenID4VCI. The simpler construction avoids introducing ARKG key representations and key handles, and the multiplicative relation also permits the ECDH and ECDSA child-key equivalences above while the secure area continues to operate with the parent key. X25519 was selected for the exchange because it requires little protocol and encoding boilerplate for this application: each party contributes one fixed-size public value and directly defines the shared-secret computation. It is also listed as an agreed key-establishment mechanism in the draft Version 3 of the EUCC Agreed Cryptographic Mechanisms . The ECDSA construction in uses the same multiplicative relation between parent and blinded keys, but derives the blinding scalar differently. It uses a separately generated private blinding key, domain separation, and hash_to_field; this document uses the X25519 shared_secret as bk, the parent public key and Credential index as ctx, and the compact H function above. Consequently, implementations of the two constructions will not derive the same keys from nominally corresponding inputs. These deviations are intentional: HDK needs one high-entropy per-request secret from which both parties can deterministically derive a batch of child keys, and it applies the same child-key relation to ECDH as well as ECDSA. They should not be interpreted as inheriting interoperability or security analysis from either referenced construction.

Security Considerations HDK relies on the Issuer having already accepted pk_parent, including its holder binding, key protection, and user-authentication properties. It preserves that association for child keys; it does not establish it. The security guarantee remains rooted in sk_parent. Disclosure of shared_secret does not reveal sk_parent or by itself enable child-key operations, but it reveals the relationship between pk_parent and its child public keys. Implementations SHOULD therefore protect and erase it when no longer needed. Both parties MUST use fresh X25519 key pairs for each request. Compromise of both sk_parent and an issuance shared_secret permits reconstruction of every child private key from that response. The biased H construction is intentional: this specification prefers ease of implementation over eliminating the small statistical bias. Replacing it with an unbiased construction would not be wire-compatible and requires a new algorithm identifier or protocol version. See the ECDSA section for intellectual-property considerations.

Privacy Considerations Distinct child public keys prevent correlation merely through reuse of the holder-binding public key. Other Credential contents, protocol metadata, network identifiers, or application behavior can still enable correlation. The Issuer knows pk_parent and derives all child public keys, so HDK does not provide unlinkability from the Issuer. shared_secret is privacy-sensitive because it reveals these relationships.

References Normative References National Institute of Standards and Technology (NIST) n.d. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. Standards for Efficient Cryptography Group In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References n.d. European Cybersecurity Certification Group, Sub-group on Cryptography ETSI n.d. n.d. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.

Acknowledgements Helpful ideas and feedback came from Peter Lee Altmann, Micha Kraus, Emil Lundberg, John Bradley, Paul Bastian, and Remco Schaar.