From yuriy@fidoalliance.org Tue Feb 13 05:27:12 2018 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 26BF4127601 for ; Tue, 13 Feb 2018 05:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fidoalliance.org 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 J-I2bW5VbqS9 for ; Tue, 13 Feb 2018 05:27:10 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 6A8BA12E89F for ; Tue, 13 Feb 2018 05:27:10 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id v139so12266310ywg.4 for ; Tue, 13 Feb 2018 05:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fidoalliance.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=bPURXRyfrjB3Ljoy1O4w5UEvSLzVwnfumULam5s2KDc=; b=gj8R7Wt7V8ojapME3TOKQExjdlEntDa96y4+C680LYy4BbYz9ASwSRcyofhTmuxOV3 sqL+H40veo39cgBzJOxuifFBQm3u/nIOzAyShvCnkh41VfyDOv1A0UCHUQOFXV9g6TSI Nh3gmOnEwUgD64/FBMbPrf8LRUftRHsNcqPs4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bPURXRyfrjB3Ljoy1O4w5UEvSLzVwnfumULam5s2KDc=; b=V6JWiUbyA9/5K4mjkN9HnnHmfPBulrMRKrxPQHWxFSKQa3kywfjjKLRNVBY84w815y /sgZ6DFrx5LUfgvCRGWlTUc3o49yZTd1wLvihbRoA3vvk98ID3iYAVT31dy6Vld+1p/F VHPExb1E7zGvEWRW4a0X2PSzl6iIbpwm7V+8708+ei2c7HbN0Sz0G6q3bNtAFVF3zof7 njJ3zZiY8kffTjFDTuPeQBYvXMGYNr0QElIlqZixblagvUn76U4bNqd5vM3zJU3fx8Fp UJzl+v4yniVjkGhhYjqy12r3TUUrTmTuQHi+xDQFsNX92Fg9/fuTrvzwxDJLqQYzCH3L cR6A== X-Gm-Message-State: APf1xPC7d2MeZMUsps26fpIA3ez1Fd/2O4E9gkheNY+8GhUxCCKoQ26L 3ezeWzBiRID2DnHJ3cqCUNCPLGNdX7uMfzZ22PTWn6Nmja4= X-Google-Smtp-Source: AH8x227HHSXGfeeAMnUmwthOxpTiHZzw7zPRWAeMfjRNQ027fVkh96UH8jHNcIcL+nJDmEzQbANYQ/ZmPTGZ0oWDOzU= X-Received: by 10.37.163.196 with SMTP id e62mr691150ybi.13.1518528429324; Tue, 13 Feb 2018 05:27:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.2.129 with HTTP; Tue, 13 Feb 2018 05:27:08 -0800 (PST) From: Yuriy Ackermann Date: Tue, 13 Feb 2018 13:27:08 +0000 Message-ID: To: cose@ietf.org Content-Type: multipart/alternative; boundary="f403045ca3629c96af056517f33d" Archived-At: X-Mailman-Approved-At: Tue, 13 Feb 2018 06:49:00 -0800 Subject: [COSE] Adding secp256k1 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 14:05:17 -0000 --f403045ca3629c96af056517f33d Content-Type: text/plain; charset="UTF-8" Hey guys. I work for FIDO Alliance. We are currently selecting a list of curves we going to support. We want to support secp256k1 in COSE, as we are already supporting it in UAF, and we have companies who really want it. I know that in security considerations you've said that there is possibility of collision of the signatures from k1 and p1, but the chances of such thing happening are enough low for it to be ignored. We are proposing adding secp256k1 into list of curves, in section 13.1 with value 8 Regards. Yuriy [image: FIDO Alliance] * Yuriy Ackermann * Senior Certification Engineer *email:* yuriy@fidoalliance.org *skype:* ackermann.yuriy *website:* https://fidoalliance.org --f403045ca3629c96af056517f33d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey guys. I work for FIDO Alliance. We are currently selec= ting a list of curves we going to support. We want to support secp256k1 in = COSE, as we are already supporting it in UAF, and we have companies who rea= lly want it.=C2=A0

I know that in security consideration= s you've said that there is possibility of collision of the signatures = from k1 and p1, but the chances of such thing happening are enough low for = it to be ignored.

We are proposing adding=C2=A0secp256k1 into list of curves, in section 13.1 with = value 8=C2=A0

Regards. Yuriy
<= div dir=3D"ltr">

3D"FIDO Yuriy Ackermann
Senior Certification Engineer
email:=C2=A0yuriy@fidoalliance.org
skype:=C2=A0ackermann.yuriy<= /a>
website:=C2=A0https://fidoalliance.org

--f403045ca3629c96af056517f33d-- From nobody Tue Feb 13 09:37:12 2018 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 A8C7212D84D for ; Tue, 13 Feb 2018 09:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 J7gSaRkaZim6 for ; Tue, 13 Feb 2018 09:37:09 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D877128896 for ; Tue, 13 Feb 2018 09:37:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1518543429; x=1550079429; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cnPAPfhVOJDNUQ/uYRRHHTfyqyPBBz1eAjrnNfkg+g8=; b=xZ2U4sJnYF/GxmGi/2B69QX5eZjSUk7FZ+CshMsjvKK/NLbmXeh+UHwr a/EbF5rPXp9yEKr3KVXqHt3EC5iNXUCAuzdgd1mEnPx4e8YfCyHnRNS+t 08llS8i787NoAWXCNUDJ8Sp5MxGtSoCREt9FZpKCqo+Erz0hbEBWtl4cj E=; X-IronPort-AV: E=Sophos;i="5.46,508,1511856000"; d="scan'208,217";a="123970091" Received: from unknown (HELO ironmsg05-sd.qualcomm.com) ([10.53.140.145]) by sabertooth01.qualcomm.com with ESMTP; 13 Feb 2018 09:37:08 -0800 X-IronPort-AV: E=McAfee;i="5900,7806,8804"; a="10316398" X-MGA-submission: =?us-ascii?q?MDHW2wF+RgX8GnA67vn/pzurC7bblj3idbC9Ua?= =?us-ascii?q?KMsOA8ArzdnGIMyozzE9cKDorNgdDpspHr/7SqeN5sysjA+jMYY1Osbc?= =?us-ascii?q?ZXcZlthtqwPOeysTv9GAdR6zxVutrJH/1M1Wm1txDG37cngFKCCtofUe?= =?us-ascii?q?2M?= Received: from nasanexm01b.na.qualcomm.com ([10.85.0.82]) by ironmsg05-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 13 Feb 2018 09:37:08 -0800 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01B.na.qualcomm.com (10.85.0.82) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 13 Feb 2018 09:36:23 -0800 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1293.002; Tue, 13 Feb 2018 09:36:23 -0800 From: Laurence Lundblade To: Yuriy Ackermann CC: "cose@ietf.org" Thread-Topic: [COSE] Adding secp256k1 Thread-Index: AQHTpNnLpFd1KgdRlEOtGpBs35o9iKOjHr+A Date: Tue, 13 Feb 2018 17:36:23 +0000 Message-ID: <90CF094D-6218-46C3-9D30-382D97F73388@qti.qualcomm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.80.80.8] Content-Type: multipart/alternative; boundary="_000_90CF094D621846C39D30382D97F73388qtiqualcommcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [COSE] Adding secp256k1 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 17:37:12 -0000 --_000_90CF094D621846C39D30382D97F73388qtiqualcommcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yuri, The COSE specification probably should not change to accommodate this. The = IANA COSE algorithm registry should be used instead. There are several options: - Write a standards track IETF document and get it set in the IANA COSE re= gistry. - Write a specification (presumably public) and get it set IANA COSE regis= try. - Use an identifier in the private range and publish it only in FIDO docs. LL On Feb 13, 2018, at 5:27 AM, Yuriy Ackermann > wrote: Hey guys. I work for FIDO Alliance. We are currently selecting a list of cu= rves we going to support. We want to support secp256k1 in COSE, as we are a= lready supporting it in UAF, and we have companies who really want it. I know that in security considerations you've said that there is possibilit= y of collision of the signatures from k1 and p1, but the chances of such th= ing happening are enough low for it to be ignored. We are proposing adding secp256k1 into list of curves, in section 13.1 with= value 8 Regards. Yuriy [FIDO Alliance] Yuriy Ackermann Senior Certification Engineer email: yuriy@fidoalliance.org skype: ackermann.yuriy website: https://fidoalliance.org _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose --_000_90CF094D621846C39D30382D97F73388qtiqualcommcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9C4491901BBFF24AB494D790DE3BE3CB@qualcomm.com> Content-Transfer-Encoding: quoted-printable Hi Yuri,

The COSE specification probably should not change to accomm= odate this. The IANA COSE algorithm registry should be used instead.

There are several options:
- Write a standards track IETF document and get it set in t= he  IANA COSE registry.
- Write a specification (presumably public) and get it set&= nbsp; IANA COSE registry.
- Use an identifier in the private range and publish it onl= y in FIDO docs.

LL



On Feb 13, 2018, at 5:27 AM, Yuriy Ackermann <yuriy@fidoalliance.org> w= rote:

Hey guys. I work for FIDO Alliance. We are curr= ently selecting a list of curves we going to support. We want to support se= cp256k1 in COSE, as we are already supporting it in UAF, and we have compan= ies who really want it. 

I know that in security considerations you've said that the= re is possibility of collision of the signatures from k1 and p1, but the ch= ances of such thing happening are enough low for it to be ignored.

We are proposing adding secp256k1 into list of curves, in section 13.1 with value 8 

Regards. Yuriy

3D"FIDO Yuriy Ackermann
Senior Certification Engineer
email: yuriy@fidoalliance.org skype: ackermann.yuriy
website: https://fidoalliance.org

_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

