From nobody Sun Apr 3 00:56:46 2022 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 7D6403A1AEA for ; Sun, 3 Apr 2022 00:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.707 X-Spam-Level: X-Spam-Status: No, score=-1.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=mnot.net header.b=FVQKstlk; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=messagingengine.com header.b=QvzIifC3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYvKbH_zd7V7 for ; Sun, 3 Apr 2022 00:56:03 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7A03A1AEC for ; Sun, 3 Apr 2022 00:56:02 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 54101320157F for ; Sun, 3 Apr 2022 03:39:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 03 Apr 2022 03:39:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-type:date:from:from:in-reply-to:mime-version:reply-to :sender:subject:subject:to:to; s=fm2; bh=CE5xMkiGcwRvCXJaWtwpPM1 crH15U7kznbX5eM5lFig=; b=FVQKstlkbRZtvcGyywAUQ9BWa8IplaQibE9f0zk v6Xf/JpBIiVGsE4y0XevsX7fOBDaG+0dhLIdok7pceon2BSRLVNO9na7wZmX90eB a1o/nHfDgKGyCZF9TAiZPCpvNYU+J/HMIVlfejyJWZrrPjSV7gHf9CPkfXRpt+7w ZDvzmKT6jGRrK/TigOB7Z6Yr2UDQSzKi3DzWl4JpA3u0qNfuoAwHMW6isYIsPt+W ZaR7PcrSbsh65RHp3IYYYOTujk094tPn83GrAkdUQdGo0E2/LXxWsm6ETiruMrys Y/xuBy0rN49UbEvzfw5SdPDPMvH9c7j+4byZ6Z4zPDQ+GWg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:from :in-reply-to:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=CE5xMkiGcwRvCXJaWtwpPM1crH15U7kznbX5eM5lFig=; b=QvzIifC3 v+sYAuJdkk+ydhte3dQXYMigVZ4MGTOQpbsHboLElw7X8w6uMf+KBMw8deeObPML gCMkyU5vNohMhoX1TF+ir4Xb9ytuksGDOKxidvdCyWPbCJ89D2U/7cQKVd1KoJsw Meunro8LolRizl5UhYjAu5BS+EMnXl5ixsCxCF8msJ+4Z31PwWPpA3I3s7G2EeH3 yvXjT+Aetl+wCSxVPe6HDCe0ppLfWtZIiSdVYUKHzuoctDARZVLsMtVMJ2Ukc1Ij +PtyKvagkQ1tcqDfpyUaP6yam4ivFsdg5CH6kVafZGOHwsAPySQSL8b9bjnWj6L+ P1NdgVTroGLWQg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudeiledguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmne cujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhih ucettghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeu gfefhfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrd gtohhmnecuvehluhhsthgvrhfuihiivgepgeenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 3 Apr 2022 03:39:14 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============1754851889538363272==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cose@ietf.org Message-Id: <20220403075602.DF7A03A1AEC@ietfa.amsl.com> Date: Sun, 3 Apr 2022 00:56:02 -0700 (PDT) Archived-At: Subject: [COSE] Weekly github digest (COSE Activity Summary) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2022 07:56:08 -0000 --===============1754851889538363272== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cose-wg/CBOR-certificates (+0/-0/=F0=9F=92=AC1) 1 issues received 1 new comments: - #93 SW-Implementation of CBOR-certificates (1 by derekatkins) https://github.com/cose-wg/CBOR-certificates/issues/93=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cose-wg/CBOR-certificates * https://github.com/cose-wg/Charter * https://github.com/cose-wg/cose-rfc8152bis * https://github.com/cose-wg/countersign * https://github.com/cose-wg/X509 --===============1754851889538363272== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (COSE Activity Summary)

Sunday April 03, 2022

Events without label "editorial"

Issues

cose-wg/CBOR-certificates (+0/-0/=F0=9F=92=AC1)

1 issues received 1 new comments:

Repositories tracked by this digest:
--===============1754851889538363272==-- From nobody Sun Apr 3 07:23:49 2022 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 DCD8E3A1C57 for ; Sun, 3 Apr 2022 07:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.704 X-Spam-Level: X-Spam-Status: No, score=-5.704 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_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transmute.industries Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iID8HG0rwDl for ; Sun, 3 Apr 2022 07:23:42 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D633A1C55 for ; Sun, 3 Apr 2022 07:23:41 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id v12so9828483ljd.3 for ; Sun, 03 Apr 2022 07:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; h=mime-version:from:date:message-id:subject:to; bh=WQ8Ru/Aiwd2G+FkL3qyriRNZPvECbriQQI/dwO49yng=; b=S8c+UptK80SZlEQKNZuwt/0S0UcIeeDFLr+EeejMxc2xgZnMIHmYVWhxkvqP1AjZlH 4abii/SvaUYrZ8vwYpaiRTuFV1SYA8s61XRaOCtnVfhf0jcCijux8oyqfylrwHr0Duw0 E8RxMcKYCljbTuTYUH5G00vEhPWl8rNZt9/MQuZWMml9rA/66RbkDR61RoLku8WZIh99 yx07voDOtUKx8ewsEq9Ra30iYJTHxqNrSDq6714MWH7SRgZuyMTiYBtfDJ+JLmmwHPmD mQD1/YrqhS0Rw9rcy++QXnsvif2uE0XKBkU5JHaFvJoH9vxl7KSq33+ls9js2vuQAaJ5 ZjpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WQ8Ru/Aiwd2G+FkL3qyriRNZPvECbriQQI/dwO49yng=; b=XrccEzCgr+w6ZkpMAJQdl5cxyoL4+TuejqX5t+oliK3M0fRby9q3toUwSvVfF/nTLP gtAgcL7W3xG8vsiktoBcL7Hd06m4sIiJXI726RbwjO2YhKFuVWEBgE8ZNDPayLfo/194 Zgc+rfLXyUE8c28Zh0KwPhAXJJttjj1QvBEeJo1oc91hAZrCmZ6Ns5fFr9Jymn4OYFAe Wp0j+HOtEtNMKnCpMuYk27hcysEhIMe9kqY0ZtYRm/GYZZuTBWLV2BBjCtAgM/eWtX/J KGVM+OhV/Q7vkrGVrEZKgomuoslwXAMKjt0OeRen/N47jjVDDmW9TT1XS0HGMfpXl5wH /ODg== X-Gm-Message-State: AOAM531/EqMExwVF9RVfdarkbt2D6JUb6SbMHvQdW7LLjmDZrEYd2B1u c3RwDMEC/sCzAPGTdwdnLt7vmpUDWLzRarAxLPIs/w== X-Google-Smtp-Source: ABdhPJyx40xhkywGlzx8ptQXMY68C5k+LEaeoPJUmGrYNqBNHG0eSsbxpDUvHQKCRA/QKKq7aDQwFI+RrDD5XSb3OCs= X-Received: by 2002:a2e:8610:0:b0:249:7bc4:bbb8 with SMTP id a16-20020a2e8610000000b002497bc4bbb8mr19321127lji.370.1648995818942; Sun, 03 Apr 2022 07:23:38 -0700 (PDT) MIME-Version: 1.0 From: Orie Steele Date: Sun, 3 Apr 2022 09:23:27 -0500 Message-ID: To: "W3C Credentials CG (Public List)" , cose@ietf.org Content-Type: multipart/alternative; boundary="0000000000000645e605dbc0c2ae" Archived-At: Subject: [COSE] XMSS: Generating usable test vectors for JOSE and COSE X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2022 14:23:47 -0000 --0000000000000645e605dbc0c2ae Content-Type: text/plain; charset="UTF-8" Friends, We've been working on generating test vectors for: https://datatracker.ietf.org/doc/html/rfc8391 That we could use to register the `kty` and `alg` for XMSS such that it could be used by JOSE and COSE. https://github.com/transmute-industries/xmss I've reached the limits of my ability to move this ball forward, and am here to ask for help. I'm not very good with GoLang, and the original xmss source I am basing this on is difficult for me to extend. I am unsure how correct what I have is even with respect to the RFC, mostly needing to trust the original go source. I don't have multiple signature tests, which are pretty critical to gaining confidence that a stateful signature scheme is functioning correctly. If you are a Go / TypeScript developer, and would like to help with these issues, we welcome contributions. If we cannot get multiple implementations and stable test vectors for XMSS we will not attempt to register it for use with JOSE / COSE, but that can always be done later if the scheme becomes more popular. If you are interested in seeing XMSS for JOSE and COSE registered and have time and skill to volunteer to contribute to this objective, please message me or dive into issues and PRs. Regards, OS -- *ORIE STEELE* Chief Technical Officer www.transmute.industries --0000000000000645e605dbc0c2ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Friends,

We've been working on generating test = vectors for:=C2=A0https://datatracker.ietf.org/doc/html/rfc8391

That we could use= to register the `kty` and `alg` for XMSS such that it could be used by JOS= E and COSE.

https://github.com/transmute-industries/xmss

I've reached t= he limits of my ability to move this ball forward, and am here to ask for h= elp.

I'm not very good with=C2=A0GoLang, and the original xmss s= ource I am basing this on is difficult for me to extend.

I am unsure= how correct what I have is even with respect to the RFC, mostly needing to= trust the original=C2=A0go source.

I don't have multiple signat= ure tests, which are pretty critical to gaining confidence that a stateful = signature scheme is functioning correctly.

If you are a Go / TypeScr= ipt developer, and would like to help=C2=A0with these issues, we welcome co= ntributions.

If we cannot get multiple implementations and stable te= st vectors for XMSS we will not attempt to register it for use with JOSE / = COSE, but that can always be done later if the scheme becomes more popular.=

If you are interested in seeing XMSS for JOSE and COSE registered a= nd have time and skill to volunteer to contribute to this objective, please= message me or dive into issues and PRs.

Regards,

OS

--
ORIE STEELE
Chief Technical Officer
www.transmute.industries


