Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86B4C14F70B for ; Thu, 3 Oct 2024 09:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yubico.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zcP2OCg2kar for ; Thu, 3 Oct 2024 09:39:16 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EAEAC14F6FF for ; Thu, 3 Oct 2024 09:39:16 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-37ccebd7f0dso857401f8f.1 for ; Thu, 03 Oct 2024 09:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yubico.com; s=google; t=1727973555; x=1728578355; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=N7zS02Ix+dF4xDGsL9VNXjmQiDPBTgm3+rHclB5z6uo=; b=UDpuuvQkC15pIQm/dhEDZz1Ppek6gopUHdZ7CkOhMGegdVDWMqcMWzfAADniTjqeNI plGRzOvcK7dSjD4JUlIiFypmQja5DtMoEpRGhkZJ0RGG+sFxHa38sjGU76tO81TwEQV3 85TwnY8BXeXCSpAvEh7Rr+J1P/NpGBYyXiam5qzVcWP/dNb3GZciwKN3LV1BjS+PngSZ SwQuIeXlSLgOMrZBiRt60dvV8v6iieLXspZllVGGkIIO6JU6YHcbs2qmdGgaPwS5WXCD +K9jombw/SsQfABuVsWCeOhVAYkoQH/+31tSYj4wNdFTEhKwBriweKvKBotQ+f8+aMHj iNUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727973555; x=1728578355; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=N7zS02Ix+dF4xDGsL9VNXjmQiDPBTgm3+rHclB5z6uo=; b=L8vhuW+G968x3E+3g3hC6fcoeR0Cfv82mNKj0RHtpOB+h2uEeXP31a+X9bxApkdMec cFidhmMNTVQxUlp5OFkMSq6qg/prCNlIO9Opc1L2HXBY5fzgceVwbP2x5dKZwhnmizLA snr9vw/McZwgkdMpmbv+N9rZyDZgm1OstCB9OcwtvxxoSvCzZ693P9RHcpV6VJ9CPW2b ssQ3tDZ3h25gJpxYzJLY7iPSr1Xsv/NtLPbfKJ4p2sEwBSGPpr9FtFxh3D+vSnp5IWTv Hzafz4IlU007sXWyr3pVSs2hbzYaJIMzjv6dF1rCGx1nq4bDnujdoDDpIJq2A79jM8dR 4xEg== X-Gm-Message-State: AOJu0Ywc2ySATa1qlyZ/Bx/5ngkJSCCvg3MVf/+4a5xATWTWPgrX75Mw FG/AYHakKFXnW0zgz2RVulHiwVf+T+8P1Ypk+pEh/4S7We62wkU1Pe0PQYY77qFsFgbs732Dj8+ NR5FphtYA0q3dD2U8ftxpPs8OI9yFNAgytNRJTw== X-Google-Smtp-Source: AGHT+IHYrKUGClfda9nM45qxZf9fFfdoSduCwrlmtDUYZ9TY3W/dJhIfeU1Q37TGOS9F81kKPDfoP/Engj7lDZb4YPc= X-Received: by 2002:a5d:5847:0:b0:374:babf:ac4f with SMTP id ffacd0b85a97d-37d0e6cb807mr17047f8f.12.1727973554416; Thu, 03 Oct 2024 09:39:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Emil Lundberg Date: Thu, 3 Oct 2024 18:38:57 +0200 Message-ID: To: Michael Jones Content-Type: multipart/alternative; boundary="000000000000e48ea2062395311b" Message-ID-Hash: IG5KMUAPEIB4XS7CODAIHYFQWKPLT5EN X-Message-ID-Hash: IG5KMUAPEIB4XS7CODAIHYFQWKPLT5EN X-MailFrom: emil@yubico.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cose.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: cose , "jose@ietf.org" , "mprorock@mesur.io" , Orie Steele X-Mailman-Version: 3.3.9rc5 Precedence: list Subject: =?utf-8?q?=5BCOSE=5D_Re=3A_=5Bjose=5D_Algorithm_identifiers_for_pre-hashing_?= =?utf-8?q?in_two-party_signing=3F?= List-Id: CBOR Object Signing and Encryption Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000e48ea2062395311b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mike and Orie, thank you for your replies (see Orie's reply on GitHub ). I've now had some time to digest them (pun intended) and consider how to proceed= . I agree that distinct algorithm identifiers seems like a suitable solution for this. I mocked up an outline of the idea, including a few examples of what this might look like for a couple of algorithms, which you can see here for the time being: https://yubico.github.io/arkg-rfc/cose-two-party-sign-algs/draft-bradleylun= dberg-cfrg-arkg.html#name-temporary-cose-algorithms-f (This address is temporary, we'll move the draft somewhere more appropriate when the ideas are more mature) The relevant section is "5.3. TEMPORARY: COSE algorithms for two-party signing", but it also lightly ties into the preceding section "5.2. COSE key reference types" for things like the *ctx* parameter in HashML-DSA. Perhaps this better illustrates what we're trying to do. As noted in the introduction section, this is subtly different from COSE Hash Envelope (CHE), for example, if I understood CHE correctly. We deliberately want to *avoid* domain-separating these signatures, and avoid an additional protocol-level hash layer. The hope is to be able to generate signatures that look the same as usual, and verify the same as usual, but without having to send the entire original message to the cryptographic hardware that holds the private key. These algorithm identifiers therefore wouldn't appear on signature structures or keys, as those would still be tagged with the existing identifier for the usual signature (verification) algorithm. This would enable our WebAuthn raw signing extension to output signatures that can be fed into existing verifiers, without needing to adapt those verifiers and cryptographic protocols to accomodate a protocol-level prehash. This also enables structuring the extension such that the WebAuthn Relying Party and authenticator (e.g., security key) can negotiate a two-party signature algorithm without needing the WebAuthn client (browser) to support it - the client just passes the data through. Please have a look at the mockup link above. Does this (and the related COSE_Key_Ref idea) seem like a reasonable approach? Emil Lundberg Staff Engineer | Yubico Den ons 25 sep. 2024 kl 00:29 skrev Michael Jones < michael_b_jones@hotmail.com>: > Thanks for writing, Emil. Here are my thoughts. > > > > I would not suggest trying to generically extend the JOSE and COSE signin= g > structures with additional parameters, such as creating a signing request > data structure. It would be much simpler and more aligned with how JOSE > and COSE work to define new algorithm identifiers for the additional need= ed > functionality. These should go into the existing registries for JOSE > > and COSE > > . > > > > As you probably already know, pre-hash algorithm identifiers for Ed25519 > and Ed448 are not currently registered for JOSE > > or COSE > . > I suggest creating them in a new specification. I=E2=80=99d be glad to c= ollaborate > on writing that with you if you=E2=80=99d like. Other needed pre-hash al= gorithm > identifiers could also be created in the new spec. > > > > Mike Prorock and Orie Steele, it=E2=80=99s relevant to know whether you i= ntent to > extend to register both pre-hash and non-pre-hash algorithm identifiers i= n > draft-ietf-cose-dilithium. Your thoughts? > > > > Emil, I am glad that you are working on the signing extension for > WebAuthn. I certainly support that work. > > > > Best > wishes, > > -- Mike > > > > *From:* Emil Lundberg > *Sent:* Friday, September 20, 2024 9:51 AM > *To:* cose ; jose@ietf.org > *Subject:* [jose] Algorithm identifiers for pre-hashing in two-party > signing? > > > > Hi COSE and JOSE WGs, > > I'm currently working on an extension to WebAuthn > [1] for signing arbitrary > data. The current draft uses `COSEAlgorithmIdentifier`s to negotiate what > signature algorithm to use, and the same `COSEAlgorithmIdentifier` is als= o > emitted in generated `COSE_Key`s to communicate the signature algorithm t= o > the signature verifier. > > However, for several reasons we want the caller of this signing API to > pre-hash the data to be signed before passing it into the extension. The > question then is: how should we communicate, _generically_, which steps o= f > the signing algorithm are performed in advance by the caller and which ar= e > performed by the WebAuthn authenticator? > > In some cases the division is fairly obvious. For example, ESP256 > > [2] hashes the input only once, so it's obvious that the caller performs > the hash and the WebAuthn authenticator interprets the input as a raw P-2= 56 > scalar. Ed25519ph > [3] hashes the input once without the key and then hashes the digest agai= n > with the key, so clearly only the first hash can be performed by the call= er > (and Ed25519 is impossible to implement in this way). > > But for other algorithms it's less obvious - for example, for HashML-DSA > [4], the caller could compute > only PH_M and submit PH_M and the hash OID into the signing API, or the > caller could compute M' and submit only M' into the signing API (I think > the former is clearly preferable, but the point is that both options > exist). Similarly for RSASSA-PSS > [5], should the > caller submit `mHash` or `EM`? This "division of labour" between the call= er > and the WebAuthn authenticator needs to be defined somehow. > > So, that is my question: how should we define and communicate this > division of labour? > > - Is there some way we can do it generically, without defining any new > algorithm identifiers? > - Should we define new algorithm identifiers for "pre-hashing for > two-party signing" in some existing registry? > - Should we define a new registry of algorithm identifiers? > - Should we define some new "signing request" data structure, which can > describe whether and how data is pre-hashed (perhaps similar to COSE Hash > Envelopes > > [6]?)? > - Other options? > > Any insight and guidance on this would be much appreciated. Of course I'm > also happy to elaborate on anything that is unclear. Thank you. > > > [1]: https://github.com/w3c/webauthn/pull/2078 > [2]: > https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithm= s-05.html > [3]: https://www.rfc-editor.org/rfc/rfc8032#section-5.1 > [4]: https://csrc.nist.gov/pubs/fips/204/final > [5]: https://www.rfc-editor.org/rfc/rfc8017#section-9.1.1 > [6]: > https://cose-wg.github.io/draft-ietf-cose-hash-envelope/draft-ietf-cose-h= ash-envelope.html#name-hash-envelope-cddl > > > *Emil Lundberg* > > Staff Engineer | *Yubico* > > > --000000000000e48ea2062395311b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mike and Orie, thank you for your replies (see Ori= e's reply on GitHub). I've now had some ti= me to digest them (pun intended) and consider how to proceed.
I agree that distinct algorithm identifiers seems like a suitab= le solution for this. I mocked up an outline of the idea, including a few e= xamples of what this might look like for a couple of algorithms, which you = can see here for the time being:=C2=A0https://yubico.github.io/arkg-rfc/cose-two-par= ty-sign-algs/draft-bradleylundberg-cfrg-arkg.html#name-temporary-cose-algor= ithms-f
(This address is temporary, we'll move the draft = somewhere more appropriate when the ideas are more mature)
The re= levant section is "5.3. TEMPORARY: COSE algorithms for two-party signi= ng", but it also lightly ties into the preceding section "5.2. CO= SE key reference types" for things like the ctx=C2=A0parameter = in HashML-DSA.
Perhaps this better illustrates what we're try= ing to do.

As noted in the introduction section, t= his is subtly different from COSE Hash Envelope (CHE), for example, if I un= derstood CHE correctly. We deliberately want to avoid=C2=A0domain-se= parating these signatures, and avoid an additional protocol-level hash laye= r. The hope is to be able to generate signatures that look the same as usua= l, and verify the same as usual, but without having to send the entire orig= inal message to the cryptographic hardware that holds the private key. Thes= e algorithm identifiers therefore wouldn't appear on signature structur= es or keys, as those would still be tagged with the existing identifier for= the usual signature (verification) algorithm.

Thi= s would enable our WebAuthn raw signing extension to output signatures that= can be fed into existing verifiers, without needing to adapt those verifie= rs and cryptographic protocols to accomodate a protocol-level prehash. This= also enables structuring the extension such that the WebAuthn Relying Part= y and authenticator (e.g., security key) can negotiate a two-party signatur= e algorithm without needing the WebAuthn client (browser) to support it - t= he client just passes the data through.

Please hav= e a look at the mockup link above. Does this (and the related COSE_Key_Ref = idea) seem like a reasonable approach?

<= div dir=3D"ltr">

Emil Lundberg

Staff Engineer | Yubico=



<= br>
Den ons= 25 sep. 2024 kl 00:29 skrev Michael Jones <michael_b_jones@hotmail.com>:

Thanks for writing, E= mil.=C2=A0 Here are my thoughts.

=C2=A0<= /span>

I would not suggest t= rying to generically extend the JOSE and COSE signing structures with addit= ional parameters, such as creating a signing request data structure.=C2=A0 = It would be much simpler and more aligned with how JOSE and COSE work to define new algorithm identifiers for the ad= ditional needed functionality.=C2=A0 These should go into the existing regi= stries for JOSE and COSE.

=C2=A0<= /span>

As you probably alrea= dy know, pre-hash algorithm identifiers for Ed25519 and Ed448 are not curre= ntly registered for JOSE or COSE.=C2=A0 I suggest creating them in a new specification.=C2=A0 I=E2= =80=99d be glad to collaborate on writing that with you if you=E2=80=99d li= ke.=C2=A0 Other needed pre-hash algorithm identifiers could also be created= in the new spec.

=C2=A0<= /span>

Mike Prorock and Orie= Steele, it=E2=80=99s relevant to know whether you intent to extend to regi= ster both pre-hash and non-pre-hash algorithm identifiers in draft-ietf-cos= e-dilithium.=C2=A0 Your thoughts?

=C2=A0<= /span>

Emil, I am glad that = you are working on the signing extension for WebAuthn.=C2=A0 I certainly su= pport that work.

=C2=A0<= /span>

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best wishes,

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=

=C2=A0<= /span>

From: Emil Lundberg <emil=3D40yubico.com@dmarc.ietf.org>
Sent: Friday, September 20, 2024 9:51 AM
To: cose <cose= @ietf.org>; jose@= ietf.org
Subject: [jose] Algorithm identifiers for pre-hashing in two-party s= igning?

=C2=A0

Hi COSE and JOSE WGs,

I'm currently working on an extension to WebAuthn [1] for signing arbitrary data. The current draft uses `COSEAl= gorithmIdentifier`s to negotiate what signature algorithm to use, and the s= ame `COSEAlgorithmIdentifier` is also emitted in generated `COSE_Key`s to c= ommunicate the signature algorithm to the signature verifier.

However, for several reasons we want the caller of this signing API to pre-= hash the data to be signed before passing it into the extension. The questi= on then is: how should we communicate, _generically_, which steps of the si= gning algorithm are performed in advance by the caller and which are performed by the WebAuthn authenticato= r?

In some cases the division is fairly obvious. For example, ESP256 [2] hashes the input only once, so it's obvious that the cal= ler performs the hash and the WebAuthn authenticator interprets the input a= s a raw P-256 scalar. Ed25519ph [3] hashes the input once without the key and then hash= es the digest again with the key, so clearly only the first hash can be per= formed by the caller (and Ed25519 is impossible to implement in this way).

But for other algorithms it's less obvious - for example, for HashML-DSA [4], the caller could compute only PH_M and submit PH_M and = the hash OID into the signing API, or the caller could compute M' and s= ubmit only M' into the signing API (I think the former is clearly prefe= rable, but the point is that both options exist). Similarly for RSASSA-PSS [5], should the caller submit `mHash` or `EM`? This "di= vision of labour" between the caller and the WebAuthn authenticator ne= eds to be defined somehow.

So, that is my question: how should we define and communicate this division= of labour?

- Is there some way we can do it generically, without defining any new algo= rithm identifiers?
- Should we define new algorithm identifiers for "pre-hashing for two-= party signing" in some existing registry?
- Should we define a new registry of algorithm identifiers?
- Should we define some new "signing request" data structure, whi= ch can describe whether and how data is pre-hashed (perhaps similar to COSE Hash Envelopes [6]?)?
- Other options?

Any insight and guidance on this would be much appreciated. Of course I'= ;m also happy to elaborate on anything that is unclear. Thank you.


[1]: https://github.com/w3c/webauthn/pull/2078
[2]: https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-= 05.html
[3]: https://www.rfc-editor.org/rfc/rfc8032#section-5.1
[4]: https://csrc.nist.gov/pubs/fips/204/final
[5]: https://www.rfc-editor.org/rfc/rfc8017#section-9.1.1
[6]: https://cose-wg.github.io/draft-ietf-cose-hash-envelope/draft-ietf-cose-has= h-envelope.html#name-hash-envelope-cddl


Emil Lundberg<= /p>

Staff Engineer | Yubico

=C2=A0

--000000000000e48ea2062395311b--