--_000_90CF094D621846C39D30382D97F73388qtiqualcommcom_-- From nobody Tue Feb 13 09:57:57 2018 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 489551241FC for ; Tue, 13 Feb 2018 09:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fidoalliance.org 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 N6dUB3KYK-TR for ; Tue, 13 Feb 2018 09:57:53 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 E567B124205 for ; Tue, 13 Feb 2018 09:57:52 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id d77so780043ywb.2 for ; Tue, 13 Feb 2018 09:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fidoalliance.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oypjsP+iOZ6jUBgol/qIo36ZFyiVRXsmI1/3/XYZrpM=; b=L8c7zNsUZlq9YaURG+96N++SPgz38nTQXSvMHK6PM9uHB1o0caJvWsqH30B8VSqvza Uej0DFpAFpbC6BFLbPSrVPUEeSaPUxHM1cVTEiVobDSfeMeMppibkzFC/Y4q85ETd/0r VvissQd+bhOIdgLrBIUKiYIrPscN1x0Z8PBWM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oypjsP+iOZ6jUBgol/qIo36ZFyiVRXsmI1/3/XYZrpM=; b=MAbNeEJ5CTMA/IGJ+wh19siPkUe3AkyT3vVdBrFcTAK4J9lxZRUUuZ+VyF/sYbE+G0 DrNgaDidQX9sDhy1x+mlqC0H0XrCvCxjHeC8x9kIiKMGkJ9REnuhnvjSmLAi8yMw0Ru2 lRn/dblVMrTi4Mn+9Rr063bD8U03RFMQPJihsGKDWQHdvpLGzaenEJtvmPsCbJu7wNqH GFGAkAUO2q6Ig4AgtFth2mg7F3cPuS+se6IUTNxxfjmYFQ0L8xcerf6MYB2Cq1PkoAG3 jy+n7GvnXTpJOaeJF3pYKEKUlWQl3xSDprebgH8t0egOdvg34T0kda72I9bGgoAAaM3t 6LsQ== X-Gm-Message-State: APf1xPCPWTZxhejBObWm21HUn8lxlwFecnpMW09+/5N+1La+CMt+ULtU xQa+OU8K3cthBqDLQOcRwPk0kOkLVhhkV+TIb4QmSgHk4EM= X-Google-Smtp-Source: AH8x225QuOPgcl6XdtPk0qgZd+7llQ9lfdtT8g0yJRGiHEqu11AVqNzJ16qQMrK9Y0xQW3pjU2PqeDdK3lD34JM9MCo= X-Received: by 10.37.4.204 with SMTP id 195mr1348308ybe.345.1518544672135; Tue, 13 Feb 2018 09:57:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.2.129 with HTTP; Tue, 13 Feb 2018 09:57:51 -0800 (PST) In-Reply-To: <90CF094D-6218-46C3-9D30-382D97F73388@qti.qualcomm.com> References: <90CF094D-6218-46C3-9D30-382D97F73388@qti.qualcomm.com> From: Yuriy Ackermann Date: Tue, 13 Feb 2018 17:57:51 +0000 Message-ID: To: Laurence Lundblade Cc: "cose@ietf.org" Content-Type: multipart/alternative; boundary="001a11c01966c2334f05651bbbc5" Archived-At: Subject: Re: [COSE] Adding secp256k1 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 17:57:55 -0000 --001a11c01966c2334f05651bbbc5 Content-Type: text/plain; charset="UTF-8" Blimey. I've totally missed it. I will email AINA then. Thank you. Regards. Yuriy [image: FIDO Alliance] * Yuriy Ackermann * Senior Certification Engineer *email:* yuriy@fidoalliance.org *skype:* ackermann.yuriy *website:* https://fidoalliance.org On Tue, Feb 13, 2018 at 5:36 PM, Laurence Lundblade < llundbla@qti.qualcomm.com> wrote: > Hi Yuri, > > The COSE specification probably should not change to accommodate this. The > IANA COSE algorithm registry should be used instead. > > There are several options: > - Write a standards track IETF document and get it set in the IANA COSE > registry . > - Write a specification (presumably public) and get it set IANA COSE > registry . > - Use an identifier in the private range and publish it only in FIDO docs. > > LL > > > > On Feb 13, 2018, at 5:27 AM, Yuriy Ackermann > wrote: > > Hey guys. I work for FIDO Alliance. We are currently selecting a list of > curves we going to support. We want to support secp256k1 in COSE, as we are > already supporting it in UAF, and we have companies who really want it. > > I know that in security considerations you've said that there is > possibility of collision of the signatures from k1 and p1, but the chances > of such thing happening are enough low for it to be ignored. > > We are proposing adding secp256k1 into list of curves, in section 13.1 > with value 8 > > Regards. Yuriy > > [image: FIDO Alliance] *Yuriy Ackermann * > Senior Certification Engineer > *email:* yuriy@fidoalliance.org > *skype:* ackermann.yuriy > *website:* https://fidoalliance.org > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > > --001a11c01966c2334f05651bbbc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Blimey. I've totally missed it. I will email AINA then= .

Thank you.

Regards.
=
Yuriy

3D"FIDO Yuriy Ackermann
Senior Certification Engineer
email:=C2=A0yuriy@fidoalliance.org
skype:=C2=A0ackermann.yuriy<= /a>
website:=C2=A0https://fidoalliance.org


On Tue, Feb 13, 2018 at 5:36 PM, Laurence Lu= ndblade <llundbla@qti.qualcomm.com> wrote:
Hi Yuri,

The COSE specification probably should not change to accommodate this.= The IANA COSE algorithm registry should be used instead.

There are several options:
- Write a standards track IETF document and get it set in the=C2=A0=C2=A0IANA COSE registry.
- Write a specification (presumably public) and get it set=C2=A0= =C2=A0IANA COSE registry.
- Use an identifier in the private range and publish it only in FIDO d= ocs.

LL



On Feb 13, 2018, at 5:27 AM, Yuriy Ackermann <yuriy@fidoalliance.org> wrote= :

Hey guys. I work for FIDO Alliance. We are currently selec= ting a list of curves we going to support. We want to support secp256k1 in = COSE, as we are already supporting it in UAF, and we have companies who rea= lly want it.=C2=A0

I know that in security considerations you've said that there is p= ossibility of collision of the signatures from k1 and p1, but the chances o= f such thing happening are enough low for it to be ignored.

We are proposing adding=C2=A0secp256k1 into list of curves, in section 13.1 with value 8=C2=A0

Regards. Yuriy

3D"FIDO Yuriy Ackermann
Senior Certification Engineer
email:=C2=A0yuriy@fidoalliance.org
skype:=C2=A0ackermann.yuriy<= br> website:=C2=A0https://fidoalliance.org

_______________________________________________
COSE mailing list
COSE@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cose


--001a11c01966c2334f05651bbbc5-- From nobody Tue Feb 13 11:03:11 2018 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 103F312EAB0 for ; Tue, 13 Feb 2018 11:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 hNMeEzFPWxGS for ; Tue, 13 Feb 2018 11:03:02 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 3746412EA9F for ; Tue, 13 Feb 2018 11:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1DJ2vgp004728; Tue, 13 Feb 2018 20:02:57 +0100 (CET) Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zgsPF4R7PzDWqm; Tue, 13 Feb 2018 20:02:57 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Tue, 13 Feb 2018 20:02:55 +0100 Cc: cose@ietf.org X-Mao-Original-Outgoing-Id: 540241373.989869-7b1f65afabab66a41e8b9b69601a7823 Content-Transfer-Encoding: quoted-printable Message-Id: <145B3CD3-5A9F-4A66-8CE5-9D0FFE08AC62@tzi.org> References: To: Yuriy Ackermann X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [COSE] Adding secp256k1 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 19:03:07 -0000 On Feb 13, 2018, at 14:27, Yuriy Ackermann = wrote: >=20 > We are proposing adding secp256k1 into list of curves, in section 13.1 = with value 8=20 Hi Yurij, please have a look at Section 16.8 of RFC 8152. This details the procedure for adding new curves. In particular, it defines the different registration policies that apply = to different number ranges that could be used here. Some of the number ranges are =E2=80=9CStandards Action=E2=80=9D, = because they are encoded slightly more efficiently but are not very = large, so there should be some consensus for using up numbers in those = ranges. Others are =E2=80=9CSpecification Required=E2=80=9D or even = just =E2=80=9CExpert Review=E2=80=9D. Analogously, Section 16.4 of RFC 8152 is used for new algorithms. Again, it defines the different policies that apply to different number = ranges that could be used here. One example of exercising this in a Standards Action was RFC 8230, which = adds algorithm and key type values to COSE to support some older = RSA-based signature and key encryption algorithms that weren=E2=80=99t = listed in RFC 8152. While I can=E2=80=99t comment on the merits or demerits of secp256k1 (or = even whether key type EC2 would be the right one here), if you want to = get the number 8 here for the curve, writing up a short Internet-Draft = and getting consensus to move forward with it as a standards-track RFC = like RFC 8230 would be the correct procedure. Or maybe it=E2=80=99s not = that important to save that one byte, and you can go for Specification = Required, possibly pointing to one of the existing FIDO documents as the = specification (or making up a new one, possibly even an independent = track RFC). Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Feb 13 14:51:39 2018 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 DC51612D95F for ; Tue, 13 Feb 2018 14:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_RP_MATCHES_RCVD=-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 SofOT-hb6PTH for ; Tue, 13 Feb 2018 14:51:35 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A434212D956 for ; Tue, 13 Feb 2018 14:51:35 -0800 (PST) Received: from Jude (100.44.187.196) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 13 Feb 2018 14:49:51 -0800 From: Jim Schaad To: 'Yuriy Ackermann' CC: , 'Laurence Lundblade' References: <90CF094D-6218-46C3-9D30-382D97F73388@qti.qualcomm.com> In-Reply-To: <90CF094D-6218-46C3-9D30-382D97F73388@qti.qualcomm.com> Date: Tue, 13 Feb 2018 14:51:28 -0800 Message-ID: <020901d3a51d$30bfb0e0$923f12a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020A_01D3A4DA.229D0D20" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEbJAVHRnZDoFdlOKnganiOYv+LDQGY98/CpQcqP/A= Content-Language: en-us X-Originating-IP: [100.44.187.196] Archived-At: Subject: Re: [COSE] Adding secp256k1 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 22:51:38 -0000 ------=_NextPart_000_020A_01D3A4DA.229D0D20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would not do the private range version below if you are going to publish in FIDO docs. This is really meant for completely closed and experimental and not for any public standards use. From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Laurence Lundblade Sent: Tuesday, February 13, 2018 9:36 AM To: Yuriy Ackermann Cc: cose@ietf.org Subject: Re: [COSE] Adding secp256k1 Hi Yuri, The COSE specification probably should not change to accommodate this. The IANA COSE algorithm registry should be used instead. There are several options: - Write a standards track IETF document and get it set in the IANA COSE registry. - Write a specification (presumably public) and get it set IANA COSE registry. - Use an identifier in the private range and publish it only in FIDO docs. LL On Feb 13, 2018, at 5:27 AM, Yuriy Ackermann > wrote: Hey guys. I work for FIDO Alliance. We are currently selecting a list of curves we going to support. We want to support secp256k1 in COSE, as we are already supporting it in UAF, and we have companies who really want it. I know that in security considerations you've said that there is possibility of collision of the signatures from k1 and p1, but the chances of such thing happening are enough low for it to be ignored. We are proposing adding secp256k1 into list of curves, in section 13.1 with value 8 Regards. Yuriy Yuriy Ackermann Senior Certification Engineer email: yuriy@fidoalliance.org skype: ackermann.yuriy website: https://fidoalliance.org _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose ------=_NextPart_000_020A_01D3A4DA.229D0D20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would = not do the private range version below if you are going to publish in = FIDO docs.  This is really meant for completely closed and = experimental and not for any public standards use.

 

 

 

From: COSE = [mailto:cose-bounces@ietf.org] On Behalf Of Laurence = Lundblade
Sent: Tuesday, February 13, 2018 9:36 = AM
To: Yuriy Ackermann = <yuriy@fidoalliance.org>
Cc: = cose@ietf.org
Subject: Re: [COSE] Adding = secp256k1

 

Hi Yuri, =

 

The COSE specification probably should not change to = accommodate this. The IANA COSE algorithm registry should be used = instead.

 

There are several options:

- Write a standards track IETF document and get it set = in the  IANA = COSE registry.

- Write = a specification (presumably public) and get it set  IANA = COSE registry.

- Use = an identifier in the private range and publish it only in FIDO = docs.

 

LL

 

 

 

On Feb 13, 2018, at 5:27 AM, Yuriy Ackermann <yuriy@fidoalliance.org> = wrote:

 

Hey guys. I work for FIDO Alliance. We are currently = selecting a list of curves we going to support. We want to support = secp256k1 in COSE, as we are already supporting it in UAF, and we have = companies who really want it. 

 

I = know that in security considerations you've said that there is = possibility of collision of the signatures from k1 and p1, but the = chances of such thing happening are enough low for it to be = ignored.

 

We are proposing adding secp256k1 into list of curves, in section 13.1 with = value 8 

 

Regards. Yuriy

<= div>

3D"FIDOYuriy Ackermann
Senior Certification = Engineer
email: yuriy@fidoalliance.org
skype: ac= kermann.yuriy
website: = https://fidoalliance.org

=
<= p = class=3DMsoNormal>_______________________________________________
COSE= mailing list
COSE@ietf.org
https://www.ietf.org/= mailman/listinfo/cose

 