--0000000000000645e605dbc0c2ae-- From nobody Tue Apr 5 07:32:09 2022 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 946143A08FF for ; Tue, 5 Apr 2022 07:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQN2X_tctnXM for ; Tue, 5 Apr 2022 07:31:56 -0700 (PDT) Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0CC3A08A9 for ; Tue, 5 Apr 2022 07:31:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 019AD425C356; Tue, 5 Apr 2022 07:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6KGkZoMoRMm; Tue, 5 Apr 2022 07:31:55 -0700 (PDT) Received: from [192.168.68.126] (pool-173-48-59-51.bstnma.fios.verizon.net [173.48.59.51]) by c8a.amsl.com (Postfix) with ESMTPSA id 79B7A425C195; Tue, 5 Apr 2022 07:31:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Megan Ferguson In-Reply-To: Date: Tue, 5 Apr 2022 10:31:54 -0400 Cc: Carsten Bormann , RFC Errata System , "ietf@augustcellars.com" , "cose@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <21BDC1F0-AB1E-4F75-94D5-6A28BB43D5BD@amsl.com> References: <20220331134832.96E6BAE92@rfcpa.amsl.com> <391F2FB0-30E5-47B5-BE6C-95E413F8DBF7@tzi.org> To: Thomas Fossati X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [COSE] [Editorial Errata Reported] RFC8152 (6909) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 14:32:02 -0000 Thomas, Just an FYI that I pointed this errata report out to the responsible AD = for RFC-to-be 9052 to consider. Thanks. RFC Editor/mf > On Mar 31, 2022, at 11:33 AM, Thomas Fossati = wrote: >=20 > Sorry for top-posting. > =20 > I agree with Carsten. Is it still possible to add this to = rfc-to-be-9052 ? > =20 > From: Carsten Bormann > Date: Thursday, 31 March 2022 at 14:53 > To: RFC Errata System > Cc: ietf@augustcellars.com , Thomas Fossati = , cose@ietf.org > Subject: Re: [COSE] [Editorial Errata Reported] RFC8152 (6909) >=20 > I think this change can be a good improvement, but the existing CDDL = is not =E2=80=9Cwrong=E2=80=9D, it is just not expressing all the = constraints that are then expressed in prose. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > On 2022-03-31, at 15:48, RFC Errata System = wrote: > >=20 > > The following errata report has been submitted for RFC8152, > > "CBOR Object Signing and Encryption (COSE)". > >=20 > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6909 > >=20 > > -------------------------------------- > > Type: Editorial > > Reported by: Thomas Fossati > >=20 > > Section: 3.1 > >=20 > > Original Text > > ------------- > > Generic_Headers =3D ( > > ? 1 =3D> int / tstr, ; algorithm identifier > > ? 2 =3D> [+label], ; criticality > > ? 3 =3D> tstr / int, ; content type > > ? 4 =3D> bstr, ; key identifier > > ? 5 =3D> bstr, ; IV > > ? 6 =3D> bstr ; Partial IV > > ) > >=20 > > Corrected Text > > -------------- > > Generic_Headers =3D ( > > ? 1 =3D> int / tstr, ; algorithm identifier > > ? 2 =3D> [+label], ; criticality > > ? 3 =3D> tstr / int, ; content type > > ? 4 =3D> bstr, ; key identifier > > ? ( 5 =3D> bstr // ; IV > > 6 =3D> bstr ) ; Partial IV > > ) > >=20 > > Notes > > ----- > > Section 3.1 says: "The "Initialization Vector" and "Partial = Initialization Vector" header parameters MUST NOT both be present in the = same security layer." > >=20 > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party =20 > > can log in to change the status and edit the report, if necessary.=20= > >=20 > > -------------------------------------- > > RFC8152 (draft-ietf-cose-msg-24) > > -------------------------------------- > > Title : CBOR Object Signing and Encryption (COSE) > > Publication Date : July 2017 > > Author(s) : J. Schaad > > Category : PROPOSED STANDARD > > Source : CBOR Object Signing and Encryption > > Area : Security > > Stream : IETF > > Verifying Party : IESG > >=20 > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. From nobody Tue Apr 5 14:00:51 2022 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 CAB363A119D for ; Tue, 5 Apr 2022 14:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vrd0zmld8R3Q for ; Tue, 5 Apr 2022 14:00:45 -0700 (PDT) Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DFE33A1198 for ; Tue, 5 Apr 2022 14:00:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 0D555427C641; Tue, 5 Apr 2022 14:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRz5SO5ld0a0; Tue, 5 Apr 2022 14:00:45 -0700 (PDT) Received: from [192.168.1.16] (cpe-76-95-228-63.socal.res.rr.com [76.95.228.63]) by c8a.amsl.com (Postfix) with ESMTPSA id C2402425C194; Tue, 5 Apr 2022 14:00:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Chris Smiley In-Reply-To: <20220331134832.96E6BAE92@rfcpa.amsl.com> Date: Tue, 5 Apr 2022 14:00:44 -0700 Cc: RFC Errata System , ietf@augustcellars.com, thomas.fossati@arm.com, cose@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <338003F6-8677-48E2-B637-7EF02F8B1837@amsl.com> References: <20220331134832.96E6BAE92@rfcpa.amsl.com> To: "Roman D. Danyliw" , Paul Wouters X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [COSE] [Editorial Errata Reported] RFC8152 (6909) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 21:00:50 -0000 Greetings, We are unable to verify this erratum that the submitter marked as = editorial. =20 Please note that we have changed the =E2=80=9CType=E2=80=9D of the = following errata=20 report to =E2=80=9CTechnical=E2=80=9D. As Stream Approver, please = review and set the=20 Status and Type accordingly (see the definitions at=20 https://www.rfc-editor.org/errata-definitions/). You may review the report at:=20 https://www.rfc-editor.org/errata/eid6909 Please see https://www.rfc-editor.org/how-to-verify/ for further=20 information on how to verify errata reports. Further information on errata can be found at:=20 https://www.rfc-editor.org/errata.php. Thank you. RFC Editor/cs > On Mar 31, 2022, at 6:48 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC8152, > "CBOR Object Signing and Encryption (COSE)". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6909 >=20 > -------------------------------------- > Type: Editorial > Reported by: Thomas Fossati >=20 > Section: 3.1 >=20 > Original Text > ------------- > Generic_Headers =3D ( > ? 1 =3D> int / tstr, ; algorithm identifier > ? 2 =3D> [+label], ; criticality > ? 3 =3D> tstr / int, ; content type > ? 4 =3D> bstr, ; key identifier > ? 5 =3D> bstr, ; IV > ? 6 =3D> bstr ; Partial IV > ) >=20 > Corrected Text > -------------- > Generic_Headers =3D ( > ? 1 =3D> int / tstr, ; algorithm identifier > ? 2 =3D> [+label], ; criticality > ? 3 =3D> tstr / int, ; content type > ? 4 =3D> bstr, ; key identifier > ? ( 5 =3D> bstr // ; IV > 6 =3D> bstr ) ; Partial IV > ) >=20 > Notes > ----- > Section 3.1 says: "The "Initialization Vector" and "Partial = Initialization Vector" header parameters MUST NOT both be present in the = same security layer." >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8152 (draft-ietf-cose-msg-24) > -------------------------------------- > Title : CBOR Object Signing and Encryption (COSE) > Publication Date : July 2017 > Author(s) : J. Schaad > Category : PROPOSED STANDARD > Source : CBOR Object Signing and Encryption > Area : Security > Stream : IETF > Verifying Party : IESG >=20 From nobody Sun Apr 10 15:20:55 2022 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 85EF73A12B6 for ; Sun, 10 Apr 2022 15:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=mnot.net header.b=R8TGGPnd; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=messagingengine.com header.b=GmI9+jjA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-DLHoTuXSaU for ; Sun, 10 Apr 2022 15:20:46 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6ED13A12A0 for ; Sun, 10 Apr 2022 15:20:46 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BD3925C0191 for ; Sun, 10 Apr 2022 18:13:39 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 10 Apr 2022 18:13:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-type:date:from:from:in-reply-to:mime-version:reply-to :sender:subject:subject:to:to; s=fm2; bh=osIRUaSIx4WuWUPjakn0HId utvhcVw6xALpyY1djyhU=; b=R8TGGPnd7scTs8cH8m5g/o2cce+T9mjnLVxGMLH cw5Ma3ll2loHBisGWX5/XY3mnUAz4qcO4mU1MbHWbUEnXgQ6kePmW9VKkFcC7GNS G57pvo8sYHj1VoBZZaXo8+IqKlZpIHkQYX1BjhUlON36R4d7JzNyC5QQDJriHIxO +cYPOyWLPf1QktbkKO6ocuF7iaAWjyrOdWIDZTljMtdGVWoRqsrRl0XpdVzZ0SLy 2Lx+/bNItpRu0z5EHPxW1flGZwC9tpt8BsEvV6XB2za1Q1xvUxGnodqU6OrhsHdS EhndZsAkvcOaBCV2wR/oBRa/s2tkcg0MVF2r9cXe/ZSGczQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:from :in-reply-to:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=osIRUaSIx4WuWUPjakn0HIdutvhcVw6xALpyY1djyhU=; b=GmI9+jjA eaEIy0Y/+mEwtD+JkWXCeqam6/rYeRsIH6QSkETS3i0TSQGTwOZlbYKFhN6xIGcU O5+a//oAmJAn5hLfvmQAKlWzvyHWvX8SsCgx69hOf8KO4NO80ywF+aSBINwyhf6w 70D+b1FFnE1HdT93df7rWCEAubnKYMixwZNoxUo7ybHJF1/Ng4UommOmklu9zDw4 aNWFw2C4EYhtPf1cIU9DOuZNH83GN/sl3pZuqlLmz8UiqijDBPoncLjzYDIPsrG9 p6O4XeTp64yZN+M3XtHVjKyCW69ovnRRPNmRZPMHsLAd29IaGbnLyk48QYZc9S0b YMC1xy9GDSBrag== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudekhedgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 10 Apr 2022 18:13:39 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============6665307493082985400==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cose@ietf.org Message-Id: <20220410222046.A6ED13A12A0@ietfa.amsl.com> Date: Sun, 10 Apr 2022 15:20:46 -0700 (PDT) Archived-At: Subject: [COSE] Weekly github digest (COSE Activity Summary) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2022 22:20:52 -0000 --===============6665307493082985400== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cose-wg/CBOR-certificates (+0/-0/=F0=9F=92=AC1) 1 issues received 1 new comments: - #93 SW-Implementation of CBOR-certificates (1 by derekatkins) https://github.com/cose-wg/CBOR-certificates/issues/93=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cose-wg/CBOR-certificates * https://github.com/cose-wg/Charter * https://github.com/cose-wg/cose-rfc8152bis * https://github.com/cose-wg/countersign * https://github.com/cose-wg/X509 --===============6665307493082985400== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (COSE Activity Summary)

Sunday April 10, 2022

Events without label "editorial"

Issues

cose-wg/CBOR-certificates (+0/-0/=F0=9F=92=AC1)

1 issues received 1 new comments:

