Designated Verifier Signatures for JOSE
draft-bastian-dvs-jose-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Paul Bastian , Micha Kraus | ||
| Last updated | 2024-08-09 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bastian-dvs-jose-01
Javascript Object Signing and Encryption P. Bastian
Internet-Draft M. Kraus
Intended status: Informational Bundesdruckerei GmbH
Expires: 10 February 2025 9 August 2024
Designated Verifier Signatures for JOSE
draft-bastian-dvs-jose-01
Abstract
This specification defines designated verifier signatures for JOSE
and defines algorithms that use a combination of key agreement and
MACs.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://paulbastian.github.io/draft-bastian-dvs-jose/draft-bastian-
dvs-jose.html. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-bastian-dvs-jose/.
Discussion of this document takes place on the Javascript Object
Signing and Encryption Working Group mailing list
(mailto:jose@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/jose/. Subscribe at
https://www.ietf.org/mailman/listinfo/jose/.
Source for this draft and an issue tracker can be found at
https://github.com/paulbastian/draft-bastian-dvs-jose.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Bastian & Kraus Expires 10 February 2025 [Page 1]
Internet-Draft DVS for JOSE August 2024
This Internet-Draft will expire on 10 February 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Cryptographic Dependencies . . . . . . . . . . . . . . . . . 3
5. Designated Verifier Signatures . . . . . . . . . . . . . . . 4
5.1. Signature Generation . . . . . . . . . . . . . . . . . . 5
5.2. Signature Verification . . . . . . . . . . . . . . . . . 5
5.3. Signature Suites . . . . . . . . . . . . . . . . . . . . 6
6. Designated Verifier Signatures using HPKE . . . . . . . . . . 6
6.1. Signature Generation . . . . . . . . . . . . . . . . . . 6
6.2. Signature Verification . . . . . . . . . . . . . . . . . 7
6.3. Signature Suites . . . . . . . . . . . . . . . . . . . . 7
7. Designated Verifier Signatures for JOSE . . . . . . . . . . . 8
7.1. Example JWT . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.1. Replay Attack Detection . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Designated verifier signatures (DVS) are signature schemes in which
signatures are generated, that can only be verified a particular
party. Unlike conventional digital signature schemes like ECDSA,
this enables repudiable signatures.
Bastian & Kraus Expires 10 February 2025 [Page 2]
Internet-Draft DVS for JOSE August 2024
This specification describes a general structure for designated
verifier signature schemes and specified a set of instantiations that
use a combination of an ECDH key exchange with an HMAC.
This specification and all described algorithms should respect the
efforts for Fully Specified Algorithms
(https://www.ietf.org/archive/id/draft-jones-jose-fully-specified-
algorithms-00.html).
This algorithm is intended for use with digital credentials
ecosystems, including the Issuer-Holder-Verifier model described by
W3C VCDM or IETF SD-JWT-VC.
2. Conventions and Definitions
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology
The draft uses "JSON Web Signature", "JOSE Header", "JWS Signature",
"JWS Signing Input" as defined by [RFC7515].
Signing Party: The Party that performs the key agreement first and
generates the MAC. Similar to a Signer.
Verifying Party: The Party that performs the key agreement second,
generates the MAC and compares it to a given value. Similar to a
Verifier.
4. Cryptographic Dependencies
DVS rely on the following primitives:
* A Diffie-Hellman Key Agreement (DHKA)
- DH(skX, pkY): Perform a non-interactive Diffie-Hellman exchange
using the private key skX and public key pkY to produce a
Diffie-Hellman shared secret of length Ndh. This function can
raise a ValidationError.
- Ndh: The length in bytes of a Diffie-Hellman shared secret
produced by DH().
- Nsk: The length in bytes of a Diffie-Hellman private key.
Bastian & Kraus Expires 10 February 2025 [Page 3]
Internet-Draft DVS for JOSE August 2024
* A key derivation function (KDF):
- Extract(salt, ikm): Extract a pseudorandom key of fixed length
Nh bytes from input keying material ikm and an optional byte
string salt.
- Expand(prk, info, L): Expand a pseudorandom key prk using
optional string info into L bytes of output keying material.
- Nh: The output size of the Extract() function in bytes.
* A Message Authentication Code algorithm (MAC)
- MacSign(k, i): Returns an authenticated tag for the given input
i and key k.
- Nk: The length in bytes of key k.
* An HPKE algorithm (for the HPKE variants):
- SealAuth(pkR, info, aad, pt, skS): encrypts and authenticates
single plaintext pt with associated data aad and context info
using a private sender key skS and public receiver key pkR.
- OpenAuth(enc, skR, info, aad, ct, pkS): decrypts ciphertext and
tag ct with associated data aad and context info using a
private receiver key skR and public sender key pkS.
5. Designated Verifier Signatures
A designated verifier signature requires three components for an
algorithm:
1. a Diffie-Hellman Key Agreement (DHKA)
2. a Key Derivation Function (KDF)
3. a Message Authentication Code algorithm (MAC)
In general, these parameters are chosen by the Signing Party. These
parameters need to be communicated to the Verifying Party before the
generation of a Designated Verifier Signature.
The following functions are defined to describe a generic, composable
Designated Verifier Signature Scheme:
Bastian & Kraus Expires 10 February 2025 [Page 4]
Internet-Draft DVS for JOSE August 2024
def dvsSign(pkR, skS, msg, salt= "", info = "DVS-1")
dh = DH(skS, pkR)
prk = Extract(salt, dh)
k = Expand(prk, info, Nk)
mac = MacSign(k, msg)
return mac
def dvsVerify(skR, pkS, msg, salt = "", info = "DVS-1", mac)
dh = DH(skR, pkS)
prk = Extract(salt, dh)
k = Expand(prk, info, Nk)
mac' = MacSign(k, msg)
if mac != mac':
raise Exception("Designated Verifier Signature invalid")
return
5.1. Signature Generation
The generation of the Designated Verifier Signature takes the private
key of the Signing Party, the public key of the Verifying Party and
the message as inputs. The retrieval and communication of the
Verifying Party's public key is out of scope of this specification
and subject to the implementing protocols.
Input:
* skS: private key of the Signing Party
* pkR: public key of the Verifying Party
* msg: JWS Signing Input
* salt : Salt for key derivation
* info : optional info for key derivation
Steps: * TODO
5.2. Signature Verification
The generation of the Designated Verifier Signature takes the private
key of the Signing Party, the public key of the Verifying Party and
the message as inputs. The retrieval and communication of the
Verifying Party's public key is out of scope of this specification
and subject to the implementing protocols.
Input:
Bastian & Kraus Expires 10 February 2025 [Page 5]
Internet-Draft DVS for JOSE August 2024
* skR: private key of the Verifying Party
* pkS: public key of the Signing Party
* msg: JWS Signing Input
* salt : Salt for key derivation
* info : optional info for key derivation
* signature : the Message Authentication Code
Steps: * TODO
5.3. Signature Suites
Algorithms MUST follow the naming DVS-<DHKA>-<KDF>-<MAC>.
6. Designated Verifier Signatures using HPKE
This section describes a simple designated verifier signature scheme
based on Hybrid Public Key Encryption (HPKE) [RFC9180] in auth mode.
It reuses the authentication scheme underlying the AEAD algorithm in
use, while using the KEM to establish a one-time authentication key
from a pair of KEM public keys. This scheme was described in early
specification drafts of HPKE [RFC9180]
6.1. Signature Generation
To create a signature, the sender simply calls the single-shot Seal()
method with an empty plaintext value and the message to be signed as
AAD. This produces an encoded key enc and a ciphertext value that
contains only the AAD tag. The signature value is the concatenation
of the encoded key and the AAD tag.
Input:
* skS: private key of the Signing Party
* pkR: public key of the Verifying Party
* msg: JWS Signing Input
* info : optional info for key derivation
Steps:
1. Call enc, ct = SealAuth(pkR, info, aad, pt, skS) with
Bastian & Kraus Expires 10 February 2025 [Page 6]
Internet-Draft DVS for JOSE August 2024
* aad = msg
* pt = ""
2. JWS Signature is the octet string concatenation of (enc || ct)
6.2. Signature Verification
To verify a signature, the recipient extracts encoded key and the AAD
tag from the signature value and calls the single-shor Open() with
the provided ciphertext. If the AEAD authentication passes, then the
signature is valid.
Input:
* skR: private key of the Verifying Party
* pkS: public key of the Signing Party
* msg: JWS Signing Input
* info : optional info for key derivation
* signature: JWS Signature octet string
Steps:
1. Decode enc || ct = signature by length of enc and ct. See
[HPKE-IANA] for length of ct and enc.
2. Call pt = OpenAuth(enc, skR, info, aad, ct, pkS) with
* aad = msg
3. the signature is valid, when OpenAuth() returns pt = "" with no
authentication exception
NOTE: ct contains only a tag. It's length depends on the AEAD
algorithm (see Nt values in RFC9180 chapter 7.3.)
6.3. Signature Suites
Algorithms MUST follow the naming DVS-HPKE-<Mode>-<KEM>-<KDF>-<AEAD>.
"Mode" is Auth (PSKAuth could also be used). The "KEM", "KDF", and
"AEAD" values are chosen from the HPKE IANA registry [HPKE-IANA].
Bastian & Kraus Expires 10 February 2025 [Page 7]
Internet-Draft DVS for JOSE August 2024
7. Designated Verifier Signatures for JOSE
Designated Verifier Signatures behave like a digital signature as
described in Section 3 of [RFC7518] and are intended for use in JSON
Web Signatures (JWS) as described in [RFC7515]. The Generating Party
performs the Message Signature or MAC Computation as defined by
Section 5.1 of [RFC7515]. The Verifying Party performs the Message
Signature or MAC Validation as defined by Section 5.2 of [RFC7515].
The following JWS headers are used to convey Designated Verifier
Signatures for JOSE:
* alg : REQUIRED. The algorithm parameter describes the chosen
signature suite, for example the ones described in
(#generic_suites) and (#hpke_suites).
* rpk : REQUIRED. The rpk (recipient public key) parameter
represents the encoded public key of the Verifying Party that was
used in the DHKA algorithm as a JSON Web Key according to
[RFC7517]. This parameter MUST be present.
* nonce : OPTIONAL. The nonce may be provided by the Verifying
Party additional to it's public key and ensure additional
freshness of the signature. If provided, the Signing Party SHOULD
add the nonce to the header.
The Signing Party may use existing JWS header parameters like x5c,
jwk or kid to represent or reference it's public key according to
[RFC7517].
7.1. Example JWT
The JWT/JWS header:
{
"typ" : "JWT",
"alg" : "DVS-P256-SHA256-HS256",
"jwk" : <JWK of the Signing Party>,
"rpk" : <JWK of Verifying Party>
}
The JWT/JWS payload:
Bastian & Kraus Expires 10 February 2025 [Page 8]
Internet-Draft DVS for JOSE August 2024
{
"iss" : "https://example.as.com",
"iat" : "1701870613",
"given_name" : "Erika",
"family_name" : "Mustermann"
}
The JWT/JWS signature:
base64-encoded MAC
This specification described instantiations of Designated Verifier
Signatures using specific algorithm combinations:
+-----------------------+-----------------------------+----------------+
| Algorithm Name | Algorithm Description | |
| | | Requirements |
+-----------------------+-----------------------------+----------------+
| DVS-P256-SHA256-HS256 | ECDH using NIST P-256, | Optional |
| | HKDF using SHA-256 and | |
| | HMAC using SHA-256 | |
+-----------------------+-----------------------------+----------------+
| DVS-HPKE-Auth-X25519 | DVS based on HPKE using | |
| -SHA256 | DHKEM(X25519, HKDF-SHA256) | Optional |
| -ChaCha20Poly1305 | HKDF-SHA256 KDF and | |
| | ChaCha20Poly1305 AEAD | |
+-----------------------+-----------------------------+----------------+
| DVS-HPKE-Auth-P256 | DVS based on HPKE using | |
| -SHA256-AES128GCM | DHKEM(P-256, HKDF-SHA256) | Optional |
| | HKDF-SHA256 KDF and | |
| | AES-128-GCM AEAD | |
+-----------------------+-----------------------------+----------------+
8. Security Considerations
8.1. Replay Attack Detection
* Verifying Party MUST ensure the freshness of signatures by
utilizing ephemeral keys in rpk or by providing a nonce for nonce.
9. IANA Considerations
Define:
* define new rpk header parameter
* alg values for DVS-P256-SHA256-HS256 and some more
Bastian & Kraus Expires 10 February 2025 [Page 9]
Internet-Draft DVS for JOSE August 2024
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/rfc/rfc7518>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.
10.2. Informative References
[HPKE-IANA]
"Hybrid Public Key Encryption (HPKE) IANA Registry",
October 2023,
<https://www.iana.org/assignments/hpke/hpke.xhtml>.
Appendix A. Acknowledgments
Thanks to:
* Brian Campbell
* John Bradley
Authors' Addresses
Paul Bastian
Bundesdruckerei GmbH
Bastian & Kraus Expires 10 February 2025 [Page 10]
Internet-Draft DVS for JOSE August 2024
Email: bastianpaul@googlemail.com
Micha Kraus
Bundesdruckerei GmbH
Email: kraus.micha@gmail.com
Bastian & Kraus Expires 10 February 2025 [Page 11]