------=_NextPart_000_020A_01D3A4DA.229D0D20-- From nobody Tue Feb 13 16:03:33 2018 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 5A8FC12EAB6 for ; Tue, 13 Feb 2018 16:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 dp8cs4MW1eXu for ; Tue, 13 Feb 2018 16:03:28 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on070b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::70b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB36B1270AC for ; Tue, 13 Feb 2018 16:03:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N72CJryyunwwa0lsSRVCbbNnT0wyyJGnxZfvPhHQ9Do=; b=SNsZhe3imeOWqpwogUL8F9QaWiLqMoII+zDluDcoCLJ1babnDMb6v5v38ldAvmYR55YOl+9GCcFr+gCZFM/xfEdZ2RpwApYeTROt+8bezVoSVe2F1gK7WpAJTLSNTCTAx6JIxpJr3YK0k2gHL8Xh4V6ZJF15DWxh5u8aQfclU0E= Received: from SN6PR2101MB0943.namprd21.prod.outlook.com (52.132.114.20) by SN6PR2101MB1101.namprd21.prod.outlook.com (52.132.115.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.527.3; Wed, 14 Feb 2018 00:03:25 +0000 Received: from SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50]) by SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50%2]) with mapi id 15.20.0527.006; Wed, 14 Feb 2018 00:03:25 +0000 From: Mike Jones To: 'Yuriy Ackermann' CC: 'Laurence Lundblade' , "cose@ietf.org" , Jim Schaad Thread-Topic: [COSE] Adding secp256k1 Thread-Index: AQHTpNnN4jUbyPdbTEq8ey5GpifNy6OimKGAgABYCACAABOsUA== Date: Wed, 14 Feb 2018 00:03:25 +0000 Message-ID: References: <90CF094D-6218-46C3-9D30-382D97F73388@qti.qualcomm.com> <020901d3a51d$30bfb0e0$923f12a0$@augustcellars.com> In-Reply-To: <020901d3a51d$30bfb0e0$923f12a0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-02-14T00:03:20.9793216Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:4::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR2101MB1101; 7:YNQDJv90DI8ZmSpkxUc1sOeFUUozl7EXGWgZSYCB3B5PerY9T8VtmBnT5Ow3+aqR/j/nhY8lxs3p14OPBukxODj9jcoYf9Vp4oC/C8Hm6jZEuzEcgHNRLj8NEgHHbMaGVlrUJn8sEw0pQpgeLqrAiCzBQAEfie/8a/x9/MFW8mi+5Ub1nsi9XRKf5C0iuuvYZ1J7uG/seissJh0yNhlwOb5FzDHTBRTB/J0zCJ5m0NOLovS7Rp/01Hrf3qFsiIzP x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a37c0cc1-a5fa-49ef-193c-08d5733e5ee2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:SN6PR2101MB1101; x-ms-traffictypediagnostic: SN6PR2101MB1101: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(21748063052155)(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001015)(61425038)(6040501)(2401047)(8121501046)(5005006)(3002001)(3231101)(944501161)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:SN6PR2101MB1101; BCL:0; PCL:0; RULEID:; SRVR:SN6PR2101MB1101; x-forefront-prvs: 0583A86C08 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39380400002)(346002)(396003)(39860400002)(189003)(199004)(252514010)(8990500004)(236005)(54906003)(53936002)(733005)(6436002)(14454004)(86612001)(3280700002)(68736007)(6306002)(2900100001)(966005)(54896002)(22452003)(99286004)(76176011)(316002)(606006)(9686003)(105586002)(7736002)(33656002)(55016002)(74316002)(478600001)(10290500003)(7696005)(10090500001)(106356001)(72206003)(81156014)(6116002)(2906002)(5660300001)(4326008)(25786009)(86362001)(229853002)(3660700001)(6246003)(8676002)(8936002)(6916009)(2950100002)(19609705001)(102836004)(5250100002)(6346003)(53546011)(790700001)(59450400001)(186003)(97736004)(6506007)(81166006)(15398625002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR2101MB1101; H:SN6PR2101MB0943.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: DvtlQ3EnwuCz65UkluTO3X+X3SIuWO6eUwhsD1bZY3axDfq0s90/FmIFIsMDzfHj6kyX2n6/VgJutO3JVzI7cg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN6PR2101MB094361788D7024F3329670E9F5F50SN6PR2101MB0943_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a37c0cc1-a5fa-49ef-193c-08d5733e5ee2 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2018 00:03:25.8898 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR2101MB1101 Archived-At: Subject: Re: [COSE] Adding secp256k1 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 00:03:31 -0000 --_000_SN6PR2101MB094361788D7024F3329670E9F5F50SN6PR2101MB0943_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yuriy - I can work with you to write the necessary text for UAF to register= the additional algorithms it needs. I'll talk with you off-list about it. -- Mike From: COSE On Behalf Of Jim Schaad Sent: Tuesday, February 13, 2018 2:51 PM To: 'Yuriy Ackermann' Cc: 'Laurence Lundblade' ; cose@ietf.org Subject: Re: [COSE] Adding secp256k1 I would not do the private range version below if you are going to publish = in FIDO docs. This is really meant for completely closed and experimental = and not for any public standards use. From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Laurence Lundblade Sent: Tuesday, February 13, 2018 9:36 AM To: Yuriy Ackermann > Cc: cose@ietf.org Subject: Re: [COSE] Adding secp256k1 Hi Yuri, The COSE specification probably should not change to accommodate this. The = IANA COSE algorithm registry should be used instead. There are several options: - Write a standards track IETF document and get it set in the IANA COSE re= gistry. - Write a specification (presumably public) and get it set IANA COSE regis= try. - Use an identifier in the private range and publish it only in FIDO docs. LL On Feb 13, 2018, at 5:27 AM, Yuriy Ackermann > wrote: Hey guys. I work for FIDO Alliance. We are currently selecting a list of cu= rves we going to support. We want to support secp256k1 in COSE, as we are a= lready supporting it in UAF, and we have companies who really want it. I know that in security considerations you've said that there is possibilit= y of collision of the signatures from k1 and p1, but the chances of such th= ing happening are enough low for it to be ignored. We are proposing adding secp256k1 into list of curves, in section 13.1 with= value 8 Regards. Yuriy [FIDO Alliance]Yuriy Ackermann Senior Certification Engineer email: yuriy@fidoalliance.org skype: ackermann.yuriy website: https://fidoalliance.org _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose --_000_SN6PR2101MB094361788D7024F3329670E9F5F50SN6PR2101MB0943_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yuriy – I can wo= rk with you to write the necessary text for UAF to register the additional = algorithms it needs.  I’ll talk with you off-list about it.=

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike=

 

From: COSE <cose-bounces@ietf.org> O= n Behalf Of Jim Schaad
Sent: Tuesday, February 13, 2018 2:51 PM
To: 'Yuriy Ackermann' <yuriy@fidoalliance.org>
Cc: 'Laurence Lundblade' <llundbla@qti.qualcomm.com>; cose@iet= f.org
Subject: Re: [COSE] Adding secp256k1

 

I would not do the private range version below if yo= u are going to publish in FIDO docs.  This is really meant for complet= ely closed and experimental and not for any public standards use.

 

 

 

From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Laurence Lundblade
Sent: Tuesday, February 13, 2018 9:36 AM
To: Yuriy Ackermann <yu= riy@fidoalliance.org>
Cc: cose@ietf.org
Subject: Re: [COSE] Adding secp256k1

 

Hi Yuri,

 

The COSE specification probably should not change to= accommodate this. The IANA COSE algorithm registry should be used instead.=

 

There are several options:

- Write a standards track IETF document and get it s= et in the  IANA COSE registry.

- Write a specification (presumably public) and get = it set &n= bsp;IANA COSE registry.

- Use an identifier in the private range and publish= it only in FIDO docs.

 

LL

 

 

 

On Feb 13, 2018, at 5:27 AM, Yuriy Ackermann <yuriy@fidoalliance.org> wrote= :

 

Hey guys. I work for FIDO Alliance. We are currently= selecting a list of curves we going to support. We want to support secp256= k1 in COSE, as we are already supporting it in UAF, and we have companies w= ho really want it. 

 

I know that in security considerations you've said t= hat there is possibility of collision of the signatures from k1 and p1, but= the chances of such thing happening are enough low for it to be ignored.

 

We are proposing adding secp256k1 into list of curves, in section 13.1 with value 8 

 

Regards. Yuriy

3D"FIDOYuriy Ackermann
Senior Certification Engineer
email: yuriy@fidoalliance.org
skype: ackermann.yuriy
website:=  https://fidoalliance.org

_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org= /mailman/listinfo/cose

 

--_000_SN6PR2101MB094361788D7024F3329670E9F5F50SN6PR2101MB0943_-- From nobody Wed Feb 14 03:59:22 2018 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 58F391273B1 for ; Wed, 14 Feb 2018 03:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fidoalliance.org 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 ZzuL1YyktbpJ for ; Wed, 14 Feb 2018 03:59:17 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 ACD9212711D for ; Wed, 14 Feb 2018 03:59:17 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id y186so6635904ywf.7 for ; Wed, 14 Feb 2018 03:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fidoalliance.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pijRh+ABtxjuR88xBZpbko2yw4Pn5AbNfXEwuEV62Wg=; b=amYpJ3hC+FQaTb9M3jzWgEtCcEoNU0LQVEKxyB7z/E/TNVJb6lj9jLU01Kao3nt7sB qT/xJqwZs3CKesURGSg3xHxjDg0v+EFSurMIlAYZzOS1JhRkB/pqoQ4dG3eQsFhSu1Y4 ZjBaSs0OXxnukhTfGruLWdQKEc+TNXNf7dngs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pijRh+ABtxjuR88xBZpbko2yw4Pn5AbNfXEwuEV62Wg=; b=pfiXjXjmIMHZ4+QNnPmLr/sek1pLCHVAo+kE7b47BrZor55Zs7P+KGHin9V21CgaV1 i7qBfO7kME/b0uJRs71YisPUAEAgNMho/8H5P13MgZJvVKD7UjlzBkovnTtA4CG+FD0T ULtenH4+dRuDQHm6r89Z4yRNTjBwFVWjZOmFHZq+WggU4aLKnDW+8sexopZfufIZ6Gyb eK+Ui1ngWGTLB/BXhRgjXquRlQ3cp7kIw5dsu/etp4zyqpqIOMoKu256J9ssPDaEx1kH 91QgF8A7Qjty1UuyDqevlrNjdcEl++CIG9ILGnYqD64/jyuixc9TNr8jmc57OLI19rT6 GaQw== X-Gm-Message-State: APf1xPD9df02dMQOiqHE/OLVkKPIyi+ALDzEClRTJcMxgS3SE1MdddCc atQOotIrYqgZwFb53q7psYtMQrDawjrGAikb1pyaPQ== X-Google-Smtp-Source: AH8x22791QoVHnFd+FqDnHCJxqDq8a5vyKXrRPk8GA+1rzodppPWBePBSV6EhScACT3ExxBWkUF+icYSgejMQ++w/J8= X-Received: by 10.37.30.7 with SMTP id e7mr334884ybe.345.1518609556966; Wed, 14 Feb 2018 03:59:16 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:281:0:0:0:0:0 with HTTP; Wed, 14 Feb 2018 03:59:16 -0800 (PST) In-Reply-To: References: <90CF094D-6218-46C3-9D30-382D97F73388@qti.qualcomm.com> <020901d3a51d$30bfb0e0$923f12a0$@augustcellars.com> From: Yuriy Ackermann Date: Wed, 14 Feb 2018 11:59:16 +0000 Message-ID: To: Mike Jones Cc: Laurence Lundblade , "cose@ietf.org" , Jim Schaad Content-Type: multipart/alternative; boundary="001a113a951a32166205652ad74d" Archived-At: Subject: Re: [COSE] Adding secp256k1 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 11:59:20 -0000 --001a113a951a32166205652ad74d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Awesome! Thank you all for your help! [image: FIDO Alliance] * Yuriy Ackermann * Senior Certification Engineer *email:* yuriy@fidoalliance.org *skype:* ackermann.yuriy *website:* https://fidoalliance.org On Wed, Feb 14, 2018 at 12:03 AM, Mike Jones wrote: > Yuriy =E2=80=93 I can work with you to write the necessary text for UAF t= o > register the additional algorithms it needs. I=E2=80=99ll talk with you = off-list > about it. > > > > -- Mike > > > > *From:* COSE *On Behalf Of * Jim Schaad > *Sent:* Tuesday, February 13, 2018 2:51 PM > *To:* 'Yuriy Ackermann' > *Cc:* 'Laurence Lundblade' ; cose@ietf.org > > *Subject:* Re: [COSE] Adding secp256k1 > > > > I would not do the private range version below if you are going to publis= h > in FIDO docs. This is really meant for completely closed and experimenta= l > and not for any public standards use. > > > > > > > > *From:* COSE [mailto:cose-bounces@ietf.org ] *On > Behalf Of *Laurence Lundblade > *Sent:* Tuesday, February 13, 2018 9:36 AM > *To:* Yuriy Ackermann > *Cc:* cose@ietf.org > *Subject:* Re: [COSE] Adding secp256k1 > > > > Hi Yuri, > > > > The COSE specification probably should not change to accommodate this. Th= e > IANA COSE algorithm registry should be used instead. > > > > There are several options: > > - Write a standards track IETF document and get it set in the IANA COSE > registry . > > - Write a specification (presumably public) and get it set IANA COSE > registry . > > - Use an identifier in the private range and publish it only in FIDO docs= . > > > > LL > > > > > > > > On Feb 13, 2018, at 5:27 AM, Yuriy Ackermann > wrote: > > > > Hey guys. I work for FIDO Alliance. We are currently selecting a list of > curves we going to support. We want to support secp256k1 in COSE, as we a= re > already supporting it in UAF, and we have companies who really want it. > > > > I know that in security considerations you've said that there is > possibility of collision of the signatures from k1 and p1, but the chance= s > of such thing happening are enough low for it to be ignored. > > > > We are proposing adding secp256k1 into list of curves, in section 13.1 > with value 8 > > > > Regards. Yuriy > > [image: FIDO Alliance] *Yuriy Ackermann * > Senior Certification Engineer > *email:* yuriy@fidoalliance.org > *skype:* ackermann.yuriy > *website:* https://fidoalliance.org > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > > --001a113a951a32166205652ad74d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Awesome! Thank you all for your help!

3D"FIDO Yuriy Ackermann
Senior Certification Engineer
email:=C2=A0yuriy@fidoalliance.org
skype:=C2=A0ackermann.yuriy<= /a>
website:=C2=A0https://fidoalliance.org


On Wed, Feb 14, 2018 at 12:03 AM, Mike Jones= <Michael.Jones@microsoft.com> wrote:

Yuriy =E2=80=93 I can = work with you to write the necessary text for UAF to register the additiona= l algorithms it needs.=C2=A0 I=E2=80=99ll talk with you off-list about it.<= u>

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mik= e

=C2=A0

From: COSE <cose-bounces@ietf.org> On Behalf Of = Jim Schaad
Sent: Tuesday, February 13, 2018 2:51 PM
To: 'Yuriy Ackermann' <yuriy@fidoalliance.org>
Cc: 'Laurence Lundblade' <llundbla@qti.qualcomm.com>; cose@ietf.org


Subject: Re: [COSE] Adding secp256k1

=C2=A0

I would not do the private range version below if yo= u are going to publish in FIDO docs.=C2=A0 This is really meant for complet= ely closed and experimental and not for any public standards use.=

=C2=A0

=C2=A0

=C2=A0

From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Laurence Lundblade
Sent: Tuesday, February 13, 2018 9:36 AM
To: Yuriy Ackermann <yuriy@fidoalliance.org>
Cc: cose@ietf.org=
Subject: Re: [COSE] Adding secp256k1

=C2=A0

Hi Yuri,

=C2=A0

The COSE specification probably should not change to= accommodate this. The IANA COSE algorithm registry should be used instead.=

=C2=A0

There are several options:

- Write a standards track IETF document and get it s= et in the=C2=A0=C2=A0IANA COSE registry.

- Write a specification (presumably public) and get = it set=C2=A0=C2=A0IANA COSE registry.

- Use an identifier in the private range and publish= it only in FIDO docs.

=C2=A0

LL

=C2=A0

=C2=A0

=C2=A0

On Feb 13, 2018, at 5:27 AM, Yuriy Ackermann <yuriy@fidoalliance= .org> wrote:

=C2=A0

Hey guys. I work for FIDO Alliance. We are currently= selecting a list of curves we going to support. We want to support secp256= k1 in COSE, as we are already supporting it in UAF, and we have companies w= ho really want it.=C2=A0

=C2=A0

I know that in security considerations you've sa= id that there is possibility of collision of the signatures from k1 and p1,= but the chances of such thing happening are enough low for it to be ignore= d.

=C2=A0

We are proposing adding=C2=A0secp256k1 into list of curves, in section 13.1 with value 8=C2=A0

=C2=A0

Regards. Yuriy

3D"FIDOYuriy Ackermann
Senior Certification Engineer
email:=C2=A0yuriy@fidoalliance.org
skype:=C2=A0ackermann.yuriy
website:= =C2=A0https://fidoalliance.org

_______________________________________________=
COSE mailing list
COSE@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cose

=C2=A0


--001a113a951a32166205652ad74d-- From nobody Wed Feb 14 10:06:05 2018 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 BB73F12D80E for ; Wed, 14 Feb 2018 10:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 EVM9xlFyHfNe for ; Wed, 14 Feb 2018 10:06:01 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 108AF12D7EA for ; Wed, 14 Feb 2018 10:06:01 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id c128so27742408qkb.4 for ; Wed, 14 Feb 2018 10:06:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YKJsA3Nod1wM9VMAMaZkl6NTqOqikdkccgtGZsRBl1s=; b=V/nIXI+290dsxJpMyiyspjloSYjiqDK+ZZdH3Ds2bNN4BflII0g0C25N88fnj0DROS g4NyzwGcxOOcpTuIBPWZ6IrRKawA6bZWXn/eoDCDz/PZcVUYkpkVdMPDT0ocE9UdX2j8 hHMPdBh47KO6RvBJ0XrAkTRFPVtBqquEN/qpg5E7meIbkEQ1WIbl/6AHOfTGI2rSus6x dEnNkQG1xQgE3TFn6c7T+nMVb1U0v6b9Fj3Nxo4ovyOxj++AE/8QGGbiSy8nb8zcGp5m QGu53Nwlgm+q3MChEtU4n5GidaoVIem0EUk0P4qtbLGTLXZqeTCxfcKm/ApbsgIghvY3 m9gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YKJsA3Nod1wM9VMAMaZkl6NTqOqikdkccgtGZsRBl1s=; b=UpNW+hF4c/GoLXWvmgUaVag+Nj7C82yiFpPEw5N4U9zQ2x3MlPYwLxIget/YpAoa/C ULggI7IHpNxjp4VtSAl779wYCMNlVoCbo35vQlJPm/J7FXK18EV1vvs8hreWYno8XbH0 UEquruDpb/ainUlHGpWUs4vszSyIQjO4xkPRdXauMKMWtfn1dMA/blOjAy9j9RWRuM+3 Py0sQ0pl60dgWPRJ0rd74Fe11d0SfLw15PXRNExIX2ybHA/ipHfhwqI9VJ7gibH4wCtp 5/KxgA5758jK0PitVoNj+jHpEVHKS670vUj7SFNLrgxOwqC6NMsA4m3Dv5kvwRUNJUMN mcgA== X-Gm-Message-State: APf1xPCmIKXKTc1R1lOLvAqxSPrQMB8f94BJVa1ro6K2JmS3XmN03XgG uWRTos389aJcRj3Kvhl13LA= X-Google-Smtp-Source: AH8x2263zJZkmsS7aFxdXLjsJolp4maMy9VMDsgHXcyn7PnpPy3a9A4Em/4P4O1FcS/ZbVn+fo2wzA== X-Received: by 10.55.119.198 with SMTP id s189mr5737qkc.88.1518631560126; Wed, 14 Feb 2018 10:06:00 -0800 (PST) Received: from [192.168.1.219] (209-6-112-84.s338.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.112.84]) by smtp.gmail.com with ESMTPSA id v22sm9621770qkl.24.2018.02.14.10.05.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Feb 2018 10:05:59 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-8FD31E22-4FDF-45FC-8897-8B7A23160B7F Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15D60) In-Reply-To: Date: Wed, 14 Feb 2018 13:05:58 -0500 Cc: Mike Jones , Laurence Lundblade , Jim Schaad , "cose@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <90CF094D-6218-46C3-9D30-382D97F73388@qti.qualcomm.com> <020901d3a51d$30bfb0e0$923f12a0$@augustcellars.com> To: Yuriy Ackermann Archived-At: Subject: Re: [COSE] Adding secp256k1 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 18:06:03 -0000 --Apple-Mail-8FD31E22-4FDF-45FC-8897-8B7A23160B7F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Yuriy. Once you have a draft ready, please start by posting it here for review. Th= e step after that will be to get it published. You can ask an Area Director= to sponsor it and have it published as an individual draft or can also pres= ent it at SecDispatch and direction for next steps should be provided. I step down in a few weeks, so I won=E2=80=99t be the AD to sponsor it, but c= an help with questions/point you to the right people. Best regards, Kathleen=20 Sent from my mobile device > On Feb 14, 2018, at 6:59 AM, Yuriy Ackermann wrot= e: >=20 > Awesome! Thank you all for your help! >=20 > Yuriy Ackermann=20 > Senior Certification Engineer > email: yuriy@fidoalliance.org > skype: ackermann.yuriy > website: https://fidoalliance.org >=20 >> On Wed, Feb 14, 2018 at 12:03 AM, Mike Jones wrote: >> Yuriy =E2=80=93 I can work with you to write the necessary text for UAF t= o register the additional algorithms it needs. I=E2=80=99ll talk with you o= ff-list about it. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: COSE On Behalf Of Jim Schaad >> Sent: Tuesday, February 13, 2018 2:51 PM >> To: 'Yuriy Ackermann' >> Cc: 'Laurence Lundblade' ; cose@ietf.org >>=20 >>=20 >> Subject: Re: [COSE] Adding secp256k1 >> =20 >>=20 >> I would not do the private range version below if you are going to publis= h in FIDO docs. This is really meant for completely closed and experimental= and not for any public standards use. >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Laurence Lundblade= >> Sent: Tuesday, February 13, 2018 9:36 AM >> To: Yuriy Ackermann >> Cc: cose@ietf.org >> Subject: Re: [COSE] Adding secp256k1 >>=20 >> =20 >>=20 >> Hi Yuri, >>=20 >> =20 >>=20 >> The COSE specification probably should not change to accommodate this. Th= e IANA COSE algorithm registry should be used instead. >>=20 >> =20 >>=20 >> There are several options: >>=20 >> - Write a standards track IETF document and get it set in the IANA COSE r= egistry. >>=20 >> - Write a specification (presumably public) and get it set IANA COSE reg= istry. >>=20 >> - Use an identifier in the private range and publish it only in FIDO docs= . >>=20 >> =20 >>=20 >> LL >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On Feb 13, 2018, at 5:27 AM, Yuriy Ackermann wro= te: >>=20 >> =20 >>=20 >> Hey guys. I work for FIDO Alliance. We are currently selecting a list of c= urves we going to support. We want to support secp256k1 in COSE, as we are a= lready supporting it in UAF, and we have companies who really want it.=20 >>=20 >> =20 >>=20 >> I know that in security considerations you've said that there is possibil= ity of collision of the signatures from k1 and p1, but the chances of such t= hing happening are enough low for it to be ignored. >>=20 >> =20 >>=20 >> We are proposing adding secp256k1 into list of curves, in section 13.1 wi= th value 8=20 >>=20 >> =20 >>=20 >> Regards. Yuriy >>=20 >> Yuriy Ackermann=20 >> Senior Certification Engineer >> email: yuriy@fidoalliance.org >> skype: ackermann.yuriy >> website: https://fidoalliance.org >>=20 >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >>=20 >> =20 >>=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail-8FD31E22-4FDF-45FC-8897-8B7A23160B7F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Yuriy.