Repositories tracked by this digest:
--===============6665307493082985400==-- From nobody Tue Apr 12 10:33:49 2022 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 6E1B03A1241 for ; Tue, 12 Apr 2022 10:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqjFdOPln2t4 for ; Tue, 12 Apr 2022 10:33:42 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D3A3A1242 for ; Tue, 12 Apr 2022 10:33:42 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id m14so7010563vsp.11 for ; Tue, 12 Apr 2022 10:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wZfCyEJV/OpYI6xbiPmzZc746tbnzTHmWfMA766bGXw=; b=SJap7b6UVYh4nT/baD3ho1r7i/1aXomusolflImdgWctKssI9toX20cZ3iRetMCZtc 555cwTLWM2hgLDTLAzmgrZwK0LHZ4sHh1SMbPrIXWqPTQ6fPTtLYXHH5dx3DNo8BUf1O LrqcO1ZrKwiQ0VpqQQtYJDP9UU1Cwpaqba60gO4i7a6RcBeGsX4AZofabCNX1Hu6f5ws z009Fu1Faw8ecyGRub65cP9DkWGo7HD8K3ddyiZeTeTqe8yVeTdjomt0E7aK+QmQ/qOR AuSWfCgOP0DrLjdQEeybjh0ueasbkHk5TvLoxGu7e9yf5hQxhqDfTNvykTjMavs37C31 EdSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wZfCyEJV/OpYI6xbiPmzZc746tbnzTHmWfMA766bGXw=; b=G1REqhuSeaUh5d5MN5C3165f8Hpv/1cWLoPeqI1Mkfi0QMO2YtszXCBzF9/+zXn18L TXRntyxvdTHTF+0d302FTJHTBLtypEWSociCtqNw3On+AYL0ThkIfce9vWh9NW7v0xtW 1f3GtNtlV0XoNtu7VG4t+DMtCrOxWZKC6Cb9fEBflBfVAza5WmrFFLczpFVxAD7EtWvl G25BJmcIeqEyFxZb15RHHceTVcrbWfyjJ/GNeIZxfz0YCITLk/QypBl5VeXaJ4Z0I0Q7 E576LcjoWlaf/8wwRUyv3fKZjKcInNAxNQ2nUT6bNBFGD/mr/pVtCZscMr5HmSIQSfo/ QIUw== X-Gm-Message-State: AOAM531GhpxHvS2goIgKPzNRya+SkatA96cuUCz7TSB0U02o2wBAF9BH pk1/R0HGhsTvK+eanDatAQRn6NASN8Tb3PtIQYI280do X-Google-Smtp-Source: ABdhPJzcn5nleO+yBeqaOg5onTf44X1YNDeMXMSWJk1dJzkSSOlRJ2kgjxgJBmdCSNxv2xnPq3v8y71xKSFdpdBIiE4= X-Received: by 2002:a67:c28c:0:b0:328:f05:46b8 with SMTP id k12-20020a67c28c000000b003280f0546b8mr9115915vsj.53.1649784821291; Tue, 12 Apr 2022 10:33:41 -0700 (PDT) MIME-Version: 1.0 References: <5E870305-9ED3-4FD8-BF7D-257CB92403A4@vigilsec.com> <53B4F33C-B908-45E4-9B4B-50939B4494C9@vigilsec.com> In-Reply-To: From: Jonathan Hammell Date: Tue, 12 Apr 2022 13:33:28 -0400 Message-ID: To: Christian Flach Cc: Russ Housley , Oleksandr Peletskyi , Sonja Laurila , cose Content-Type: multipart/alternative; boundary="0000000000003a9d5205dc7876c0" Archived-At: Subject: Re: [COSE] Questions about signatures and countersignatures X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 17:33:48 -0000 --0000000000003a9d5205dc7876c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Christian, A while ago, I produced some of the countersignature examples for the I-D. I've been reviewing my code in light of the questions you have raised and some discussion that I had with Russ, and I believe that there is ambiguity remaining in the I-D that is leading to these different interpretations. I would love to work with you to do some interoperability testing and ensure the examples are correct before the I-D is published. Jonathan On Fri, Mar 25, 2022 at 4:25 PM Christian Flach wrote: > Got it, thanks! > > On Fri, Mar 25, 2022 at 9:03 PM Russ Housley wrote= : > >> No, I'm not suggesting a change. I'm trying to describe the reason one >> performs a countersignature. >> >> Russ >> >> On Mar 25, 2022, at 10:20 AM, Christian Flach < >> cmfcmf=3D40google.com@dmarc.ietf.org> wrote: >> >> Hi Russ, >> >> Thanks a lot for your answers! >> >> Regarding my second question, you write 'However, a countersignature is = a >> signature over a previous signature, another approach would be to put th= e >> signature_value bstr in the payload'. You are suggesting a change to >> draft-ietf-cose-countersign here, correct? Currently, if I read the draf= t >> correctly, the COSE_Sign1.signature field is present in >> Countersign_structure.other_fields and Countersign_structure.payload >> contains the message payload. >> >> Christian >> >> On Mon, Mar 14, 2022 at 10:15 PM Russ Housley >> wrote: >> >>> Christian: >>> >>> I have been very slow in responding. Apologies. I hope this late >>> response is helpful. >>> >>> 1. I think that RFC 8152, Section 4.3 is the place to look. I think >>> the detached payload is placed in the 'payload' field for signature >>> calculation. >>> >>> 2. Countersignatures are signatures over another previously calculated >>> signature. That said, we probably should be more clear in the >>> draft-ietf-cose-countersign about what goes in the payload field. Check= ing >>> with one implementer, that person also used COSE_Sign1.payload of nil i= n >>> when the payload is detached. However, a countersignature is a signatu= re >>> over a previous signature, another approach would be to put the >>> signature_value bstr in the payload. I am thinking that the second >>> approach make the most sense, and it is parallel to this part of the >>> specification: >>> >>> "When done on a COSE_Mac or COSE_Mac0, the payload is included as well >>> as the MAC value". >>> >>> 3. This seems right to me. In RFC 5652, I added text to be very clear >>> what a "signature value" means. It does not include the tag and length= . >>> Is there something that we need to in draft-ietf-cose-countersign to >>> provide similar clarity? >>> >>> 4. Section 3 of draft-ietf-cose-countersign says: >>> >>> "When done on >>> a COSE_Sign, this is the same as applying a second signature to the >>> payload and adding a parallel signature as a new COSE_Signature is >>> the preferred method." >>> >>> I think you are pointing out that COSE_Sign does not appear in the list >>> of COSE structures in Section 2, where it says: >>> >>> "The countersignature header >>> parameter can occur as an unprotected attribute in any of the >>> following structures: COSE_Sign1, COSE_Signature, COSE_Encrypt, >>> COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0." >>> >>> I think we should add COSE_Sign in Section 2. >>> >>> 5. A countersignture covers one previously calculated signature. It >>> does not match the semantics in the question. One approach would be to >>> define an application that signs another COSE document that already has >>> multiple signatures. A second approach would be to use countersignatur= e >>> for each of the previously calculated signatures. >>> >>> The alternative would be for a countersignature to cover the array of >>> signatures. I have not thought about that, and I wonder what about the >>> semantics of doing so. >>> >>> 6. I do not know why this document is not an RFC yet. The approval >>> process is going very slowly. >>> >>> Russ >>> >>> >>> On Feb 11, 2022, at 8:58 AM, Christian Flach < >>> cmfcmf=3D40google.com@dmarc.ietf.org> wrote: >>> >>> Hi everyone, >>> >>> We are looking into using COSE for signing some CBOR data. After readin= g >>> the latest versions of the drafts, we had a few questions and were >>> wondering whether you could provide us some clarification: >>> >>> >>> 1. We have a COSE_Sign1 / COSE_Sign structure with a =E2=80=9Cpayloa= d=E2=80=9D field >>> set to nil, because we want the payload to not be part of the struct= ure. >>> I=E2=80=99m a bit confused about how to correctly construct the Sig_= structure, >>> specifically the =E2=80=9Cexternal_aad=E2=80=9D and =E2=80=9Cpayload= =E2=80=9D fields. The description of >>> Sig_structure.external_aad says =E2=80=9CThe externally supplied dat= a from the >>> application encoded in a bstr type=E2=80=9D, and the description of >>> Sig_structure.payload says =E2=80=9CThe payload to be signed encoded= in a bstr >>> type. The payload is placed here independent of how it is transporte= d.=E2=80=9D. >>> Both descriptions sound like they would match our detached payload. >>> The Java COSE implementation seems to place the detached payload in >>> `payload` and an empty byte string in `external_aad`. Is this the co= rrect >>> way to build the Sig_structure for a COSE_Sign1 / COSE_Sign with a d= etached >>> payload? >>> >>> >>> Section 4.3, which, I think, is about =E2=80=9Cexternal_aad=E2=80=9D, b= egins with =E2=80=9COne >>> of the features offered in the COSE document is the ability for >>> applications to provide additional data to be authenticated, but that i= s >>> not carried as part of the COSE object.=E2=80=9C. I would appreciate a = clearer >>> distinction between =E2=80=9Cdetached payloads=E2=80=9D and =E2=80=9Cex= ternally supplied data=E2=80=9D, >>> since both appear to achieve similar goals, namely the data to not be p= art >>> of the COSE structure. When would an application use one or the other? >>> >>> The following questions are all about counter signatures v2. >>> >>> >>> 1. I=E2=80=99d like to double check whether I understood the constru= ction of >>> the Countersign_structure correctly: If I want to countersign a COSE= _Sign1 >>> structure with a detached payload (COSE_Sign1.payload =3D nil), is t= he >>> following correct? >>> >>> >>> Countersign_structure =3D [ >>> context : "CounterSignatureV2", ; Identifier >>> body_protected : empty_or_serialized_map, ; Protected headers of >>> COSE_Sign1 >>> sign_protected : empty_or_serialized_map, ; Protected headers of >>> COSE_Countersignature >>> external_aad : bstr, ; Empty >>> payload : bstr, ; The detached payload >>> other_fields : [ bstr ] ; An array with a single element: the >>> signature field of COSE_Sign1 >>> ] >>> >>> >>> 1. Similarly, if I wanted to countersign a COSE_Signature that is >>> part of a COSE_Sign structure with a detached payload (COSE_Sign.pay= load =3D >>> nil), is the following correct? >>> >>> >>> Countersign_structure =3D [ >>> context : "CounterSignature", ; Identifier >>> body_protected : empty_or_serialized_map, ; Protected headers of >>> COSE_Signature >>> sign_protected : empty_or_serialized_map, ; Protected headers of >>> COSE_Countersignature >>> external_aad : bstr, ; Empty >>> payload : bstr, ; The signature field of COSE_Signature >>> ] >>> >>> If this is correct, is it intentional that the detached payload IS part >>> of the Countersign_structure when countersigning COSE_Sign1, but not wh= en >>> countersigning a COSE_Signature that is part of the COSE_Sign signature= s >>> array? >>> >>> >>> 1. Section 3 =E2=80=9CVersion 2 Countersignatures=E2=80=9D says =E2= =80=9CThis document >>> extends the context of a countersignature to allow it to be applied = to all >>> of the security structures defined=E2=80=9D. This sounds like it wou= ld be allowed >>> to countersign COSE_Sign (even if it doesn=E2=80=99t make much sense= , as is also >>> described in section 3). However, section 2 =E2=80=9CCountersignatur= e Header >>> Parameters=E2=80=9D says that the countersignature header can only o= ccur on a >>> selected subset of COSE structures, and specifically does not list >>> COSE_Sign as a possible structure to countersign. >>> >>> >>> >>> 1. There does not currently seem to be a way to correctly >>> countersign a COSE_Sign structure with a single countersignature. Le= t=E2=80=99s >>> take the notary analogy: Two people sign a contract, and the notary = places >>> their (single) countersignature on the same document, confirming tha= t the >>> two persons signed the contract. The same would not be possible with= COSE, >>> I think. With COSE, the notary would need to countersign both signat= ures >>> separately, i.e. add a countersignature header to both COSE_Signatur= e >>> entries of the the COSE_Sign.signatures array. Is my understanding c= orrect? >>> 2. Has there been progress on registering temporary code points in >>> the COSE Header parameters table for counter signatures v2? I found = an >>> email from 2020 about this topic ( >>> https://mailarchive.ietf.org/arch/msg/cose/88jwAsA4Rh61oP3XR9KGtasNl= wo/), >>> which seems to have been in favor of registering these, but from wha= t I can >>> tell, they haven=E2=80=99t been registered yet. >>> >>> >>> Christian >>> >>> -- >>> >>> [image: Google Logo] >>> Christian Flach (he/him) >>> Software Engineer >>> cmfcmf@google.com >>> >>> Google Germany GmbH >>> Erika-Mann-Stra=C3=9Fe 33 >>> 80636 M=C3=BCnchen >>> >>> Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian >>> Registergericht und -nummer: Hamburg, HRB 86891 >>> Sitz der Gesellschaft: Hamburg >>> >>> Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise er= halten >>> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, >>> l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie mich= bitte wissen, >>> dass die E-Mail an die falsche Person gesendet wurde. >>> >>> >>> This e-mail is confidential. If you received this communication by >>> mistake, please don't forward it to anyone else, please erase all copie= s >>> and attachments, and please let me know that it has gone to the wrong >>> person. >>> _______________________________________________ >>> COSE mailing list >>> COSE@ietf.org >>> https://www.ietf.org/mailman/listinfo/cose >>> >>> >>> >> >> -- >> >> [image: Google Logo] >> Christian Flach (he/him) >> Software Engineer >> cmfcmf@google.com >> >> Google Germany GmbH >> Erika-Mann-Stra=C3=9Fe 33 >> 80636 M=C3=BCnchen >> >> Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian >> Registergericht und -nummer: Hamburg, HRB 86891 >> Sitz der Gesellschaft: Hamburg >> >> Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise erh= alten >> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, >> l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie mich = bitte wissen, >> dass die E-Mail an die falsche Person gesendet wurde. >> >> >> This e-mail is confidential. If you received this communication by >> mistake, please don't forward it to anyone else, please erase all copies >> and attachments, and please let me know that it has gone to the wrong >> person. >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >> >> >> > > -- > > [image: Google Logo] > Christian Flach (he/him) > Software Engineer > cmfcmf@google.com > > Google Germany GmbH > > Erika-Mann-Stra=C3=9Fe 33 > > 80636 M=C3=BCnchen > > Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian > > Registergericht und -nummer: Hamburg, HRB 86891 > > Sitz der Gesellschaft: Hamburg > > Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise erha= lten > haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, > l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie mich b= itte wissen, > dass die E-Mail an die falsche Person gesendet wurde. > > > > This e-mail is confidential. If you received this communication by > mistake, please don't forward it to anyone else, please erase all copies > and attachments, and please let me know that it has gone to the wrong > person. > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --0000000000003a9d5205dc7876c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christian,
A while ago, I produced some of the countersignature examples for t= he I-D.=C2=A0 I've been reviewing my code in light of the questions you= have raised and some discussion that I had with Russ, and I believe that t= here is ambiguity remaining in the I-D that is leading to these different i= nterpretations.=C2=A0