Once you h= ave a draft ready, please start by posting it here for review.  The ste= p after that will be to get it published.  You can ask an Area Director= to sponsor it and have it published as an individual draft or can also pres= ent it at SecDispatch and direction for next steps should be provided.
=

I step down in a few weeks, so I won=E2=80=99t be the AD= to sponsor it, but can help with questions/point you to the right people.

Best regards,
Kathleen 
Sent from my mobile device

On = Feb 14, 2018, at 6:59 AM, Yuriy Ackermann <yuriy@fidoalliance.org> wrote:

Awesome! Thank you all for your help!

=

3D"FIDO Yuriy Ackermann
Senior Certification Engineer
email: yuriy@fidoalliance.org
skype: ackermann.yuriy
website: https://fidoalliance.org


On Wed, Feb 14, 2018 at 12:03 AM, Mike Jones <= span dir=3D"ltr"><Michael.Jones@microsoft.com> wrote:

Yuriy =E2=80=93 I can w= ork with you to write the necessary text for UAF to register the additional a= lgorithms it needs.  I=E2=80=99ll talk with you off-list about it.

 

    = ;            &nb= sp;            &= nbsp;           =             &nbs= p;          -- Mike=

 

From: COSE <cose-bounces@ietf.org> On Behalf Of Jim Schaad
Sent: Tuesday, February 13, 2018 2:51 PM
To: 'Yuriy Ackermann' <yuriy@fidoalliance.org>
Cc: 'Laurence Lundblade' <llundbla@qti.qualcomm.com>; cose@ietf.org


Subject: Re: [COSE] Adding secp256k1

=

 

I would not do the private range version below if you= are going to publish in FIDO docs.  This is really meant for completel= y closed and experimental and not for any public standards use.

 

 

 

From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Laurence Lundblade
Sent: Tuesday, February 13, 2018 9:36 AM
To: Yuriy Ackermann <yuriy@fidoalliance.org>
Cc: cose@ietf.org<= /a>
Subject: Re: [COSE] Adding secp256k1

 

Hi Yuri,

 

The COSE specification probably should not change to a= ccommodate this. The IANA COSE algorithm registry should be used instead.=

 

There are several options:

- Write a specification (presumably public) and get i= t set  IANA COSE registry.

- Use an identifier in the private range and publish i= t only in FIDO docs.

 

LL

 

 

 

On Feb 13, 2018, at 5:27 AM, Yuriy Ackermann <yuriy@fidoalliance.o= rg> wrote:

 

Hey guys. I work for FIDO Alliance. We are currently s= electing a list of curves we going to support. We want to support secp256k1 i= n COSE, as we are already supporting it in UAF, and we have companies who re= ally want it. 

 

I know that in security considerations you've said th= at there is possibility of collision of the signatures from k1 and p1, but t= he chances of such thing happening are enough low for it to be ignored.

 

We are proposing adding secp256k1 into list of curves, in section 13.1 with value 8 

 

Regards. Yuriy

3D"FIDOYuriy Ackermann
Senior Certification Engineer
email: yuriy@fidoalliance.org
skype: ackermann.yuriy
website:<= /span> https://fidoalliance.org

_______________________________________________<= br> COSE mailing list
COSE@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/cose

 