I would love to work with you to do some interoperability tes= ting and ensure the examples are correct before the I-D is published.
=

Jonathan

On Fri, = Mar 25, 2022 at 4:25 PM Christian Flach <cmfcmf=3D40google.com@dmarc.ietf.org> wrote:
Got it= , thanks!

On Fri, Mar 25, 2022 at 9:03 PM Russ Housley <housley@vigilsec.com> wrote= :
No, I'= ;m not suggesting a change.=C2=A0 I'm trying to describe the reason one= performs a countersignature.

Russ

On Mar 25, 2022, at 10:20 AM, Christian Flach <cmfc= mf=3D40google.com@dmarc.ietf.org> wrote:

Hi Russ,

Thanks a lot for your answers!
Regarding my second question, you write 'However, a counte= rsignature is a signature over a previous signature, another approach would= be to put the signature_value bstr in the payload'. You are suggesting= a change to draft-ietf-cose-countersign here, correct? Currently, if I rea= d the draft correctly, the COSE_Sign1.signature field is present in Counter= sign_structure.other_fields and Countersign_structure.payload contains the = message payload.

Christian

On Mon, Mar 14, 20= 22 at 10:15 PM Russ Housley <housley@vigilsec.com> wrote:
Christian:

I hav= e been very slow in responding.=C2=A0 Apologies.=C2=A0 I hope this late res= ponse is helpful.

1.=C2=A0 I think that RFC 8152, = Section 4.3 is the place to look.=C2=A0 I think the detached payload is pla= ced in the 'payload' field for signature calculation.
2.=C2=A0 Countersignatures are signatures over another previous= ly calculated signature. That said, we probably should be more clear in the= draft-ietf-cose-countersign about what goes in the payload field. Checking= with one implementer, that person also used COSE_Sign1.payload of nil in w= hen the payload is detached.=C2=A0 However, a countersignature is a signatu= re over a previous signature, another approach would be to put the signatur= e_value bstr in the payload.=C2=A0 I am thinking that the second approach m= ake the most sense, and it is parallel to this part of the specification:

"= When done on a COSE_Mac or COSE_Mac0, the payload is included as well as th= e MAC value".

3.=C2=A0 This seems right to me= .=C2=A0 In RFC 5652, I added text to be very clear what a "signature v= alue" means.=C2=A0 It does not include the tag and length.=C2=A0 Is th= ere something that we need to in draft-ietf-cose-countersign to provide sim= ilar clarity?

4. Section 3 of draft-ietf-cose= -countersign says:

=C2=A0"When done on
a COSE_Sign, this is the same as applying a second signa= ture to the
payload and add= ing a parallel signature as a new COSE_Signature is
the preferred method."
I think you are pointing out that COSE_Sign does not appear in = the list of COSE structures in Section 2, where it says:

"The countersignat= ure header
=C2=A0 =C2=A0 =C2=A0 parameter can occur as an unprotected at= tribute in any of the
=C2=A0 =C2=A0 =C2=A0 following structures: COSE_Si= gn1, COSE_Signature, COSE_Encrypt,
=C2=A0 =C2=A0 =C2=A0 COSE_recipient, = COSE_Encrypt0, COSE_Mac, and COSE_Mac0."

I th= ink we should add COSE_Sign in Section 2.

5.= =C2=A0 A countersignture covers one previously calculated signature.=C2=A0 = It does not match the semantics in the question.=C2=A0 One approach would b= e to define an application that signs another COSE document that already ha= s multiple signatures.=C2=A0 A second approach would be to use countersigna= ture for each of the previously calculated signatures.

=
The alternative would be for a countersignature to cover the array of = signatures.=C2=A0 I have not thought about that, and I wonder what about th= e semantics of doing so.

6.=C2=A0 I do not know wh= y this document is not an RFC yet.=C2=A0 The approval process is going very= slowly.

Russ


On Feb 11, 2022, at 8:58 AM, Christian Flach &= lt;cmfcmf=3D40google.com@dmarc.ietf.org> wrote:

Hi everyon= e,

We are looking into using COSE for = signing some CBOR data. After reading the latest versions of the drafts, we= had a few questions and were wondering whether you could provide us some c= larification:

  1. We h= ave a COSE_Sign1 / COSE_Sign structure with a =E2=80=9Cpayload=E2=80=9D fie= ld set to nil, because we want the payload to not be part of the structure.= I=E2=80=99m a bit confused about how to correctly construct the Sig_struct= ure, specifically the =E2=80=9Cexternal_aad=E2=80=9D and =E2=80=9Cpayload= =E2=80=9D fields. The description of Sig_structure.external_aad says =E2=80= =9CThe externally supplied data from the application encoded in a bstr type= =E2=80=9D, and the description of Sig_structure.payload says =E2=80=9CThe p= ayload to be signed encoded in a bstr type. The payload is placed here inde= pendent of how it is transported.=E2=80=9D. Both descriptions sound like th= ey would match our detached payload.
    The Java COSE implementation seems to place the detached payload in = `payload` and an empty byte string in `external_aad`. Is this the correct w= ay to build the Sig_structure for a COSE_Sign1 / COSE_Sign with a detached = payload?

Se= ction 4.3, which, I think, is about =E2=80=9Cexternal_aad=E2=80=9D, begins = with =E2=80=9COne of the features offered in the COSE document is the abili= ty for applications to provide additional data to be authenticated, but tha= t is not carried as part of the COSE object.=E2=80=9C. I would appreciate a= clearer distinction between =E2=80=9Cdetached payloads=E2=80=9D and =E2=80= =9Cexternally supplied data=E2=80=9D, since both appear to achieve similar = goals, namely the data to not be part of the COSE structure. When would an = application use one or the other?