____________________= ___________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman= /listinfo/cose
= --Apple-Mail-8FD31E22-4FDF-45FC-8897-8B7A23160B7F-- From nobody Sat Feb 17 08:34:55 2018 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 C2DDA1204DA; Sat, 17 Feb 2018 08:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, 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 JApWs0NPk0ix; Sat, 17 Feb 2018 08:34:44 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 16CB4120725; Sat, 17 Feb 2018 08:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1HGYepK013857; Sat, 17 Feb 2018 17:34:40 +0100 (CET) Received: from client-0231.vpn.uni-bremen.de (client-0231.vpn.uni-bremen.de [134.102.107.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zkFwF6pZ9zDXjD; Sat, 17 Feb 2018 17:34:37 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 540578068.245754-97e5f0bc463b69dabaa858a33a4d2e19 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sat, 17 Feb 2018 08:34:29 -0800 Message-Id: To: ace@ietf.org, "core@ietf.org WG (core@ietf.org)" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [COSE] Constrained Node/Network Cluster @ IETF101: DRAFT AGENDA X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Feb 2018 16:34:46 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF101. Remember that there is still quite some potential for changes. The painful ones (not necessarily fixable) this time include: DINRG vs. ACE, CBOR vs. TEEP, ROLL vs. SUIT vs. OCF/WoT; also CORE vs. ANIMA, CORE vs. QUIC. All times are BST (UTC+0100). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- Hackathon (including various interops) MONDAY, March 19, 2018 0930-1200 Morning Session I Bleinheim ART dispatch Dispatch WG - 0930-1100 Joint = with ARTAREA Sandringham INT ipwave IP Wireless Access in Vehicular = Environments WG Palace C IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Viscount OPS v6ops IPv6 Operations WG Balmoral SEC *** ace Authentication and Authorization for = Constrained Environments WG 1330-1530 Afternoon Session I Buckingham ART *** core Constrained RESTful Environments WG Viscount INT 6man IPv6 Maintenance WG Sandringham TSV quic QUIC WG 1550-1720 Afternoon Session II Sandringham INT intarea Internet Area Working Group WG Balmoral IRTF cfrg Crypto Forum Buckingham SEC oauth Web Authorization Protocol WG 1740-1840 Afternoon Session III Balmoral SEC tls Transport Layer Security WG Sandringham TSV tsvarea Transport Area Open Meeting TUESDAY, March 20, 2018 0930-1200 Morning Session I Viscount ART *** core Constrained RESTful Environments WG Sandringham IRTF maprg Measurement and Analysis for Protocols Buckingham OPS anima Autonomic Networking Integrated Model = and Approach WG Bleinheim SEC secdispatch Security Dispatch WG 1330-1530 Afternoon Session I Park Suite ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Buckingham IRTF panrg Path Aware Networking Proposed RG Richm_Chl_Tow RTG rift Routing In Fat Trees WG Balmoral SEC *** teep Trusted Execution Environment = Provisioning BOF 1550-1820 Afternoon Session II Balmoral ART httpbis Hypertext Transfer Protocol WG Park Suite IRTF icnrg Information-Centric Networking WEDNESDAY, March 21, 2018 0930-1200 Morning Session I Viscount INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Sandringham IRTF irtfopen IRTF Open Meeting Bleinheim SEC tls Transport Layer Security WG Park Suite TSV taps Transport Services WG 1330-1500 Afternoon Session I Viscount INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Richm_Chl_Tow RTG bier Bit Indexed Explicit Replication WG Park Suite SEC oauth Web Authorization Protocol WG Palace C TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1650 Afternoon Session II Park Suite INT *** lwig Light-Weight Implementation Guidance WG Buckingham SEC acme Automated Certificate Management = Environment WG Viscount SEC tokbind Token Binding WG 1710-1940 IETF Plenary - Sandringham THURSDAY, March 22, 2018 0930-1200 Morning Session I Buckingham INT dnssd Extensions for Scalable DNS Service = Discovery WG Park Suite RTG *** roll Routing Over Low power and Lossy = networks WG Sandringham TSV quic QUIC WG 1330-1530 Afternoon Session I Buckingham INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Sandringham SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Bleinheim IRTF*** t2trg Thing-to-Thing Sandringham RTG rtgarea Routing Area Open Meeting Buckingham SEC mls Messaging Layer Security BOF Balmoral TSV tsvwg Transport Area Working Group WG 1810-1910 Afternoon Session III Bleinheim ART uta Using TLS in Applications WG Park Suite RTG babel Babel routing protocol WG Balmoral TSV tsvwg Transport Area Working Group WG FRIDAY, March 23, 2018 0930-1130 Morning Session I Richm_Chl_Tow ART ice Interactive Connectivity Establishment = WG - 0930 - 1030 Sandringham INT homenet Home Networking WG Bleinheim RTG detnet Deterministic Networking WG Viscount RTG *** roll Routing Over Low power and Lossy = networks WG Balmoral SEC *** suit Software Updates for Internet of Things = WG 1150-1320 Afternoon Session I Bleinheim RTG detnet Deterministic Networking WG 1330-1730 @ OCF meeting venue (Prague, colocated with W3C WoT) -- Joint meeting of OCF, W3C WoT, and T2TRG From nobody Sat Feb 24 00:03:44 2018 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 0AD21126D45; Sat, 24 Feb 2018 00:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 BpTacQAHyYk4; Sat, 24 Feb 2018 00:03:35 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 14003120227; Sat, 24 Feb 2018 00:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1O83Vm7021286; Sat, 24 Feb 2018 09:03:31 +0100 (CET) Received: from client-0185.vpn.uni-bremen.de (client-0185.vpn.uni-bremen.de [134.102.107.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zpLFG64Z9zDXfw; Sat, 24 Feb 2018 09:03:30 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 541152208.06002-906f3783a4e6b88ee7e0de21eeb0bf70 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sat, 24 Feb 2018 00:03:29 -0800 Message-Id: <42D54C90-DA66-42FB-B734-27986B87BC2E@tzi.org> To: ace , "core@ietf.org WG" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [COSE] Constrained Node/Network Cluster @ IETF101: "FINAL" AGENDA X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2018 08:03:38 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF101. Remember that "FINAL" means this will be the basis for printed agenda sheets, there is still some potential for changes after that. SUIT is now on top of CORE (!??). (Also, ICE has moved.) The painful ones this time include: DINRG vs. ACE, CBOR vs. TEEP, ROLL vs. traveling to OCF/WoT; also CORE vs. ANIMA, CORE vs. QUIC, CORE vs. SECDISPATCH. All times are actually in GMT (UTC+0000, DST only starts in London on March 25). (You can always get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- Hackathon (including various interops) MONDAY, March 19, 2018 0930-1200 Morning Session I Blenheim ART dispatch Dispatch WG - 0930-1100 Joint = with ARTAREA Sandringham INT ipwave IP Wireless Access in Vehicular = Environments WG Palace C IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Viscount OPS v6ops IPv6 Operations WG Balmoral SEC *** ace Authentication and Authorization for = Constrained Environments WG 1330-1530 Afternoon Session I Richm_Chl_Tow ART *** core Constrained RESTful Environments WG Viscount INT 6man IPv6 Maintenance WG Buckingham SEC *** suit Software Updates for Internet of Things = WG Sandringham TSV quic QUIC WG 1550-1720 Afternoon Session II Sandringham INT intarea Internet Area Working Group WG Balmoral IRTF cfrg Crypto Forum Viscount SEC oauth Web Authorization Protocol WG 1740-1840 Afternoon Session III Balmoral SEC tls Transport Layer Security WG Sandringham TSV tsvarea Transport Area Open Meeting TUESDAY, March 20, 2018 0930-1200 Morning Session I Viscount ART *** core Constrained RESTful Environments WG Sandringham IRTF maprg Measurement and Analysis for Protocols Buckingham OPS anima Autonomic Networking Integrated Model = and Approach WG Blenheim SEC secdispatch Security Dispatch WG 1330-1530 Afternoon Session I Park Suite ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Palace C ART ice Interactive Connectivity Establishment = WG Buckingham IRTF panrg Path Aware Networking Proposed RG Richm_Chl_Tow RTG rift Routing In Fat Trees WG Balmoral SEC *** teep Trusted Execution Environment = Provisioning BOF 1550-1820 Afternoon Session II Balmoral ART httpbis Hypertext Transfer Protocol WG Park Suite IRTF icnrg Information-Centric Networking WEDNESDAY, March 21, 2018 0930-1200 Morning Session I Viscount INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Sandringham IRTF irtfopen IRTF Open Meeting Blenheim SEC tls Transport Layer Security WG Park Suite TSV taps Transport Services WG 1330-1500 Afternoon Session I Viscount INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Richm_Chl_Tow RTG bier Bit Indexed Explicit Replication WG Park Suite SEC oauth Web Authorization Protocol WG Palace C TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1650 Afternoon Session II Park Suite INT *** lwig Light-Weight Implementation Guidance WG Buckingham SEC acme Automated Certificate Management = Environment WG Viscount SEC tokbind Token Binding WG 1710-1940 IETF Plenary - Sandringham THURSDAY, March 22, 2018 0930-1200 Morning Session I Buckingham INT dnssd Extensions for Scalable DNS Service = Discovery WG Park Suite RTG *** roll Routing Over Low power and Lossy = networks WG Sandringham TSV quic QUIC WG 1330-1530 Afternoon Session I Buckingham INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Sandringham SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Blenheim IRTF*** t2trg Thing-to-Thing Sandringham RTG rtgarea Routing Area Open Meeting Buckingham SEC mls Messaging Layer Security BOF Balmoral TSV tsvwg Transport Area Working Group WG 1810-1910 Afternoon Session III Blenheim ART uta Using TLS in Applications WG Park Suite RTG babel Babel routing protocol WG Balmoral TSV tsvwg Transport Area Working Group WG FRIDAY, March 23, 2018 0930-1130 Morning Session I Sandringham INT homenet Home Networking WG Blenheim RTG detnet Deterministic Networking WG Viscount RTG *** roll Routing Over Low power and Lossy = networks WG 1150-1320 Afternoon Session I Blenheim RTG detnet Deterministic Networking WG - 1150 - = 1430 1330-1730 @ OCF meeting venue (Prague, colocated with W3C WoT) -- Joint meeting of OCF, W3C WoT, and T2TRG (UTC+01:00 times) From nobody Mon Feb 26 09:01:59 2018 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 DF8B212D88B for ; Mon, 26 Feb 2018 09:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 WUhbmZIqnC_l for ; Mon, 26 Feb 2018 09:01:34 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 EA4DB12708C for ; Mon, 26 Feb 2018 09:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1QH1MNg015026 for ; Mon, 26 Feb 2018 18:01:22 +0100 (CET) Received: from client-0046.vpn.uni-bremen.de (client-0046.vpn.uni-bremen.de [134.102.107.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zqp4y3SlHzDWbv; Mon, 26 Feb 2018 18:01:22 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 541357279.598157-d873acd6e94a66d8cbd2d1455430a9e2 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 26 Feb 2018 18:01:21 +0100 Message-Id: <8D47D59A-D997-495A-A541-73896F6B92AF@tzi.org> To: cose@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [COSE] Digests (hashes) in COSE? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 17:01:37 -0000 I think that has come up before, but today in the SUIT WG Interim we = briefly discussed a structure where it would be useful to contain = multiple unkeyed digests (hashes) in one signed claim (*). In COSE, we = have a registry for keyed MAC schemes, but not for hashes. We also = don=E2=80=99t have a COSE_Digest structure (which would be quite simple, = I believe) either (**). To avoid everyone defining their own way of describing hashes, should we = be setting this up for COSE? We would have to be fast to be relevant for SUIT. Gr=C3=BC=C3=9Fe, Carsten (*) https://tools.ietf.org/html/draft-moran-suit-manifest-01#section-4 (**) maybe a bit like CMS digestedData, but simpler of course From nobody Tue Feb 27 16:48:24 2018 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 CD6AC127342 for ; Tue, 27 Feb 2018 16:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 UJV3rjrVzQ-a for ; Tue, 27 Feb 2018 16:48:21 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187091205F0 for ; Tue, 27 Feb 2018 16:48:21 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 27 Feb 2018 16:46:31 -0800 From: Jim Schaad To: 'Carsten Bormann' , References: <8D47D59A-D997-495A-A541-73896F6B92AF@tzi.org> In-Reply-To: <8D47D59A-D997-495A-A541-73896F6B92AF@tzi.org> Date: Tue, 27 Feb 2018 16:48:13 -0800 Message-ID: <02d801d3b02d$d1f026f0$75d074d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQEtieayEHTEMkMGEbQjF/dkV8hppqUFRnjQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Digests (hashes) in COSE? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 00:48:23 -0000 I need to re-publish my document with hash algorithms, however I am not = sure what needs to be placed in this structure in some ways. Is there something beyond MAC =3D [ Digest : bstr, Algorithm: alg_id ] If you start trying to carry the content you end up with problems = because it is just as often pointed to. Not sure that putting the = pointer in the digest computation would make sense as this value often = chances as well. Are you thinking of something specific that should be part of this? I am not sure just how strong the demand is for parametrized hash = algorithms is. I have used a couple in my lifetime, but always as cases = to see what would happen and have never used one in the wild. Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Monday, February 26, 2018 9:01 AM > To: cose@ietf.org > Subject: [COSE] Digests (hashes) in COSE? >=20 > I think that has come up before, but today in the SUIT WG Interim we = briefly > discussed a structure where it would be useful to contain multiple = unkeyed > digests (hashes) in one signed claim (*). In COSE, we have a registry = for > keyed MAC schemes, but not for hashes. We also don=E2=80=99t have a = COSE_Digest > structure (which would be quite simple, I believe) either (**). >=20 > To avoid everyone defining their own way of describing hashes, should = we > be setting this up for COSE? > We would have to be fast to be relevant for SUIT. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > (*) https://tools.ietf.org/html/draft-moran-suit-manifest-01#section-4 > (**) maybe a bit like CMS digestedData, but simpler of course >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Tue Feb 27 20:55:28 2018 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 E490712741D for ; Tue, 27 Feb 2018 20:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 J1KcOQipUYF2 for ; Tue, 27 Feb 2018 20:55:24 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C9C1241F8 for ; Tue, 27 Feb 2018 20:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1519793724; x=1551329724; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=czddkdVo48ie+lw11XZPbmw/7GnsKRhxPhAi4jOlJoc=; b=gUtsfipOg+PP8fkEQzhVRe7gOj0hfwyVuoVeslnCPCqhbB1LQxb12Lcv 5AqewNL+sejPiyz1QQp6eLKFYi4O2e2yyfLo6mXx0es38KfOFn2cnUQSU rCzKhVpnTtxuTMX3RkHwqh9+38LkCMOt/3xR2U15SlDoQoKkL5uAZ+2oy s=; X-IronPort-AV: E=Sophos;i="5.47,404,1515484800"; d="scan'208";a="424202621" Received: from unknown (HELO ironmsg01-sd.qualcomm.com) ([10.53.140.141]) by wolverine02.qualcomm.com with ESMTP; 27 Feb 2018 20:55:23 -0800 Received: from nasanexm01g.na.qualcomm.com ([10.85.0.33]) by ironmsg01-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 27 Feb 2018 20:55:23 -0800 Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01G.na.qualcomm.com (10.85.0.33) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 27 Feb 2018 20:55:22 -0800 Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1365.000; Tue, 27 Feb 2018 20:55:21 -0800 From: Laurence Lundblade To: Jim Schaad , 'Carsten Bormann' , "cose@ietf.org" Thread-Topic: [COSE] Digests (hashes) in COSE? Thread-Index: AQHTryONkKCQEr6CFEK/3EQ7Tw8UYqO5g3SA//+8/1k= Date: Wed, 28 Feb 2018 04:55:21 +0000 Message-ID: <1519793721953.72205@qti.qualcomm.com> References: <8D47D59A-D997-495A-A541-73896F6B92AF@tzi.org>, <02d801d3b02d$d1f026f0$75d074d0$@augustcellars.com> In-Reply-To: <02d801d3b02d$d1f026f0$75d074d0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.107.6] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [COSE] Digests (hashes) in COSE? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 04:55:26 -0000 I have used an alg id for a plain hash in a CBOR/COSE implementation. With= out going into details it was a special-purpose singing scheme. I ended up = using an id in the for-private-use space. =0A= =0A= My use aside, it seems helpful and useful to have SHA-256, 384... and frien= ds in the COSE IANA registry. =0A= =0A= LL=0A= =0A= ________________________________________=0A= From: COSE on behalf of Jim Schaad =0A= Sent: Tuesday, February 27, 2018 4:48 PM=0A= To: 'Carsten Bormann'; cose@ietf.org=0A= Subject: Re: [COSE] Digests (hashes) in COSE?=0A= =0A= I need to re-publish my document with hash algorithms, however I am not sur= e what needs to be placed in this structure in some ways.=0A= =0A= Is there something beyond=0A= =0A= MAC =3D [=0A= Digest : bstr,=0A= Algorithm: alg_id=0A= ]=0A= =0A= If you start trying to carry the content you end up with problems because i= t is just as often pointed to. Not sure that putting the pointer in the di= gest computation would make sense as this value often chances as well.=0A= =0A= Are you thinking of something specific that should be part of this?=0A= =0A= I am not sure just how strong the demand is for parametrized hash algorithm= s is. I have used a couple in my lifetime, but always as cases to see what= would happen and have never used one in the wild.=0A= =0A= Jim=0A= =0A= =0A= > -----Original Message-----=0A= > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Carsten Bormann=0A= > Sent: Monday, February 26, 2018 9:01 AM=0A= > To: cose@ietf.org=0A= > Subject: [COSE] Digests (hashes) in COSE?=0A= >=0A= > I think that has come up before, but today in the SUIT WG Interim we brie= fly=0A= > discussed a structure where it would be useful to contain multiple unkeye= d=0A= > digests (hashes) in one signed claim (*). In COSE, we have a registry fo= r=0A= > keyed MAC schemes, but not for hashes. We also don=92t have a COSE_Diges= t=0A= > structure (which would be quite simple, I believe) either (**).=0A= >=0A= > To avoid everyone defining their own way of describing hashes, should we= =0A= > be setting this up for COSE?=0A= > We would have to be fast to be relevant for SUIT.=0A= >=0A= > Gr=FC=DFe, Carsten=0A= >=0A= > (*) https://tools.ietf.org/html/draft-moran-suit-manifest-01#section-4=0A= > (**) maybe a bit like CMS digestedData, but simpler of course=0A= >=0A= > _______________________________________________=0A= > COSE mailing list=0A= > COSE@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/cose=0A= =0A= _______________________________________________=0A= COSE mailing list=0A= COSE@ietf.org=0A= https://www.ietf.org/mailman/listinfo/cose= From nobody Tue Feb 27 22:11:00 2018 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 D6DBD12741D for ; Tue, 27 Feb 2018 22:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 6sBcpEOLTDVA for ; Tue, 27 Feb 2018 22:10:56 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 0F9EA120713 for ; Tue, 27 Feb 2018 22:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1S6AEHc028700; Wed, 28 Feb 2018 07:10:14 +0100 (CET) Received: from [10.137.155.71] (unknown [88.128.82.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zrlXk2ksLzDWxm; Wed, 28 Feb 2018 07:10:14 +0100 (CET) Content-Type: multipart/alternative; boundary=Apple-Mail-70FC9B29-A295-4B45-885F-A8108472AE25 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (15D100) In-Reply-To: <02d801d3b02d$d1f026f0$75d074d0$@augustcellars.com> Date: Wed, 28 Feb 2018 07:10:12 +0100 Cc: cose@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <8D47D59A-D997-495A-A541-73896F6B92AF@tzi.org> <02d801d3b02d$d1f026f0$75d074d0$@augustcellars.com> To: Jim Schaad Archived-At: Subject: Re: [COSE] Digests (hashes) in COSE? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 06:10:59 -0000 --Apple-Mail-70FC9B29-A295-4B45-885F-A8108472AE25 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In the specific case, there would be multiple hashes all under the same algo= rithm id, so the data structure would be pretty trivial... Maybe we just ne= ed the iana considerations for registering hash functions plus some text how= to truncate.=20 Sent from mobile > On 28. Feb 2018, at 01:48, Jim Schaad wrote: >=20 > I need to re-publish my document with hash algorithms, however I am not su= re what needs to be placed in this structure in some ways. >=20 > Is there something beyond >=20 > MAC =3D [ > Digest : bstr, > Algorithm: alg_id > ] >=20 > If you start trying to carry the content you end up with problems because i= t is just as often pointed to. Not sure that putting the pointer in the dig= est computation would make sense as this value often chances as well. >=20 > Are you thinking of something specific that should be part of this? >=20 > I am not sure just how strong the demand is for parametrized hash algorith= ms is. I have used a couple in my lifetime, but always as cases to see what= would happen and have never used one in the wild. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Carsten Bormann >> Sent: Monday, February 26, 2018 9:01 AM >> To: cose@ietf.org >> Subject: [COSE] Digests (hashes) in COSE? >>=20 >> I think that has come up before, but today in the SUIT WG Interim we brie= fly >> discussed a structure where it would be useful to contain multiple unkeye= d >> digests (hashes) in one signed claim (*). In COSE, we have a registry fo= r >> keyed MAC schemes, but not for hashes. We also don=E2=80=99t have a COSE= _Digest >> structure (which would be quite simple, I believe) either (**). >>=20 >> To avoid everyone defining their own way of describing hashes, should we >> be setting this up for COSE? >> We would have to be fast to be relevant for SUIT. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> (*) https://tools.ietf.org/html/draft-moran-suit-manifest-01#section-4 >> (**) maybe a bit like CMS digestedData, but simpler of course >>=20 >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >=20 >=20 >=20 --Apple-Mail-70FC9B29-A295-4B45-885F-A8108472AE25 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable In the specific case, there would be multip= le hashes all under the same algorithm id, so the data structure would be pr= etty trivial...  Maybe we just need the iana considerations for registe= ring hash functions plus some text how to truncate. 

Sent from mobile

On 28. Feb 2018, at 01:48, Jim Schaad <ietf@augustcellars.com> wrote:

I need to re-publish my document wit= h hash algorithms, however I am not sure what needs to be placed in this str= ucture in some ways.

Is there something bey= ond

MAC =3D [
  =  Digest : bstr,
   Algorithm: alg_id
]

If you start trying to carr= y the content you end up with problems because it is just as often pointed t= o.  Not sure that putting the pointer in the digest computation would m= ake sense as this value often chances as well.

Are you thinking of something specific that should be part of this?

I am not sure just how strong the demand is for= parametrized hash algorithms is.  I have used a couple in my lifetime,= but always as cases to see what would happen and have never used one in the= wild.

Jim


-----Original Message-----
From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Ca= rsten Bormann
Sent: M= onday, February 26, 2018 9:01 AM
To: cose@ietf.org
Subject: [COSE] Digests (hashe= s) in COSE?
I think that has come up befo= re, but today in the SUIT WG Interim we briefly
discussed a structure where it would be useful to= contain multiple unkeyed
<= span>digests (hashes) in one signed claim (*).  In COSE, we have a regi= stry for
keyed MAC sc= hemes, but not for hashes.  We also don=E2=80=99t have a COSE_Digest
structure (which would b= e quite simple, I believe) either (**).

T= o avoid everyone defining their own way of describing hashes, should we
be setting this up for CO= SE?
We would have to b= e fast to be relevant for SUIT.

Gr=C3=BC=C3= =9Fe, Carsten
=
(*) https://tools.ietf.o= rg/html/draft-moran-suit-manifest-01#section-4
(**) maybe a bit like CMS digestedData, but si= mpler of course

_________________________= ______________________
COSE mailing list
<= a href=3D"mailto:COSE@ietf.org">COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose



= --Apple-Mail-70FC9B29-A295-4B45-885F-A8108472AE25-- From nobody Tue Feb 27 22:28:52 2018 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 1EDD012DA14 for ; Tue, 27 Feb 2018 22:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7XLrSJhXeM4y for ; Tue, 27 Feb 2018 22:28:47 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D4C12DA26 for ; Tue, 27 Feb 2018 22:28:46 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 27 Feb 2018 22:26:54 -0800 From: Jim Schaad To: 'Carsten Bormann' CC: References: <8D47D59A-D997-495A-A541-73896F6B92AF@tzi.org> <02d801d3b02d$d1f026f0$75d074d0$@augustcellars.com> In-Reply-To: Date: Tue, 27 Feb 2018 22:28:36 -0800 Message-ID: <030101d3b05d$5f2195c0$1d64c140$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0302_01D3B01A.50FF1910" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQEtieayEHTEMkMGEbQjF/dkV8hppgDx+O3qAYmj/oWk8cnCUA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Digests (hashes) in COSE? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 06:28:49 -0000 ------=_NextPart_000_0302_01D3B01A.50FF1910 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For the draft that I originally wrote, the truncated length is part of = the algorithm identifier just like it is with the MAC algorithms. I = will get it republished and make sure that it is ready to go. I can = probably get an AD to pick it up in London. =20 Jim =20 =20 From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Tuesday, February 27, 2018 10:10 PM To: Jim Schaad Cc: cose@ietf.org Subject: Re: [COSE] Digests (hashes) in COSE? =20 In the specific case, there would be multiple hashes all under the same = algorithm id, so the data structure would be pretty trivial... Maybe we = just need the iana considerations for registering hash functions plus = some text how to truncate.=20 Sent from mobile On 28. Feb 2018, at 01:48, Jim Schaad > wrote: I need to re-publish my document with hash algorithms, however I am not = sure what needs to be placed in this structure in some ways. Is there something beyond MAC =3D [ Digest : bstr, Algorithm: alg_id ] If you start trying to carry the content you end up with problems = because it is just as often pointed to. Not sure that putting the = pointer in the digest computation would make sense as this value often = chances as well. Are you thinking of something specific that should be part of this? I am not sure just how strong the demand is for parametrized hash = algorithms is. I have used a couple in my lifetime, but always as cases = to see what would happen and have never used one in the wild. Jim -----Original Message----- From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Monday, February 26, 2018 9:01 AM To: cose@ietf.org =20 Subject: [COSE] Digests (hashes) in COSE? =20 I think that has come up before, but today in the SUIT WG Interim we = briefly discussed a structure where it would be useful to contain multiple = unkeyed digests (hashes) in one signed claim (*). In COSE, we have a registry = for keyed MAC schemes, but not for hashes. We also don=E2=80=99t have a = COSE_Digest structure (which would be quite simple, I believe) either (**). =20 To avoid everyone defining their own way of describing hashes, should we be setting this up for COSE? We would have to be fast to be relevant for SUIT. =20 Gr=C3=BC=C3=9Fe, Carsten =20 (*) https://tools.ietf.org/html/draft-moran-suit-manifest-01#section-4 (**) maybe a bit like CMS digestedData, but simpler of course =20 _______________________________________________ COSE mailing list COSE@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose ------=_NextPart_000_0302_01D3B01A.50FF1910 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

For the = draft that I originally wrote, the truncated length is part of the = algorithm identifier just like it is with the MAC algorithms.=C2=A0 I = will get it republished and make sure that it is ready to go.=C2=A0 I = can probably get an AD to pick it up in London.

 

Jim

 

 

From: = Carsten Bormann [mailto:cabo@tzi.org]
Sent: Tuesday, February = 27, 2018 10:10 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = cose@ietf.org
Subject: Re: [COSE] Digests (hashes) in = COSE?

 

In the specific case, there would be = multiple hashes all under the same algorithm id, so the data structure = would be pretty trivial...  Maybe we just need the iana = considerations for registering hash functions plus some text how to = truncate. 

Sent from mobile


On 28. Feb 2018, at = 01:48, Jim Schaad <ietf@augustcellars.com> = wrote:

I need to re-publish my document with hash algorithms, = however I am not sure what needs to be placed in this structure in some = ways.

Is there something beyond

MAC =3D = [
   Digest : bstr,
   Algorithm: = alg_id
]

If you start trying to carry the content you end up = with problems because it is just as often pointed to.  Not sure = that putting the pointer in the digest computation would make sense as = this value often chances as well.

Are you thinking of something = specific that should be part of this?

I am not sure just how = strong the demand is for parametrized hash algorithms is.  I have = used a couple in my lifetime, but always as cases to see what would = happen and have never used one in the = wild.

Jim



-----Original = Message-----

From: COSE [mailto:cose-bounces@ietf.org] = On Behalf Of Carsten Bormann

Sent: Monday, February 26, 2018 9:01 = AM

To: = cose@ietf.org

Subject: [COSE] Digests (hashes) in = COSE?

 

I = think that has come up before, but today in the SUIT WG Interim we = briefly

discussed a structure where it would be useful to = contain multiple unkeyed

digests (hashes) in one signed claim (*).  In = COSE, we have a registry for

keyed MAC schemes, but not for hashes.  We also = don=E2=80=99t have a COSE_Digest

structure (which would be quite simple, I believe) = either (**).

 

To = avoid everyone defining their own way of describing hashes, should = we

be = setting this up for COSE?

We = would have to be fast to be relevant for = SUIT.

 

Gr=C3=BC=C3=9Fe, = Carsten

 

(*) = https://tools.ietf.org/html/draft-moran-suit-manifest-01#section-4=

(**) = maybe a bit like CMS digestedData, but simpler of = course

 

_______________________________________________

COSE = mailing list

COSE@ietf.org

https://www.ietf.org/= mailman/listinfo/cose



=
------=_NextPart_000_0302_01D3B01A.50FF1910-- From nobody Wed Feb 28 00:24:16 2018 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 BEF0F1243F3 for ; Wed, 28 Feb 2018 00:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 nlcc2MI1NjsL for ; Wed, 28 Feb 2018 00:24:12 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 2BD1B124207 for ; Wed, 28 Feb 2018 00:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w1S8Nsh8016301; Wed, 28 Feb 2018 09:23:54 +0100 (CET) Received: from [100.64.76.226] (ip-109-40-131-130.web.vodafone.de [109.40.131.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zrpVy1svyzDWyy; Wed, 28 Feb 2018 09:23:54 +0100 (CET) Content-Type: multipart/alternative; boundary=Apple-Mail-CA9F7D42-0BD1-4A58-A6AD-52ACA2D8E14D Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (15D100) In-Reply-To: <030101d3b05d$5f2195c0$1d64c140$@augustcellars.com> Date: Wed, 28 Feb 2018 09:23:53 +0100 Cc: cose@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <417F4B81-5EB0-4BED-A81E-5FDB5C31BD2C@tzi.org> References: <8D47D59A-D997-495A-A541-73896F6B92AF@tzi.org> <02d801d3b02d$d1f026f0$75d074d0$@augustcellars.com> <030101d3b05d$5f2195c0$1d64c140$@augustcellars.com> To: Jim Schaad Archived-At: Subject: Re: [COSE] Digests (hashes) in COSE? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 08:24:15 -0000 --Apple-Mail-CA9F7D42-0BD1-4A58-A6AD-52ACA2D8E14D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Right. Consistency with Mac is probably King here, but there is no need to i= ndicate truncation in the algorithm identifier, as the byte string itself al= ready indicates truncation---if there is a consistent way to do this for an a= lgorithm id.=20 Sent from mobile > On 28. Feb 2018, at 07:28, Jim Schaad wrote: >=20 > For the draft that I originally wrote, the truncated length is part of the= algorithm identifier just like it is with the MAC algorithms. I will get i= t republished and make sure that it is ready to go. I can probably get an A= D to pick it up in London. > =20 > Jim > =20 > =20 > From: Carsten Bormann [mailto:cabo@tzi.org]=20 > Sent: Tuesday, February 27, 2018 10:10 PM > To: Jim Schaad > Cc: cose@ietf.org > Subject: Re: [COSE] Digests (hashes) in COSE? > =20 > In the specific case, there would be multiple hashes all under the same al= gorithm id, so the data structure would be pretty trivial... Maybe we just n= eed the iana considerations for registering hash functions plus some text ho= w to truncate.=20 >=20 > Sent from mobile >=20 > On 28. Feb 2018, at 01:48, Jim Schaad wrote: >=20 > I need to re-publish my document with hash algorithms, however I am not su= re what needs to be placed in this structure in some ways. >=20 > Is there something beyond >=20 > MAC =3D [ > Digest : bstr, > Algorithm: alg_id > ] >=20 > If you start trying to carry the content you end up with problems because i= t is just as often pointed to. Not sure that putting the pointer in the dig= est computation would make sense as this value often chances as well. >=20 > Are you thinking of something specific that should be part of this? >=20 > I am not sure just how strong the demand is for parametrized hash algorith= ms is. I have used a couple in my lifetime, but always as cases to see what= would happen and have never used one in the wild. >=20 > Jim >=20 >=20 >=20 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Monday, February 26, 2018 9:01 AM > To: cose@ietf.org > Subject: [COSE] Digests (hashes) in COSE? > =20 > I think that has come up before, but today in the SUIT WG Interim we brief= ly > discussed a structure where it would be useful to contain multiple unkeyed= > digests (hashes) in one signed claim (*). In COSE, we have a registry for= > keyed MAC schemes, but not for hashes. We also don=E2=80=99t have a COSE_= Digest > structure (which would be quite simple, I believe) either (**). > =20 > To avoid everyone defining their own way of describing hashes, should we > be setting this up for COSE? > We would have to be fast to be relevant for SUIT. > =20 > Gr=C3=BC=C3=9Fe, Carsten > =20 > (*) https://tools.ietf.org/html/draft-moran-suit-manifest-01#section-4 > (**) maybe a bit like CMS digestedData, but simpler of course > =20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose >=20 >=20 --Apple-Mail-CA9F7D42-0BD1-4A58-A6AD-52ACA2D8E14D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Right. Consistency with Mac is probably Kin= g here, but there is no need to indicate truncation in the algorithm identif= ier, as the byte string itself already indicates truncation---if there is a c= onsistent way to do this for an algorithm id. 

Sent from mobile<= /div>

On 28. Feb 2018, at 07:28, Jim Schaad <ietf@augustcellars.com> wrote:

For the draft that I originally wrote, the truncated length is part= of the algorithm identifier just like it is with the MAC algorithms.  I= will get it republished and make sure that it is ready to go.  I can p= robably get an AD to pick it up in London.

 

Jim

 

 

From: Carsten Bormann [mailto:cabo@tzi.org]
Sent: Tuesda= y, February 27, 2018 10:10 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: cose@ietf.org
Subject: Re: [COSE] D= igests (hashes) in COSE?

 

In t= he specific case, there would be multiple hashes all under the same algorith= m id, so the data structure would be pretty trivial...  Maybe we just n= eed the iana considerations for registering hash functions plus some text ho= w to truncate. 

Sent from mobile


On 28. Feb 2018, at 01:48, Jim Schaad <ietf@augustcellars.com> wrote:

I need to re-publish my document with hash algorithms, however I am no= t sure what needs to be placed in this structure in some ways.

Is the= re something beyond

MAC =3D [
   Digest : bstr,
=    Algorithm: alg_id
]

If you start trying to carry= the content you end up with problems because it is just as often pointed to= .  Not sure that putting the pointer in the digest computation would ma= ke sense as this value often chances as well.

Are you thinking of som= ething specific that should be part of this?

I am not sure just how s= trong the demand is for parametrized hash algorithms is.  I have used a= couple in my lifetime, but always as cases to see what would happen and hav= e never used one in the wild.

Jim



-----Original Message-----

From: COSE [mailto:cose-bounces@ietf.org] On Be= half Of Carsten Bormann

Sent: Monday, Febru= ary 26, 2018 9:01 AM

To: cose@ietf.org

Subject: [= COSE] Digests (hashes) in COSE?

 =

I think that has come up before, but today in t= he SUIT WG Interim we briefly

discussed a st= ructure where it would be useful to contain multiple unkeyed

<= /blockquote>

digests (hashes) in one signed claim (*).  In COSE, w= e have a registry for

keyed MAC schemes, bu= t not for hashes.  We also don=E2=80=99t have a COSE_Digest<= /p>

<= p class=3D"MsoNormal">structure (which would be quite simple, I believe) eit= her (**).

 

To avoid everyone defining their own way of describing hashes, should= we

be setting this up for COSE?=

=

We would have to be fast to be relevant for SUIT.

 

Gr=C3=BC= =C3=9Fe, Carsten

 

(*) https://tools.ietf.org/html/draft-moran-suit-manifest-01#= section-4

(**) maybe a bit like CMS dig= estedData, but simpler of course

 = ;

______________________________________________= _

COSE mailing list

COSE@ietf.org

<= /blockquote>

htt= ps://www.ietf.org/mailman/listinfo/cose



= --Apple-Mail-CA9F7D42-0BD1-4A58-A6AD-52ACA2D8E14D-- From nobody Wed Feb 28 15:48:05 2018 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 45EDF1270AC for ; Wed, 28 Feb 2018 15:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 UYI26i1Jhfnf for ; Wed, 28 Feb 2018 15:48:02 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69028127058 for ; Wed, 28 Feb 2018 15:48:01 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 28 Feb 2018 15:46:10 -0800 From: Jim Schaad To: 'Carsten Bormann' CC: References: <8D47D59A-D997-495A-A541-73896F6B92AF@tzi.org> <02d801d3b02d$d1f026f0$75d074d0$@augustcellars.com> <030101d3b05d$5f2195c0$1d64c140$@augustcellars.com> <417F4B81-5EB0-4BED-A81E-5FDB5C31BD2C@tzi.org> In-Reply-To: <417F4B81-5EB0-4BED-A81E-5FDB5C31BD2C@tzi.org> Date: Wed, 28 Feb 2018 15:47:51 -0800 Message-ID: <001901d3b0ee$8d8decb0$a8a9c610$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01D3B0AB.7F6D44C0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQEtieayEHTEMkMGEbQjF/dkV8hppgDx+O3qAYmj/oUCLlOVDQD674TOpNmh2nA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Digests (hashes) in COSE? X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 23:48:04 -0000 ------=_NextPart_000_001A_01D3B0AB.7F6D44C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have defined the following: =20 Sha256 Sha256 truncated to 64-bits =20 Are there other algorithms which people believe need to be defined? =20 =20 Jim =20 =20 From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Wednesday, February 28, 2018 12:24 AM To: Jim Schaad Cc: cose@ietf.org Subject: Re: [COSE] Digests (hashes) in COSE? =20 Right. Consistency with Mac is probably King here, but there is no need = to indicate truncation in the algorithm identifier, as the byte string = itself already indicates truncation---if there is a consistent way to do = this for an algorithm id.=20 Sent from mobile On 28. Feb 2018, at 07:28, Jim Schaad > wrote: For the draft that I originally wrote, the truncated length is part of = the algorithm identifier just like it is with the MAC algorithms. I = will get it republished and make sure that it is ready to go. I can = probably get an AD to pick it up in London. =20 Jim =20 =20 From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Tuesday, February 27, 2018 10:10 PM To: Jim Schaad > Cc: cose@ietf.org =20 Subject: Re: [COSE] Digests (hashes) in COSE? =20 In the specific case, there would be multiple hashes all under the same = algorithm id, so the data structure would be pretty trivial... Maybe we = just need the iana considerations for registering hash functions plus = some text how to truncate.=20 Sent from mobile On 28. Feb 2018, at 01:48, Jim Schaad > wrote: I need to re-publish my document with hash algorithms, however I am not = sure what needs to be placed in this structure in some ways. Is there something beyond MAC =3D [ Digest : bstr, Algorithm: alg_id ] If you start trying to carry the content you end up with problems = because it is just as often pointed to. Not sure that putting the = pointer in the digest computation would make sense as this value often = chances as well. Are you thinking of something specific that should be part of this? I am not sure just how strong the demand is for parametrized hash = algorithms is. I have used a couple in my lifetime, but always as cases = to see what would happen and have never used one in the wild. Jim -----Original Message----- From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Monday, February 26, 2018 9:01 AM To: cose@ietf.org =20 Subject: [COSE] Digests (hashes) in COSE? =20 I think that has come up before, but today in the SUIT WG Interim we = briefly discussed a structure where it would be useful to contain multiple = unkeyed digests (hashes) in one signed claim (*). In COSE, we have a registry = for keyed MAC schemes, but not for hashes. We also don=E2=80=99t have a = COSE_Digest structure (which would be quite simple, I believe) either (**). =20 To avoid everyone defining their own way of describing hashes, should we be setting this up for COSE? We would have to be fast to be relevant for SUIT. =20 Gr=C3=BC=C3=9Fe, Carsten =20 (*) https://tools.ietf.org/html/draft-moran-suit-manifest-01#section-4 (**) maybe a bit like CMS digestedData, but simpler of course =20 _______________________________________________ COSE mailing list COSE@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose ------=_NextPart_000_001A_01D3B0AB.7F6D44C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I have = defined the following:

 

Sha256

Sha256 = truncated to 64-bits

 

Are there = other algorithms which people believe need to be defined?=C2=A0 =

 

Jim

 

 

From: = Carsten Bormann [mailto:cabo@tzi.org]
Sent: Wednesday, = February 28, 2018 12:24 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = cose@ietf.org
Subject: Re: [COSE] Digests (hashes) in = COSE?

 

Right. Consistency with Mac is probably = King here, but there is no need to indicate truncation in the algorithm = identifier, as the byte string itself already indicates truncation---if = there is a consistent way to do this for an algorithm = id. 

Sent from mobile


On 28. Feb 2018, at = 07:28, Jim Schaad <ietf@augustcellars.com> = wrote:

For the draft that I originally wrote, the truncated = length is part of the algorithm identifier just like it is with the MAC = algorithms.  I will get it republished and make sure that it is = ready to go.  I can probably get an AD to pick it up in = London.

 

Jim

 

 

From: = Carsten Bormann [mailto:cabo@tzi.org]
Sent: = Tuesday, February 27, 2018 10:10 PM
To: Jim Schaad <ietf@augustcellars.com>
= Cc: cose@ietf.org
Subject: Re: = [COSE] Digests (hashes) in COSE?

 

In the specific case, there would be = multiple hashes all under the same algorithm id, so the data structure = would be pretty trivial...  Maybe we just need the iana = considerations for registering hash functions plus some text how to = truncate. 

Sent from mobile


On 28. Feb 2018, at = 01:48, Jim Schaad <ietf@augustcellars.com> = wrote:

I need to re-publish my document with hash algorithms, = however I am not sure what needs to be placed in this structure in some = ways.

Is there something beyond

MAC =3D = [
   Digest : bstr,
   Algorithm: = alg_id
]

If you start trying to carry the content you end up = with problems because it is just as often pointed to.  Not sure = that putting the pointer in the digest computation would make sense as = this value often chances as well.

Are you thinking of something = specific that should be part of this?

I am not sure just how = strong the demand is for parametrized hash algorithms is.  I have = used a couple in my lifetime, but always as cases to see what would = happen and have never used one in the = wild.

Jim




-----Original = Message-----

From: COSE [mailto:cose-bounces@ietf.org] = On Behalf Of Carsten Bormann

Sent: Monday, February 26, 2018 9:01 = AM

To: = cose@ietf.org

Subject: [COSE] Digests (hashes) in = COSE?

 

I = think that has come up before, but today in the SUIT WG Interim we = briefly

discussed a structure where it would be useful to = contain multiple unkeyed

digests (hashes) in one signed claim (*).  In = COSE, we have a registry for

keyed MAC schemes, but not for hashes.  We also = don=E2=80=99t have a COSE_Digest

structure (which would be quite simple, I believe) = either (**).

 

To = avoid everyone defining their own way of describing hashes, should = we

be = setting this up for COSE?

We = would have to be fast to be relevant for = SUIT.

 

Gr=C3=BC=C3=9Fe, = Carsten

 

(*) = https://tools.ietf.org/html/draft-moran-suit-manifest-01#section-4=

(**) = maybe a bit like CMS digestedData, but simpler of = course

 

_______________________________________________

COSE = mailing list

COSE@ietf.org

https://www.ietf.org/= mailman/listinfo/cose




------=_NextPart_000_001A_01D3B0AB.7F6D44C0--