The = following questions are all about counter signatures v2.

  • I=E2=80=99d like to doub= le check whether I understood the construction of the Countersign_structure= correctly: If I want to countersign a COSE_Sign1 structure with a detached= payload (COSE_Sign1.payload =3D nil), is the following correct?

  • Countersign_structure =3D [
    =C2=A0=C2=A0context : "CounterSignatureV2"= , ; Identifier
    =C2=A0=C2=A0body_protected : empty_or_serializ= ed_map, ; Protected headers = of COSE_Sign1
    =C2=A0=C2=A0sign_protected := empty_or_serialized_map, ; = Protected headers of COSE_Countersignature
    =C2=A0=C2=A0external_aad : bstr, = = ; Empty
    =C2=A0=C2=A0payload : bstr, ; The detached payload
    <= span style=3D"font-size:10pt;font-family:Arial;background-color:transparent= ;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:= baseline;white-space:pre-wrap">=C2=A0=C2=A0other_fields : [ bstr ] = ;= An array with a single element: the signatu= re field of COSE_Sign1
    ]

    <= ol style=3D"margin-top:0px;margin-bottom:0px" start=3D"3">
  • Similarly, if I wanted = to countersign a COSE_Signature that is part of a COSE_Sign structure with = a detached payload (COSE_Sign.payload =3D nil), is the following correct?

  • Countersign_structure =3D [
    = =C2=A0=C2=A0context : "CounterSignatur= e", ;= Identifier
    =C2=A0=C2=A0body_protected : e= mpty_or_serialized_map, ; = Protected headers of COSE_Signature
    =C2=A0= =C2=A0sign_protected : empty_or_serialized_map, ; Protected headers of COSE_Countersignature
    =C2=A0=C2=A0external_aad : bstr, = ; Empty
    <= span style=3D"font-size:10pt;font-family:Arial;background-color:transparent= ;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:= baseline;white-space:pre-wrap">=C2=A0=C2=A0payload : bstr, <= span style=3D"font-size:10pt;font-family:Arial;background-color:transparent= ;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:= baseline;white-space:pre-wrap"> = ; The signature field of COSE_Signature
    ]<= /span>

    If this is correct, i= s it intentional that the detached payload IS part of the Countersign_struc= ture when countersigning COSE_Sign1, but not when countersigning a COSE_Sig= nature that is part of the COSE_Sign signatures array?

    1. Section 3 =E2=80=9CVersion= 2 Countersignatures=E2=80=9D says =E2=80=9CThis document extends the conte= xt of a countersignature to allow it to be applied to all of the security s= tructures defined=E2=80=9D. This sounds like it would be allowed to counter= sign COSE_Sign (even if it doesn=E2=80=99t make much sense, as is also desc= ribed in section 3). However, section 2 =E2=80=9CCountersignature Header Pa= rameters=E2=80=9D says that the countersignature header can only occur on a= selected subset of COSE structures, and specifically does not list COSE_Si= gn as a possible structure to countersign.

    1. There does not currently se= em to be a way to correctly countersign a COSE_Sign structure with a single= countersignature. Let=E2=80=99s take the notary analogy: Two people sign a= contract, and the notary places their (single) countersignature on the sam= e document, confirming that the two persons signed the contract. The same w= ould not be possible with COSE, I think. With COSE, the notary would need t= o countersign both signatures separately, i.e. add a countersignature heade= r to both COSE_Signature entries of the the COSE_Sign.signatures array. Is = my understanding correct?
    2. Has there been progress on registering temporary code points in= the COSE Header parameters table for counter signatures v2? I found an ema= il from 2020 about this topic (https:= //mailarchive.ietf.org/arch/msg/cose/88jwAsA4Rh61oP3XR9KGtasNlwo/), which seems to have been in favor of registering these, b= ut from what I can tell, they haven=E2=80=99t been registered yet.


    = --

    3D"Google<= tr style=3D"margin:0px;padding:0px">
    Christian Flach (he/him)
    Software Engineer
    cmfcmf@google.com

    <= /div>
    Goo= gle Germany GmbH
    Erika-Mann-Stra=C3=9Fe 33
    80636 M=C3=BCnchen

    <= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">Gesch=C3=A4ftsf= =C3=BChrer: Paul Manicle, Liana Sebastian
    Registergericht und -nummer: Hamburg= , HRB 86891
    Sitz der Gesellschaft: Hamburg

    Diese E-Mail ist vertraulich. Fall= s Sie diese f=C3=A4lschlicherweise erhalten haben sollten, leiten Sie diese= bitte nicht an jemand anderes weiter, l=C3=B6schen Sie alle Kopien und Anh= =C3=A4nge davon und lassen Sie mich bitte wissen, dass die E-Mail an die fa= lsche Person gesendet wurde.=C2=A0

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

    This e-= mail is confidential. If you received this communication by mistake, please= don't forward it to anyone else, please erase all copies and attachmen= ts, and please let me know that it has gone to the wrong person.
    _______________________________________________
    COSE mailing list
    COSE@ietf.org
    https://= www.ietf.org/mailman/listinfo/cose



    --

    3D"Google
    Christian Fla= ch (he/him)
    Software Engi= neer
    cmfcmf@google.com

    Google Germany = GmbH
    Erika-Mann-Stra=C3=9Fe 33
    80636 M=C3=BCnchen

    Gesch=C3=A4ftsf=C3=BChrer: P= aul Manicle, Liana Sebastian
    Registergericht und -nummer: Hamburg, HRB 86891
    Sitz= der Gesellschaft: Hamburg

    Diese E-Mail ist vertraulich. Falls Sie diese f= =C3=A4lschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht = an jemand anderes weiter, l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge dav= on und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person = gesendet wurde.=C2=A0

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

    This e-mail is confi= dential. If you received this communication by mistake, please don't fo= rward it to anyone else, please erase all copies and attachments, and pleas= e let me know that it has gone to the wrong person.
    _______________________________________________
    COSE mailing list
    COSE@ietf.org
    https://= www.ietf.org/mailman/listinfo/cose



    --

    3D"Google
    Christian Fla= ch (he/him)
    Software Engi= neer
    cmfcmf@google.com

    Google = Germany GmbH

    Erika-Mann-Stra=C3=9Fe 33

    80636 M=C3=BCnchen


    Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian

    Registerg= ericht und -nummer: Hamburg, HRB 86891

    Sitz der Gesellschaft: Hamburg<= /span>


    Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherwei= se erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes w= eiter, l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie m= ich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.=C2= =A0

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

    This e-mail is confidential. I= f you received this communication by mistake, please don't forward it t= o anyone else, please erase all copies and attachments, and please let me k= now that it has gone to the wrong person.

    _______________________________________________
    COSE mailing list
    COSE@ietf.org
    https://www.ietf.org/mailman/listinfo/cose
    --0000000000003a9d5205dc7876c0-- From nobody Tue Apr 12 12:38:25 2022 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 F1A073A16D4 for ; Tue, 12 Apr 2022 12:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhBCo0NmPmpB for ; Tue, 12 Apr 2022 12:38:18 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DBAA3A16A9 for ; Tue, 12 Apr 2022 12:38:18 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id f32so1460450vsv.1 for ; Tue, 12 Apr 2022 12:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4MIZZGkZrt2nj3yjEyTPe7vRRe6jWn4wHa7tnadOsog=; b=CAGgnq+ukfsdjZ9eRQoOQC6rgwZcyGeQYlbcfILHPnMxBzTcNF1eAotzeHipTvYto8 2/FbNgPXaF8f/8CYbgC8UJob/7g7uZR0SubYV9nzd+J9uyz5uzfaHS838M3SomXqKoRd 0m5G/n/JR3XmNufgSy8iJmfhk77dejkKqFybyepbVd15CGX6ipvlnZqwvJ5QWvyWw7Tj DB6Pj5gDb4VRa+CaZ1DiHAN0C+Smzzfap3uwEp5qQKOXJ4gK4u4UAgvcbJFhsX+grRGI X9mLETB/P5R9oaaxy5txrOtoxyYQYkxBGC0KuS6XkYqUx3Y7/WSwTxw2K/tOJmnqTWNF IOzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4MIZZGkZrt2nj3yjEyTPe7vRRe6jWn4wHa7tnadOsog=; b=u8I6DL9BsXVOIgjVHYtSOqGWiZbj2ktBawwsmM7zKkBR5Ay5lWVsjRkoauN7QxU8pp nkvQbRq6yevpMhroYpY9ARSoYYJJcK6ozAS6pSSKAZMzd865DVGGNLDWZS3PHQqgIKY0 kUf4m0Vgh0L2BnzCvEPl9Ke/uV71YGadhR98ka3qXgCeYvhfX1rrFiUJpPHrzBOz8+h9 EMWJ+mT7ldMCS8356eKRcLw0FWCRrLLEz+z50b5OANuCmZonjek/W96ApA+6nFHCjMol WqB55n5PREOWZzImrP5yDax3hk57Cc/OT72id1+44nZrfVH5diQHZbxnNel7tlXtpr4S IN9A== X-Gm-Message-State: AOAM532GI1j2vBHArGOmyqbxIqZ4PZVi4YZmMb+VNxY7qFyemba11mDD 70PiSPW0paee0K66AVhgaBq6YUV8ugqP9pb50h8= X-Google-Smtp-Source: ABdhPJw/lEVeHq25HPfX+3nXpC+YY/7FcGJaFMO984caFffCGeY+o4vJgKxY9n4yR3bTjw80L+G7K0vRmni0YFZhIRE= X-Received: by 2002:a05:6102:6d3:b0:325:cfa3:44b with SMTP id m19-20020a05610206d300b00325cfa3044bmr12309570vsg.23.1649792297163; Tue, 12 Apr 2022 12:38:17 -0700 (PDT) MIME-Version: 1.0 References: <5E870305-9ED3-4FD8-BF7D-257CB92403A4@vigilsec.com> <53B4F33C-B908-45E4-9B4B-50939B4494C9@vigilsec.com> In-Reply-To: <53B4F33C-B908-45E4-9B4B-50939B4494C9@vigilsec.com> From: Jonathan Hammell Date: Tue, 12 Apr 2022 15:38:03 -0400 Message-ID: To: Russ Housley Cc: Christian Flach , Oleksandr Peletskyi , Sonja Laurila , cose@ietf.org Content-Type: multipart/alternative; boundary="000000000000d35f9705dc7a3393" Archived-At: Subject: Re: [COSE] Questions about signatures and countersignatures X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2022 19:38:23 -0000 --000000000000d35f9705dc7a3393 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Russ, I agree with you that a countersignature on COSE_Sign1 must have the signature_value of the underlying message in the ToBeSigned input for the countersignature; however, my interpretation of the current text for the payload of the Countersign_structure is aligned with Christian's (for COSE_Sign1). COSE's countersignature was generalized to apply to all COSE structures, so the payload may not always be a signature_value as one might intuitively expect. The design discussions for CounterSignatureV2 is in this thread: https://mailarchive.ietf.org/arch/msg/cose/6-vyoetZboIdrwwEYoYlj9QY_3Q/ My recollection was that the group decided to proceed with the third option, that is including every bstr value in the structure. I believe this is consistent with step 6 in Section 3.3. As Jim discussed in the above thread, countersignature on COSE_Sign1 was an example where the original method defined in RFC 8152 failed because there was no way to capture the signature_value bstr since it was the third bstr in the COSE message structure. I disagree with the interpretation that I believe you and Christian have for applying a countersignature to the COSE_Sign structure. You may find it surprising, but that countersignature will not actually sign the signature_value of any of the signers. As written in Section 3 of the I-D, "When done on a COSE_Sign, this is the same as applying a second signature to the payload and adding a parallel signature as a new COSE_Signature is the preferred method." I have confirmed that the message payload is included and not the signature_values nor signature array by validating the countersignature in the example from C.1.3 of RFC 8152. In order to do the traditional countersignature logic of signing a signature value, one would apply the countersignature on the specific COSE_Signature structure in the signatures array of COSE_Sign. Jonathan On Fri, Mar 25, 2022 at 4:03 PM Russ Housley wrote: > No, I'm not suggesting a change. I'm trying to describe the reason one > performs a countersignature. > > Russ > > On Mar 25, 2022, at 10:20 AM, Christian Flach < > cmfcmf=3D40google.com@dmarc.ietf.org> wrote: > > Hi Russ, > > Thanks a lot for your answers! > > Regarding my second question, you write 'However, a countersignature is a > signature over a previous signature, another approach would be to put the > signature_value bstr in the payload'. You are suggesting a change to > draft-ietf-cose-countersign here, correct? Currently, if I read the draft > correctly, the COSE_Sign1.signature field is present in > Countersign_structure.other_fields and Countersign_structure.payload > contains the message payload. > > Christian > > On Mon, Mar 14, 2022 at 10:15 PM Russ Housley > wrote: > >> Christian: >> >> I have been very slow in responding. Apologies. I hope this late >> response is helpful. >> >> 1. I think that RFC 8152, Section 4.3 is the place to look. I think th= e >> detached payload is placed in the 'payload' field for signature calculat= ion. >> >> 2. Countersignatures are signatures over another previously calculated >> signature. That said, we probably should be more clear in the >> draft-ietf-cose-countersign about what goes in the payload field. Checki= ng >> with one implementer, that person also used COSE_Sign1.payload of nil in >> when the payload is detached. However, a countersignature is a signatur= e >> over a previous signature, another approach would be to put the >> signature_value bstr in the payload. I am thinking that the second >> approach make the most sense, and it is parallel to this part of the >> specification: >> >> "When done on a COSE_Mac or COSE_Mac0, the payload is included as well a= s >> the MAC value". >> >> 3. This seems right to me. In RFC 5652, I added text to be very clear >> what a "signature value" means. It does not include the tag and length. >> Is there something that we need to in draft-ietf-cose-countersign to >> provide similar clarity? >> >> 4. Section 3 of draft-ietf-cose-countersign says: >> >> "When done on >> a COSE_Sign, this is the same as applying a second signature to the >> payload and adding a parallel signature as a new COSE_Signature is >> the preferred method." >> >> I think you are pointing out that COSE_Sign does not appear in the list >> of COSE structures in Section 2, where it says: >> >> "The countersignature header >> parameter can occur as an unprotected attribute in any of the >> following structures: COSE_Sign1, COSE_Signature, COSE_Encrypt, >> COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0." >> >> I think we should add COSE_Sign in Section 2. >> >> 5. A countersignture covers one previously calculated signature. It >> does not match the semantics in the question. One approach would be to >> define an application that signs another COSE document that already has >> multiple signatures. A second approach would be to use countersignature >> for each of the previously calculated signatures. >> >> The alternative would be for a countersignature to cover the array of >> signatures. I have not thought about that, and I wonder what about the >> semantics of doing so. >> >> 6. I do not know why this document is not an RFC yet. The approval >> process is going very slowly. >> >> Russ >> >> >> On Feb 11, 2022, at 8:58 AM, Christian Flach < >> cmfcmf=3D40google.com@dmarc.ietf.org> wrote: >> >> Hi everyone, >> >> We are looking into using COSE for signing some CBOR data. After reading >> the latest versions of the drafts, we had a few questions and were >> wondering whether you could provide us some clarification: >> >> >> 1. We have a COSE_Sign1 / COSE_Sign structure with a =E2=80=9Cpayload= =E2=80=9D field >> set to nil, because we want the payload to not be part of the structu= re. >> I=E2=80=99m a bit confused about how to correctly construct the Sig_s= tructure, >> specifically the =E2=80=9Cexternal_aad=E2=80=9D and =E2=80=9Cpayload= =E2=80=9D fields. The description of >> Sig_structure.external_aad says =E2=80=9CThe externally supplied data= from the >> application encoded in a bstr type=E2=80=9D, and the description of >> Sig_structure.payload says =E2=80=9CThe payload to be signed encoded = in a bstr >> type. The payload is placed here independent of how it is transported= .=E2=80=9D. >> Both descriptions sound like they would match our detached payload. >> The Java COSE implementation seems to place the detached payload in >> `payload` and an empty byte string in `external_aad`. Is this the cor= rect >> way to build the Sig_structure for a COSE_Sign1 / COSE_Sign with a de= tached >> payload? >> >> >> Section 4.3, which, I think, is about =E2=80=9Cexternal_aad=E2=80=9D, be= gins with =E2=80=9COne of >> the features offered in the COSE document is the ability for application= s >> to provide additional data to be authenticated, but that is not carried = as >> part of the COSE object.=E2=80=9C. I would appreciate a clearer distinct= ion between >> =E2=80=9Cdetached payloads=E2=80=9D and =E2=80=9Cexternally supplied dat= a=E2=80=9D, since both appear to >> achieve similar goals, namely the data to not be part of the COSE >> structure. When would an application use one or the other? >> >> The following questions are all about counter signatures v2. >> >> >> 1. I=E2=80=99d like to double check whether I understood the construc= tion of >> the Countersign_structure correctly: If I want to countersign a COSE_= Sign1 >> structure with a detached payload (COSE_Sign1.payload =3D nil), is th= e >> following correct? >> >> >> Countersign_structure =3D [ >> context : "CounterSignatureV2", ; Identifier >> body_protected : empty_or_serialized_map, ; Protected headers of >> COSE_Sign1 >> sign_protected : empty_or_serialized_map, ; Protected headers of >> COSE_Countersignature >> external_aad : bstr, ; Empty >> payload : bstr, ; The detached payload >> other_fields : [ bstr ] ; An array with a single element: the >> signature field of COSE_Sign1 >> ] >> >> >> 1. Similarly, if I wanted to countersign a COSE_Signature that is >> part of a COSE_Sign structure with a detached payload (COSE_Sign.payl= oad =3D >> nil), is the following correct? >> >> >> Countersign_structure =3D [ >> context : "CounterSignature", ; Identifier >> body_protected : empty_or_serialized_map, ; Protected headers of >> COSE_Signature >> sign_protected : empty_or_serialized_map, ; Protected headers of >> COSE_Countersignature >> external_aad : bstr, ; Empty >> payload : bstr, ; The signature field of COSE_Signature >> ] >> >> If this is correct, is it intentional that the detached payload IS part >> of the Countersign_structure when countersigning COSE_Sign1, but not whe= n >> countersigning a COSE_Signature that is part of the COSE_Sign signatures >> array? >> >> >> 1. Section 3 =E2=80=9CVersion 2 Countersignatures=E2=80=9D says =E2= =80=9CThis document >> extends the context of a countersignature to allow it to be applied t= o all >> of the security structures defined=E2=80=9D. This sounds like it woul= d be allowed >> to countersign COSE_Sign (even if it doesn=E2=80=99t make much sense,= as is also >> described in section 3). However, section 2 =E2=80=9CCountersignature= Header >> Parameters=E2=80=9D says that the countersignature header can only oc= cur on a >> selected subset of COSE structures, and specifically does not list >> COSE_Sign as a possible structure to countersign. >> >> >> >> 1. There does not currently seem to be a way to correctly countersign >> a COSE_Sign structure with a single countersignature. Let=E2=80=99s t= ake the notary >> analogy: Two people sign a contract, and the notary places their (sin= gle) >> countersignature on the same document, confirming that the two person= s >> signed the contract. The same would not be possible with COSE, I thin= k. >> With COSE, the notary would need to countersign both signatures separ= ately, >> i.e. add a countersignature header to both COSE_Signature entries of = the >> the COSE_Sign.signatures array. Is my understanding correct? >> 2. Has there been progress on registering temporary code points in >> the COSE Header parameters table for counter signatures v2? I found a= n >> email from 2020 about this topic ( >> https://mailarchive.ietf.org/arch/msg/cose/88jwAsA4Rh61oP3XR9KGtasNlw= o/), >> which seems to have been in favor of registering these, but from what= I can >> tell, they haven=E2=80=99t been registered yet. >> >> >> Christian >> >> -- >> >> [image: Google Logo] >> Christian Flach (he/him) >> Software Engineer >> cmfcmf@google.com >> >> Google Germany GmbH >> Erika-Mann-Stra=C3=9Fe 33 >> 80636 M=C3=BCnchen >> >> Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian >> Registergericht und -nummer: Hamburg, HRB 86891 >> Sitz der Gesellschaft: Hamburg >> >> Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise erh= alten >> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, >> l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie mich = bitte wissen, >> dass die E-Mail an die falsche Person gesendet wurde. >> >> >> This e-mail is confidential. If you received this communication by >> mistake, please don't forward it to anyone else, please erase all copies >> and attachments, and please let me know that it has gone to the wrong >> person. >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >> >> >> > > -- > > [image: Google Logo] > Christian Flach (he/him) > Software Engineer > cmfcmf@google.com > > Google Germany GmbH > Erika-Mann-Stra=C3=9Fe 33 > 80636 M=C3=BCnchen > > Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian > Registergericht und -nummer: Hamburg, HRB 86891 > Sitz der Gesellschaft: Hamburg > > Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise erha= lten > haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, > l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie mich b= itte wissen, > dass die E-Mail an die falsche Person gesendet wurde. > > > This e-mail is confidential. If you received this communication by > mistake, please don't forward it to anyone else, please erase all copies > and attachments, and please let me know that it has gone to the wrong > person. > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --000000000000d35f9705dc7a3393 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Russ,
    I agree with you that a countersignature on COSE_Sign1 must = have the signature_value of the underlying message in the ToBeSigned input = for the countersignature; however, my interpretation of the current text fo= r the payload of the Countersign_structure is aligned with Christian's = (for COSE_Sign1). =C2=A0

    COSE's countersignature was generalized= to apply to all COSE structures, so the payload may not always be a signat= ure_value as one might intuitively expect.=C2=A0

    The design discuss= ions for CounterSignatureV2 is in this thread: https://mailarchive= .ietf.org/arch/msg/cose/6-vyoetZboIdrwwEYoYlj9QY_3Q/
    My recollectio= n was that the group decided to proceed with the third option, that is incl= uding every bstr value in the structure.=C2=A0 I believe this is consistent= with step 6 in Section 3.3. =C2=A0

    As Jim discussed in the above th= read, countersignature on COSE_Sign1 was an example where the original meth= od defined in RFC 8152 failed because there was no way to capture the signa= ture_value bstr since it was the third bstr in the COSE message structure. = =C2=A0

    I disagree with the interpretation that I believe you and Chr= istian have for applying a countersignature to the COSE_Sign structure.=C2= =A0 You may find it surprising, but that countersignature will not actually= sign the signature_value of any of the signers.=C2=A0 As written in Sectio= n 3 of the I-D, "When done on a COSE_Sign, this is the same as applyin= g a second signature to the payload and adding a parallel signature as a ne= w COSE_Signature is the preferred method."=C2=A0 I have confirmed that= the message payload is included and not the signature_values nor signature= array by validating the countersignature in the example from C.1.3 of RFC = 8152.=C2=A0 In order to do the traditional countersignature logic of signin= g a signature value, one would apply the countersignature on the specific C= OSE_Signature structure in the signatures array of COSE_Sign. =C2=A0

    Jonatha= n

    On Fri, Mar 25, 2022 at 4:03 PM Russ Housley <housley@vigilsec.com> wrote:
    No, I'm not suggesting a change.=C2=A0 I'm trying to de= scribe the reason one performs a countersignature.

    Russ<= br>

    On Mar 25, 2022, at 10:20 AM, Ch= ristian Flach <cmfcmf=3D40google.com@dmarc.ietf.org> wrote:
    <= br>
    Hi Russ,

    Thanks a lot for your = answers!

    Regarding my second question, you write &= #39;However, a countersignature is a signature over a previous signature, a= nother approach would be to put the signature_value bstr in the payload'= ;. You are suggesting a change to draft-ietf-cose-countersign here, correct= ? Currently, if I read the draft correctly, the COSE_Sign1.signature field = is present in Countersign_structure.other_fields and Countersign_structure.= payload contains the message payload.

    Christian

    On Mon, Mar 14, 2022 at 10:15 PM Russ Housley <housley@vigilsec.com> wrote:
    =
    Christian:
    I have been very slow in responding.=C2=A0 Apologies.=C2=A0= I hope this late response is helpful.

    1.=C2=A0 I = think that RFC 8152, Section 4.3 is the place to look.=C2=A0 I think the de= tached payload is placed in the 'payload' field for signature calcu= lation.

    2.=C2=A0 Countersignatures are signatures = over another previously calculated signature. That said, we probably should= be more clear in the draft-ietf-cose-countersign about what goes in the pa= yload field. Checking with one implementer, that person also used COSE_Sign= 1.payload of nil in when the payload is detached.=C2=A0 However, a counters= ignature is a signature over a previous signature, another approach would b= e to put the signature_value bstr in the payload.=C2=A0 I am thinking that = the second approach make the most sense, and it is parallel to this part of= the specification:

    "When done on a COSE_Mac or COSE_Mac0, the payload is i= ncluded as well as the MAC value".

    3.=C2=A0 T= his seems right to me.=C2=A0 In RFC 5652, I added text to be very clear wha= t a "signature value" means.=C2=A0 It does not include the tag an= d length.=C2=A0 Is there something that we need to in draft-ietf-cose-count= ersign to provide similar clarity?

    4. Section= 3 of draft-ietf-cose-countersign says:

    =C2=A0"When done on
    a COSE_Sign, this is the same as ap= plying a second signature to the
    <= /span>payload and adding a parallel signature as a new COSE_Signature is
    the preferred method.&= quot;

    I think you are pointing out that COSE_Sign = does not appear in the list of COSE structures in Section 2, where it says:=

    &quo= t;The countersignature header
    =C2=A0 =C2=A0 =C2=A0 parameter can occur a= s an unprotected attribute in any of the
    =C2=A0 =C2=A0 =C2=A0 following = structures: COSE_Sign1, COSE_Signature, COSE_Encrypt,
    =C2=A0 =C2=A0 =C2= =A0 COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0."

    I think we should add COSE_Sign in Section 2.

    5.=C2=A0 A countersignture covers one previously calculat= ed signature.=C2=A0 It does not match the semantics in the question.=C2=A0 = One approach would be to define an application that signs another COSE docu= ment that already has multiple signatures.=C2=A0 A second approach would be= to use countersignature for each of the previously calculated signatures.<= /div>

    The alternative would be for a countersignature to= cover the array of signatures.=C2=A0 I have not thought about that, and I = wonder what about the semantics of doing so.

    6.=C2= =A0 I do not know why this document is not an RFC yet.=C2=A0 The approval p= rocess is going very slowly.

    Russ


    On Feb 11, 2022, at 8:58 A= M, Christian Flach <cmfcmf=3D40google.com@dmarc.ietf.org> wrote:
    Hi everyone,

    = We are looking into using COSE for signing = some CBOR data. After reading the latest versions of the drafts, we had a f= ew questions and were wondering whether you could provide us some clarifica= tion:

    1. We have a CO= SE_Sign1 / COSE_Sign structure with a =E2=80=9Cpayload=E2=80=9D field set t= o nil, because we want the payload to not be part of the structure. I=E2=80= =99m a bit confused about how to correctly construct the Sig_structure, spe= cifically the =E2=80=9Cexternal_aad=E2=80=9D and =E2=80=9Cpayload=E2=80=9D = fields. The description of Sig_structure.external_aad says =E2=80=9CThe ext= ernally supplied data from the application encoded in a bstr type=E2=80=9D,= and the description of Sig_structure.payload says =E2=80=9CThe payload to = be signed encoded in a bstr type. The payload is placed here independent of= how it is transported.=E2=80=9D. Both descriptions sound like they would m= atch our detached payload.
      The= Java COSE implementation seems to place the detached payload in `payload` = and an empty byte string in `external_aad`. Is this the correct way to buil= d the Sig_structure for a COSE_Sign1 / COSE_Sign with a detached payload?

    Section 4.3,= which, I think, is about =E2=80=9Cexternal_aad=E2=80=9D, begins with =E2= =80=9COne of the features offered in the COSE document is the ability for a= pplications to provide additional data to be authenticated, but that is not= carried as part of the COSE object.=E2=80=9C. I would appreciate a clearer= distinction between =E2=80=9Cdetached payloads=E2=80=9D and =E2=80=9Cexter= nally supplied data=E2=80=9D, since both appear to achieve similar goals, n= amely the data to not be part of the COSE structure. When would an applicat= ion use one or the other?

    The followin= g questions are all about counter signatures v2.

    1. I=E2=80=99d like to double chec= k whether I understood the construction of the Countersign_structure correc= tly: If I want to countersign a COSE_Sign1 structure with a detached payloa= d (COSE_Sign1.payload =3D nil), is the following correct?
    2. =

    Countersign_structure =3D [
    =C2=A0=C2=A0context : "CounterSignatureV2", ; Identifier
    =C2=A0=C2=A0body_protected : empty_or_serialized_map,= ; Protected headers of COSE= _Sign1
    =C2=A0=C2=A0sign_protected : empty_= or_serialized_map, ; Protect= ed headers of COSE_Countersignature
    =C2=A0= =C2=A0external_aad : bstr, <= span style=3D"white-space:pre-wrap"> ; Empty
    = =C2=A0=C2=A0payload : bstr, = ; The detached payload
    =C2=A0=C2=A0other_fields : [ bstr ] ; An ar= ray with a single element: the signature fie= ld of COSE_Sign1
    ]

    1. Similarly, if I wanted to c= ountersign a COSE_Signature that is part of a COSE_Sign structure with a de= tached payload (COSE_Sign.payload =3D nil), is the following correct?

    Countersign_structure =3D [
    =C2=A0=C2=A0context : "CounterSignature&qu= ot;, ; Ide= ntifier
    =C2=A0=C2=A0body_protected : empty= _or_serialized_map, ; Protec= ted headers of COSE_Signature
    =C2=A0=C2=A0= sign_protected : empty_or_serialized_map, ; Protected headers of COSE_Countersignature
    =C2=A0=C2=A0external_aad : bstr, <= span style=3D"font-size:10pt;font-family:Arial;background-color:transparent= ;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:= baseline;white-space:pre-wrap">
    ; Empty
    =C2=A0=C2=A0payload : bstr, = ; The si= gnature field of COSE_Signature
    ]
    If this is correct, is it int= entional that the detached payload IS part of the Countersign_structure whe= n countersigning COSE_Sign1, but not when countersigning a COSE_Signature t= hat is part of the COSE_Sign signatures array?

    1. Section 3 =E2=80=9CVersion 2 Count= ersignatures=E2=80=9D says =E2=80=9CThis document extends the context of a = countersignature to allow it to be applied to all of the security structure= s defined=E2=80=9D. This sounds like it would be allowed to countersign COS= E_Sign (even if it doesn=E2=80=99t make much sense, as is also described in= section 3). However, section 2 =E2=80=9CCountersignature Header Parameters= =E2=80=9D says that the countersignature header can only occur on a selecte= d subset of COSE structures, and specifically does not list COSE_Sign as a = possible structure to countersign.

    1. There does not currently seem to be = a way to correctly countersign a COSE_Sign structure with a single counters= ignature. Let=E2=80=99s take the notary analogy: Two people sign a contract= , and the notary places their (single) countersignature on the same documen= t, confirming that the two persons signed the contract. The same would not = be possible with COSE, I think. With COSE, the notary would need to counter= sign both signatures separately, i.e. add a countersignature header to both= COSE_Signature entries of the the COSE_Sign.signatures array. Is my unders= tanding correct?
    2. Has there been progress on registering temporary code points in= the COSE Header parameters table for counter signatures v2? I found an ema= il from 2020 about this topic (https:= //mailarchive.ietf.org/arch/msg/cose/88jwAsA4Rh61oP3XR9KGtasNlwo/), which seems to have been in favor of registering these, b= ut from what I can tell, they haven=E2=80=99t been registered yet.


    = --

    3D"Google<= tr style=3D"margin:0px;padding:0px">
    Christian Flach (he/him)
    Software Engineer
    cmfcmf@google.com

    <= /div>
    Goo= gle Germany GmbH
    Erika-Mann-Stra=C3=9Fe 33
    80636 M=C3=BCnchen

    <= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">Gesch=C3=A4ftsf= =C3=BChrer: Paul Manicle, Liana Sebastian
    Registergericht und -nummer: Hamburg= , HRB 86891
    Sitz der Gesellschaft: Hamburg

    Diese E-Mail ist vertraulich. Fall= s Sie diese f=C3=A4lschlicherweise erhalten haben sollten, leiten Sie diese= bitte nicht an jemand anderes weiter, l=C3=B6schen Sie alle Kopien und Anh= =C3=A4nge davon und lassen Sie mich bitte wissen, dass die E-Mail an die fa= lsche Person gesendet wurde.=C2=A0

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

    This e-= mail is confidential. If you received this communication by mistake, please= don't forward it to anyone else, please erase all copies and attachmen= ts, and please let me know that it has gone to the wrong person.
    _______________________________________________
    COSE mailing list
    COSE@ietf.org
    https://= www.ietf.org/mailman/listinfo/cose



    --

    3D"Google
    Christian Fla= ch (he/him)
    Software Engi= neer
    cmfcmf@google.com

    Google Germany = GmbH
    Erika-Mann-Stra=C3=9Fe 33
    80636 M=C3=BCnchen

    Gesch=C3=A4ftsf=C3=BChrer: P= aul Manicle, Liana Sebastian
    Registergericht und -nummer: Hamburg, HRB 86891
    Sitz= der Gesellschaft: Hamburg

    Diese E-Mail ist vertraulich. Falls Sie diese f= =C3=A4lschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht = an jemand anderes weiter, l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge dav= on und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person = gesendet wurde.=C2=A0

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

    This e-mail is confi= dential. If you received this communication by mistake, please don't fo= rward it to anyone else, please erase all copies and attachments, and pleas= e let me know that it has gone to the wrong person.
    _______________________________________________
    COSE mailing list
    COSE@ietf.org
    https://= www.ietf.org/mailman/listinfo/cose

    _______________________________________________
    COSE mailing list
    COSE@ietf.org
    https://www.ietf.org/mailman/listinfo/cose
    --000000000000d35f9705dc7a3393-- From nobody Wed Apr 13 07:26:55 2022 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 7A63E3A2111 for ; Wed, 13 Apr 2022 07:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azqicG8JbF4c for ; Wed, 13 Apr 2022 07:26:50 -0700 (PDT) Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D2A3A210E for ; Wed, 13 Apr 2022 07:26:50 -0700 (PDT) Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 40F58162CFA; Wed, 13 Apr 2022 10:26:48 -0400 (EDT) Received: from [10.0.1.3] (pfs.iad.rg.net [198.180.150.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 12FE0162CF8; Wed, 13 Apr 2022 10:26:48 -0400 (EDT) From: Russ Housley Message-Id: <1AA56B88-4CF8-4C49-9B6B-B7FBAD0506EE@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_72793B45-1D38-45F8-930A-E4BFE2AE793F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Wed, 13 Apr 2022 10:26:47 -0400 In-Reply-To: Cc: Oleksandr Peletskyi , Sonja Laurila , Christian Flach , cose@ietf.org To: Jonathan Hammell References: <5E870305-9ED3-4FD8-BF7D-257CB92403A4@vigilsec.com> <53B4F33C-B908-45E4-9B4B-50939B4494C9@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [COSE] Questions about signatures and countersignatures X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 14:26:53 -0000 --Apple-Mail=_72793B45-1D38-45F8-930A-E4BFE2AE793F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jonathan: > I agree with you that a countersignature on COSE_Sign1 must have the = signature_value of the underlying message in the ToBeSigned input for = the countersignature; however, my interpretation of the current text for = the payload of the Countersign_structure is aligned with Christian's = (for COSE_Sign1). =20 >=20 > COSE's countersignature was generalized to apply to all COSE = structures, so the payload may not always be a signature_value as one = might intuitively expect. =20 >=20 > The design discussions for CounterSignatureV2 is in this thread: = https://mailarchive.ietf.org/arch/msg/cose/6-vyoetZboIdrwwEYoYlj9QY_3Q/ = =20= > My recollection was that the group decided to proceed with the third = option, that is including every bstr value in the structure. I believe = this is consistent with step 6 in Section 3.3. =20 That is consistent with my memory too. > As Jim discussed in the above thread, countersignature on COSE_Sign1 = was an example where the original method defined in RFC 8152 failed = because there was no way to capture the signature_value bstr since it = was the third bstr in the COSE message structure. Yes, Jim was seeking a general solution. > I disagree with the interpretation that I believe you and Christian = have for applying a countersignature to the COSE_Sign structure. You = may find it surprising, but that countersignature will not actually sign = the signature_value of any of the signers. As written in Section 3 of = the I-D, "When done on a COSE_Sign, this is the same as applying a = second signature to the payload and adding a parallel signature as a new = COSE_Signature is the preferred method." I have confirmed that the = message payload is included and not the signature_values nor signature = array by validating the countersignature in the example from C.1.3 of = RFC 8152. In order to do the traditional countersignature logic of = signing a signature value, one would apply the countersignature on the = specific COSE_Signature structure in the signatures array of COSE_Sign. Do you think anything needs to change in the document? Russ --Apple-Mail=_72793B45-1D38-45F8-930A-E4BFE2AE793F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Jonathan:

    I agree with you that a countersignature on COSE_Sign1 must = have the signature_value of the underlying message in the ToBeSigned = input for the countersignature; however, my interpretation of the = current text for the payload of the Countersign_structure is aligned = with Christian's (for COSE_Sign1).  

    COSE's countersignature = was generalized to apply to all COSE structures, so the payload may not = always be a signature_value as one might intuitively expect. 

    The design discussions for CounterSignatureV2 = is in this thread: https://mailarchive.ietf.org/arch/msg/cose/6-vyoetZboIdrwwEYoYl= j9QY_3Q/
    My recollection was that the group decided = to proceed with the third option, that is including every bstr value in = the structure.  I believe this is consistent with step 6 in Section = 3.3.  

    That is consistent with my memory too.

    As Jim discussed in the above thread, = countersignature on COSE_Sign1 was an example where the original method = defined in RFC 8152 failed because there was no way to capture the = signature_value bstr since it was the third bstr in the COSE message = structure.

    Yes, Jim was seeking a general solution.

    I disagree with the interpretation that = I believe you and Christian have for applying a countersignature to the = COSE_Sign structure.  You may find it surprising, but that = countersignature will not actually sign the signature_value of any of = the signers.  As written in Section 3 of the I-D, "When done on a = COSE_Sign, this is the same as applying a second signature to the = payload and adding a parallel signature as a new COSE_Signature is the = preferred method."  I have confirmed that the message payload is = included and not the signature_values nor signature array by validating = the countersignature in the example from C.1.3 of RFC 8152.  In = order to do the traditional countersignature logic of signing a = signature value, one would apply the countersignature on the specific = COSE_Signature structure in the signatures array of COSE_Sign. =

    Do you think = anything needs to change in the document?

    Russ

    = --Apple-Mail=_72793B45-1D38-45F8-930A-E4BFE2AE793F-- From nobody Sat Apr 16 07:35:37 2022 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 DA0933A0C0B for ; Sat, 16 Apr 2022 07:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixNpoM-8ClwQ for ; Sat, 16 Apr 2022 07:35:30 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A5E3A0C02 for ; Sat, 16 Apr 2022 07:35:30 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id r1so9142232vsi.12 for ; Sat, 16 Apr 2022 07:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z6+k7Xjvbk1myTlHsFqQ96TyrhUKFyLSih1DgHtQdE0=; b=VJHYwTHqaskkMH6LlKLEH1TVkLfY6n/r8Hp4eQrMZncnCBKqQOx4Ef9llyktyfQpZ+ dI4RmF5H4ifwjpMLjbB4K/3GhfV7caHPMC6mw3RjmsOV5UpxB5llxvzicrdfEJuV1Mai iMg2m0TExbJAoXyra7xZbkzpZNNh/DaLO874sUr+SU02COoKzTn3AMu1jqYS3jHNc02u a++LjP5Fg3GKwS23QtWM4puGlxrAKKC70RZvCV98iQ8GnP/bi50dfoJ5rcVKxH+hmZ/r jHy4DYndapTcfG2rZdXuEJfgP/7gsh7ge6/7wiHPG0JFy0Ark9t607IUqXUFrc8rZ3TK BYww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z6+k7Xjvbk1myTlHsFqQ96TyrhUKFyLSih1DgHtQdE0=; b=Xiw37+KgS18SRAjdBNowi2dIEyjXW/T9ztBTnaC0cpKrZbX8IPnqq6CiuhvZng2+8c 4QP79K0WBLY7xsppoyNMde6Xrt+stEco2GcwOuHAtR3CPFwZlm02QbyqVnYH8VdFjcu9 Tg0p7dV+DfwXwFtgVoOc0FpnwotErxcygFSku1lMR5cdlGVBNbo/UXCq0owEGplx7Rau r7oDbbm/ECerw1PRvbZLg//S2re06nc3RIagbkCQtIfmGu9wOgPg6pmInFiWr/okMR11 lnL0N3dbLVlcfPnD3Os9w7bO1r6ei0m4S1s4i2BWQdQLvQS/Qw1mAdQetkCsp1JxsxGN vTew== X-Gm-Message-State: AOAM532yuuks3fnNtWB9OJLaBIjVzTu4oQG2Ve+nhfXT/KchHnqfyo4G K1zL4AIxob1wGH1x6ko8D1ly5HBxJdaLzXnFrcc= X-Google-Smtp-Source: ABdhPJxrEpsLLwJLCPZl4uabRmAeADTl4q81Q5307X8pCMN/KV955y4k4IrxEWS2SAXnrU64rfOub+ejzMf0x6G4Ues= X-Received: by 2002:a67:1987:0:b0:328:21fb:f2c0 with SMTP id 129-20020a671987000000b0032821fbf2c0mr945317vsz.17.1650119727872; Sat, 16 Apr 2022 07:35:27 -0700 (PDT) MIME-Version: 1.0 References: <5E870305-9ED3-4FD8-BF7D-257CB92403A4@vigilsec.com> <53B4F33C-B908-45E4-9B4B-50939B4494C9@vigilsec.com> <1AA56B88-4CF8-4C49-9B6B-B7FBAD0506EE@vigilsec.com> In-Reply-To: <1AA56B88-4CF8-4C49-9B6B-B7FBAD0506EE@vigilsec.com> From: Jonathan Hammell Date: Sat, 16 Apr 2022 10:35:16 -0400 Message-ID: To: Russ Housley Cc: Oleksandr Peletskyi , Sonja Laurila , Christian Flach , cose@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [COSE] Questions about signatures and countersignatures X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2022 14:35:35 -0000 Hi Russ, On Wed, Apr 13, 2022 at 10:26 AM Russ Housley wrote: > Do you think anything needs to change in the document? After re-reading the description in Section 3, I think the semantics are clear for an implementer. The warning needs to be heeded that one must consider the security properties when applying it. If one is using a software library for COSE, I suppose that the resulting security properties may not be obvious to the user, particularly in the case of COSE_Sign. That said, any text we add in the RFC is likely not to be read by a software library user, so it is the responsibility of the library to provide a proper API to prevent misuse. The case of detached signatures might be a little unclear, as Christian originally raised. Section 4.1 of RFC 8152 says that "If the payload is transported separately ("detached content"), then a nil CBOR object is placed in [the payload]..." A nil value is a different CBOR type than an empty bstr (Section 1.3 of RFC 8152). However, Step 5 of Section 3.3 says that "the payload is placed [in the payload of Countersign_structure] independent of how it is transported." I believe this implies that the detached payload is indeed included here for the purpose of countersigning, similar to externally supplied data. But would an implementer then misinterpret Step 6 given that the payload of the original structure was nil and not a bstr, and thus not include the signature bstr in the other_fields? The examples in the I-D certainly need to be updated. The first example was taken from RFC 8152. It is odd given that it is a countersignature on a COSE_Sign, which is discouraged in Section 3 for the reasons discussed before, and it uses the same key to countersign as was used in the original signature. That is, it has two ECDSA signatures with the same key. The early allocations that I requested for the countersignature header parameters were never actioned, but the values chosen still seem to be unassigned by IANA. However, I will need to update the examples that I generated for Appendix A since in a recent review of my code I believe I found a bug. It would be nice to do an interoperability test with another implementer, so please let me know if anyone wishes to test with me. Best regards, Jonathan