From nobody Mon Jun 1 06:25:54 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 272973A1030; Mon, 1 Jun 2020 06:25:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-cose-hash-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov , ivaylo@ackl.io X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <159101794967.27986.902730371235702504@ietfa.amsl.com> Date: Mon, 01 Jun 2020 06:25:50 -0700 Archived-At: Subject: [COSE] Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 13:25:50 -0000 Warren Kumari has entered the following ballot position for draft-ietf-cose-hash-algs-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for writing this - it was an interesting read. I do have one issue, which I cannot tell if it is simply me being dumb, or if the text needs more work. “ Doing indirect signing allows for a signature to be validated without first downloading all of the content associated with the signature. This capability can be of even greater importance in a constrained environment as not all of the content signed may be needed by the device.” I’m unclear how this works — itseems clear enough that I can verify that the signature matches the hash, but doesn’t the device need to still download and compute the hash over all of the content? Otherwise I could take a hash and signature from content A, and claim that it is for content B. Sure, if the signature **doens’t** match the hash I know not to bother downloading the content at all, but if the sig does match the hash I still need to download the content to check that the hash is for this content.... Please help educate me! Nit: “ A pointer to the value that was hashed. this could” — s/this/This/ From nobody Mon Jun 1 12:53:24 2020 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 A98BD3A1506; Mon, 1 Jun 2020 12:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 jRJ_5jr1mqR7; Mon, 1 Jun 2020 12:53:15 -0700 (PDT) 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 3F4883A1505; Mon, 1 Jun 2020 12:53:15 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 1 Jun 2020 12:52:49 -0700 From: Jim Schaad To: 'Warren Kumari' , 'The IESG' CC: , , , 'Ivaylo Petrov' References: <159101794967.27986.902730371235702504@ietfa.amsl.com> In-Reply-To: <159101794967.27986.902730371235702504@ietfa.amsl.com> Date: Mon, 1 Jun 2020 12:52:46 -0700 Message-ID: <000001d6384e$3b3ac480$b1b04d80$@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: AQJYrmFvmPG4f4/C370RnJaaHX1oRae/IJxQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 19:53:18 -0000 -----Original Message----- From: Warren Kumari via Datatracker =20 Sent: Monday, June 1, 2020 6:26 AM To: The IESG Cc: draft-ietf-cose-hash-algs@ietf.org; cose-chairs@ietf.org; = cose@ietf.org; Ivaylo Petrov ; ivaylo@ackl.io Subject: Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04: = (with COMMENT) Warren Kumari has entered the following ballot position for draft-ietf-cose-hash-algs-04: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for writing this - it was an interesting read. I do have one issue, which I cannot tell if it is simply me being dumb, = or if the text needs more work. =E2=80=9C Doing indirect signing allows for a signature to be validated = without first downloading all of the content associated with the = signature. This capability can be of even greater importance in a constrained environment as not = all of=20 the content signed may be needed by the device.=E2=80=9D I=E2=80=99m unclear how this works =E2=80=94 itseems clear enough that = I can verify that the signature matches the hash, but doesn=E2=80=99t = the device need to still download and compute the hash over all of the = content? Otherwise I could take a hash and signature from content A, and claim = that it is for content B. Sure, if the signature **doens=E2=80=99t** = match the hash I know not to bother downloading the content at all, but = if the sig does match the hash I still need to download the content to = check that the hash is for this content.... Please help educate me! [JLS] I am more than willing to help educate. You are going to be = seeing some of this from the SUIT people as well. For a firmware type = update you might defined a structure that looks like: FirmwareBlock =3D Array of ( Text description of block Hardware target Version number URL to the bytes of the update Hash algorithm identifier Hash of the bytes of the update A message containing an array of these blocks is created, a COSE signed = message is then created containing this array of blocks as the content = of the message and sent to the piece of hardware. The hardware can then validate the signed message, walk the array of = blocks, if the block applies download the bytes pointed to by the URL, = hash the bytes downloaded and compare the hash values. If the hash = values match then the bytes can be applied to the device. This allows a = device to only download the bytes that are needed, ignoring those which = have either already been applied or which are not relevant to the = device. This is what I call an indirect signature, the block of data pointed to = by the URL is not part of the message is implicitly signed since the = hash of the data block is signed rather than the actual data. It is = interesting to note that this is the way that CMS has always worked, the = hash of the message is placed in an array of attributes and that array = of attributes is what is signed by the signature algorithm.=20 Nit: =E2=80=9C A pointer to the value that was hashed. this = could=E2=80=9D =E2=80=94 s/this/This/ [JLS] Fixed. From nobody Mon Jun 1 13:15:10 2020 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 CABA63A152E; Mon, 1 Jun 2020 13:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 MuNv9ggdgyKV; Mon, 1 Jun 2020 13:15:06 -0700 (PDT) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) (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 3F8DB3A152D; Mon, 1 Jun 2020 13:15:06 -0700 (PDT) Received: by mail-io1-f66.google.com with SMTP id s18so8376169ioe.2; Mon, 01 Jun 2020 13:15:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DSHuQZxKOOnnKnf0hYwbcus9E8Gn9WIOWzyeUpSOAdw=; b=PC7AgQYlG2jevYCnZ2Q9NnwUn8JEgjBaKp+rsHj/cnE4dO++vSehEPJHekK00NeVi/ UTgoXDt9HWRjAU8hv9PsuDLyfXvfv/8KBav3WmODXUopNir/8qOd97nyMjUKGNseBBIo YH1V6v3IHLD6qhaMXHDYL6z4pAadCHGMLnzQxURsirx3qyT2rhQ+DyKm41ewLAeWESW1 HUWaK1H4KEocFlPp+kSM7RMLqhY2aRMV3T0XYdiF1Hkrtx4KCg2ZTAd1LhkEawvMGMDj ojFvuE40yLdGrTnCNDVoslzmvg3IJF1kIcWLQum2BO13yuYcjPqYEuVOGmff69Lryc6Q E40A== X-Gm-Message-State: AOAM5334ih2k6NmPu58z67M3RGkxJOZ6MoSMfiHdM2wbi14tOV6dJgMX 9si6/iUb12p+e33d0S4CKHNivXvbxUgI2MmM+V4= X-Google-Smtp-Source: ABdhPJyi9GBnJSpomEU/GvF7AtHDq3RxIw8ZTbv3Dddikm2eEJ7MsqP/gCCEnFbcPkNZjFtGlmzu75zu08go9nm2rwU= X-Received: by 2002:a02:cd89:: with SMTP id l9mr21878209jap.88.1591042504940; Mon, 01 Jun 2020 13:15:04 -0700 (PDT) MIME-Version: 1.0 References: <159101794967.27986.902730371235702504@ietfa.amsl.com> <000001d6384e$3b3ac480$b1b04d80$@augustcellars.com> In-Reply-To: <000001d6384e$3b3ac480$b1b04d80$@augustcellars.com> From: Barry Leiba Date: Mon, 1 Jun 2020 16:14:53 -0400 Message-ID: To: Jim Schaad Cc: Warren Kumari , The IESG , Ivaylo Petrov , cose-chairs@ietf.org, draft-ietf-cose-hash-algs@ietf.org, cose@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [COSE] Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 20:15:08 -0000 Put another way, I think that Warren is asking if a bad actor can trick you into downloading something anyway, and only after to wasted the download will you find out that you shouldn't have bothered. The answer to that is, "Sure." The point here is that the download can be saved most of the time, during normal operation. And the signature protects against the abnormal situations (such as someone trying to spoof an update). Nothing is perfect, but the combination is beneficial. Barry On Mon, Jun 1, 2020 at 3:53 PM Jim Schaad wrote: > > > > -----Original Message----- > From: Warren Kumari via Datatracker > Sent: Monday, June 1, 2020 6:26 AM > To: The IESG > Cc: draft-ietf-cose-hash-algs@ietf.org; cose-chairs@ietf.org; cose@ietf.o= rg; Ivaylo Petrov ; ivaylo@ackl.io > Subject: Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04: (w= ith COMMENT) > > Warren Kumari has entered the following ballot position for > draft-ietf-cose-hash-algs-04: No Objection > > When responding, please keep the subject line intact and reply to all ema= il addresses included in the To and CC lines. (Feel free to cut this introd= uctory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for writing this - it was an interesting read. > > I do have one issue, which I cannot tell if it is simply me being dumb, o= r if the text needs more work. > > =E2=80=9C Doing indirect signing allows for a signature to be validated w= ithout first downloading all of the content associated with the signature.= This capability > can be of even greater importance in a constrained environment as not a= ll of > the content signed may be needed by the device.=E2=80=9D > > I=E2=80=99m unclear how this works =E2=80=94 itseems clear enough that I= can verify that the signature matches the hash, but doesn=E2=80=99t the de= vice need to still download and compute the hash over all of the content? > > Otherwise I could take a hash and signature from content A, and claim tha= t it is for content B. Sure, if the signature **doens=E2=80=99t** match the= hash I know not to bother downloading the content at all, but if the sig d= oes match the hash I still need to download the content to check that the h= ash is for this content.... > > Please help educate me! > > [JLS] I am more than willing to help educate. You are going to be seeing= some of this from the SUIT people as well. For a firmware type update you= might defined a structure that looks like: > FirmwareBlock =3D Array of ( > Text description of block > Hardware target > Version number > URL to the bytes of the update > Hash algorithm identifier > Hash of the bytes of the update > > A message containing an array of these blocks is created, a COSE signed m= essage is then created containing this array of blocks as the content of th= e message and sent to the piece of hardware. > > The hardware can then validate the signed message, walk the array of bloc= ks, if the block applies download the bytes pointed to by the URL, hash the= bytes downloaded and compare the hash values. If the hash values match th= en the bytes can be applied to the device. This allows a device to only do= wnload the bytes that are needed, ignoring those which have either already = been applied or which are not relevant to the device. > > This is what I call an indirect signature, the block of data pointed to b= y the URL is not part of the message is implicitly signed since the hash of= the data block is signed rather than the actual data. It is interesting t= o note that this is the way that CMS has always worked, the hash of the mes= sage is placed in an array of attributes and that array of attributes is wh= at is signed by the signature algorithm. > > Nit: =E2=80=9C A pointer to the value that was hashed. this could=E2=80= =9D =E2=80=94 s/this/This/ > > [JLS] Fixed. > > > From nobody Mon Jun 1 15:26:23 2020 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 1DF093A15EE; Mon, 1 Jun 2020 15:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 KDgyEPU_UfTr; Mon, 1 Jun 2020 15:26:20 -0700 (PDT) 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 EAD343A15EC; Mon, 1 Jun 2020 15:26:19 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 1 Jun 2020 15:26:13 -0700 From: Jim Schaad To: 'Barry Leiba' CC: 'Warren Kumari' , 'The IESG' , 'Ivaylo Petrov' , , , References: <159101794967.27986.902730371235702504@ietfa.amsl.com> <000001d6384e$3b3ac480$b1b04d80$@augustcellars.com> In-Reply-To: Date: Mon, 1 Jun 2020 15:26:10 -0700 Message-ID: <000801d63863$a8ee0fe0$faca2fa0$@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: AQJYrmFvmPG4f4/C370RnJaaHX1oRQNhwyvSAemdhXynlQ7a0A== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 22:26:22 -0000 Not quite. A bad actor can get you to download something that does not = match what you are after, but only after you have validated the original = message. Nothing stops a bad actor from trying to trigger you to start = with a new base message. Jim -----Original Message----- From: Barry Leiba =20 Sent: Monday, June 1, 2020 1:15 PM To: Jim Schaad Cc: Warren Kumari ; The IESG ; Ivaylo = Petrov ; cose-chairs@ietf.org; = draft-ietf-cose-hash-algs@ietf.org; cose@ietf.org Subject: Re: Warren Kumari's No Objection on = draft-ietf-cose-hash-algs-04: (with COMMENT) Put another way, I think that Warren is asking if a bad actor can trick = you into downloading something anyway, and only after to wasted the = download will you find out that you shouldn't have bothered. The answer = to that is, "Sure." The point here is that the download can be saved = most of the time, during normal operation. And the signature protects = against the abnormal situations (such as someone trying to spoof an = update). Nothing is perfect, but the combination is beneficial. Barry On Mon, Jun 1, 2020 at 3:53 PM Jim Schaad = wrote: > > > > -----Original Message----- > From: Warren Kumari via Datatracker > Sent: Monday, June 1, 2020 6:26 AM > To: The IESG > Cc: draft-ietf-cose-hash-algs@ietf.org; cose-chairs@ietf.org;=20 > cose@ietf.org; Ivaylo Petrov ; ivaylo@ackl.io > Subject: Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04: = > (with COMMENT) > > Warren Kumari has entered the following ballot position for > draft-ietf-cose-hash-algs-04: No Objection > > When responding, please keep the subject line intact and reply to all=20 > email addresses included in the To and CC lines. (Feel free to cut=20 > this introductory paragraph, however.) > > > Please refer to=20 > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for writing this - it was an interesting read. > > I do have one issue, which I cannot tell if it is simply me being = dumb, or if the text needs more work. > > =E2=80=9C Doing indirect signing allows for a signature to be = validated without first downloading all of the content associated with = the signature. This capability > can be of even greater importance in a constrained environment as = not all of > the content signed may be needed by the device.=E2=80=9D > > I=E2=80=99m unclear how this works =E2=80=94 itseems clear enough = that I can verify that the signature matches the hash, but = doesn=E2=80=99t the device need to still download and compute the hash = over all of the content? > > Otherwise I could take a hash and signature from content A, and claim = that it is for content B. Sure, if the signature **doens=E2=80=99t** = match the hash I know not to bother downloading the content at all, but = if the sig does match the hash I still need to download the content to = check that the hash is for this content.... > > Please help educate me! > > [JLS] I am more than willing to help educate. You are going to be = seeing some of this from the SUIT people as well. For a firmware type = update you might defined a structure that looks like: > FirmwareBlock =3D Array of ( > Text description of block > Hardware target > Version number > URL to the bytes of the update > Hash algorithm identifier > Hash of the bytes of the update > > A message containing an array of these blocks is created, a COSE = signed message is then created containing this array of blocks as the = content of the message and sent to the piece of hardware. > > The hardware can then validate the signed message, walk the array of = blocks, if the block applies download the bytes pointed to by the URL, = hash the bytes downloaded and compare the hash values. If the hash = values match then the bytes can be applied to the device. This allows a = device to only download the bytes that are needed, ignoring those which = have either already been applied or which are not relevant to the = device. > > This is what I call an indirect signature, the block of data pointed = to by the URL is not part of the message is implicitly signed since the = hash of the data block is signed rather than the actual data. It is = interesting to note that this is the way that CMS has always worked, the = hash of the message is placed in an array of attributes and that array = of attributes is what is signed by the signature algorithm. > > Nit: =E2=80=9C A pointer to the value that was hashed. this = could=E2=80=9D =E2=80=94=20 > s/this/This/ > > [JLS] Fixed. > > > From nobody Mon Jun 1 21:33:17 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB3B3A02C1; Mon, 1 Jun 2020 21:33:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-cose-hash-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov , ivaylo@ackl.io X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <159107239537.28693.16065000145824637198@ietfa.amsl.com> Date: Mon, 01 Jun 2020 21:33:15 -0700 Archived-At: Subject: [COSE] Barry Leiba's Yes on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 04:33:16 -0000 Barry Leiba has entered the following ballot position for draft-ietf-cose-hash-algs-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- — Abstract — There are however circumstances where hash algorithms are used, such as indirect signatures where the hash of one or more contents are signed, and X.509 certificate or other object identification by the use of a fingerprint. I found this hard to parse, and had to read it a few times. How about this?: NEW There are, however, circumstances where hash algorithms are used, such as in indirect signatures, where the hash of some content is signed, and for fingerprinting of X.509 certificates or other objects. END — Introduction — This omission was intentional as a structure consisting of just a digest identifier, the content, and a digest value does not by itself provide any strong security service. Nit: this needs a few more commas... one after “intentional”, and one before and one after “by itself”. One of the primary things that has been identified by a hash function for secure message is a certificate. Another that I had trouble parsing. Maybe, “One of the primary things related to secure messages that has been identified by a hash function is a certificate.” — Section 2 — hash functions is part of the base design as cryptographic advances are sure to reduce the strength of a hash function. Nit: this needs a comma after “design”. The standard "Collision Attack" is one where an attacker can find two different messages that have the same hash value. If a collision attack exists, then the function SHOULD NOT be used for a cryptographic purpose. I’m uncomfortable with having this document give a brief tutorial on cryptographic hashing, as it has to be oversimplified... and it is. If it’s going to stay, I’d like to see ar least one minor change, though I’ll defer to the Sec ADs on this point: for any hash alg, it is always possible to encounter a collision, and the text isn’t clear about what “if a collision attack exists” really means. I think it means not to use it if a collision attack is practical, and maybe this is a better way to say it?: NEW A "collision attack" is one where an attacker can find two different messages that have the same hash value. A hash function that is susceptible to collision attacks, SHOULD NOT be used for cryptographic purposes. END checked to see if they are the correct one. “They are the correct one?” Oof. How about, “to find the correct one,” or (maybe better), “to see if they are suitable.”? If the fingerprint is used to verify that it is the correct certificate, then that usage is subject to a collision attack as above. If however, the fingerprint is used to sort through a collection of certificates “then that usage is a cryptographic one and is subject to the warning above about collision attacks.” And “however” also needs a comma before it, as well as after. In this case, one still needs to validate that the public key validates the signature Make the first “validate” say “confirm” instead, to avoid the awkward double use of “validate”. To distinguish between these two cases, a new value in the recommended column of the COSE Algorithms registry is to be added. "Filter Only" indicates that the only purpose of a hash function should be to filter results and not those which require collision resistance. Might it be better to have the new column be called “cryptographic use”, with values of “yes” and “no”? Hint: I think it would. Hint#2: this is a non-blocking comment, so you might disagree. — Section 2.1 — * Additional data, this can be something as simple as a random value Nit: make the comma a semicolon. appending to the content, but it is strongly suggested to it Nit: change “to it” to “that it”. — Section 3.1 — Because of the known issues for SHA-1 and the fact that is should no Nit: change “that is” to “that it”. — Section 3.2 — Locations that use this hash function need either to analysis the potential problems with having a collision occur, or where the only function of the hash is to narrow the possible choices. Locations? And do you mean to use “analysis” as a verb? Maybe this?: NEW Use of this hash function needs analysis of the potential problems with having a collision occur, or must be limited to where the function of the hash is non-cryptographic. END — Section 3.3 — One of the benefits of this differences is that when computing a shorter SHAKE hash value Nit: “difference”, singular. — Section 5 — that need the cryptographic properties, i.e. collision resistance, and properties that correspond to possible object identification. Collision resistance isn’t the only cryptographic property (there’s also, for example, preimage resistance), so change “i.e.” to “such as”. This is another example of the hazard of trying to explain hashing in a simple document such as this one. This is the difference between collision resistance and second pre-image resistance. If you have collision resistance, don’t you automatically have second preimage resistance? What’s he point of mentioning second preimage resistance here, when you don’t mention it nor need it anywhere else? are under constant attack and the strength of hash algorithms will be reduced over time. I would say “the cryptographic strength”. From nobody Tue Jun 2 06:53:13 2020 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 F41A23A09AE for ; Tue, 2 Jun 2020 06:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 T7XFx2e1Kazm for ; Tue, 2 Jun 2020 06:53:07 -0700 (PDT) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 162F93A09BD for ; Tue, 2 Jun 2020 06:53:07 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id d7so6187689lfi.12 for ; Tue, 02 Jun 2020 06:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NvXPrM3MSioEVr8AEzjPPHmG5nJ/sVH/Rpn63yPj+Oc=; b=xkkfkJxu+kEaS94grXi5CQiYFpWr6e4Ur9FasFQnfar17vSLmyF8LmMOGML5DRGHOJ pr6TmUXyqqYuIcHAVxB/VCi3+f99r6zRevaEU7hVQk+gROCG5B28Uds5gKJea74gHW/t WUrh60uqfwpIG/AYBUs8vxHo+II2fQiuZnv4PWNZoB4A2oNVg3TyWw0yGqjGLn5u9J0s GAlodCOLy1KkmQe+bRP+7w2EdBI4BnfGNqk24Zgx6ImYovkvAxxAuTg6ewFK4D0kooOI JLVLir8avrpzB3qgDf1YeFdTxxr+D7T7q4red3aJfrSauTvltE/IZBev6lV0LGNdzNo1 L1ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NvXPrM3MSioEVr8AEzjPPHmG5nJ/sVH/Rpn63yPj+Oc=; b=dc01TRuYDUibSnp7SWeOPS35pPofY5AIOuxIwjBq19MfVBKcHGr6mx/LQjEFe2pvLp WEKJNjdSsaRHHTETCZvbyu+ZCeoVoHM7aGPncZuXe1Na3AWh+PCUiVCIyFjvL0h764+K Kwm9PnVrFhhhBSr5zfjDPbl36T3fVOlUC4zBejIr6rTA5uyw21hrn92fMAq8LIhBnmp3 zO2ijPVyYqwB3pkNT86rHT+mZ9cV0YlPK71QiZnwU33OtyxCnGQTPm8277i4bcndoFpy zbovqUUNZrDXw5rfNV3aBQvxhueDYXBc+KiTuJAYml8cAinb5KHGwUbbCVfpo2MExKQc HqFw== X-Gm-Message-State: AOAM532kVmQR20ebTh8Aya1aYcezjf3Un9xvzMkG6jE9dR7Z8UMKHU/q 2YS4j1seggDhww3s98rBKmPfqy96oFGLi7uWfgeXaeym2UgYFg== X-Google-Smtp-Source: ABdhPJxfkvQ2wqGkKo5M0eY51689q6+ol1O87xcr2KoNOdD8i4eOePyrm4ai2sJPVg0doFMS+IMdZ4diomm1osBZGvo= X-Received: by 2002:a19:987:: with SMTP id 129mr14145346lfj.8.1591105984869; Tue, 02 Jun 2020 06:53:04 -0700 (PDT) MIME-Version: 1.0 References: <159101794967.27986.902730371235702504@ietfa.amsl.com> <000001d6384e$3b3ac480$b1b04d80$@augustcellars.com> In-Reply-To: From: Warren Kumari Date: Tue, 2 Jun 2020 09:52:28 -0400 Message-ID: To: Barry Leiba Cc: Jim Schaad , The IESG , Ivaylo Petrov , cose-chairs@ietf.org, draft-ietf-cose-hash-algs@ietf.org, cose@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [COSE] Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 13:53:09 -0000 On Mon, Jun 1, 2020 at 4:15 PM Barry Leiba wrote: > > Put another way, I think that Warren is asking if a bad actor can > trick you into downloading something anyway, and only after to wasted > the download will you find out that you shouldn't have bothered. Nah, not quite -- "Doing indirect signing allows for a signature to be validated without first downloading all of the content associated with the signature. This capabil= ity can be of even greater importance in a constrained environment as not all = of the content signed may be needed by the device." Sorry, I'm still not getting it I can see a signature over something like a manifest, listing all of the "things" (firmware blocks, files, whatever). I can download this, and validate the signature, and know that the manifest came from the e.g device manufacturer. I can then look through and find the thing (let's pretend it's a URL to a firmware update), go fetch that, hash it and then check that the "Hash of the bytes of the update" match what was in the manifest. But, in both of these cases, I have to download the entire thing that is signed or hashed (first the manifest, and all of the bytes of the update *for my device type*). In another example, if this were a book, if I only cared about the chapter about doughnuts, I would check the index (and signature over the index), and then go hash the chapter that the index points to, and make sure that it matches -- but, I've still had to a: check the signature on the index (which requires the entire index) and b: hash the entire doughnuts chapter (which means I need the entire doughnuts chapter). Yes, I don't need to hash the chapter on macarons or Mille feuilles, but I'm still having to download / hash the content associated with the signature... Or, is this just saying that the index contains hashes for the individual blocks (chapters), and so I just need to download the entire index and check the signature, and then the block(s) that I care about (and that the hashes match what is in the index)? I'm really not trying to be difficult, I'm just confused... W > The > answer to that is, "Sure." The point here is that the download can be > saved most of the time, during normal operation. And the signature > protects against the abnormal situations (such as someone trying to > spoof an update). Nothing is perfect, but the combination is > beneficial. > > Barry > > On Mon, Jun 1, 2020 at 3:53 PM Jim Schaad wrote: > > > > > > > > -----Original Message----- > > From: Warren Kumari via Datatracker > > Sent: Monday, June 1, 2020 6:26 AM > > To: The IESG > > Cc: draft-ietf-cose-hash-algs@ietf.org; cose-chairs@ietf.org; cose@ietf= .org; Ivaylo Petrov ; ivaylo@ackl.io > > Subject: Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04: = (with COMMENT) > > > > Warren Kumari has entered the following ballot position for > > draft-ietf-cose-hash-algs-04: No Objection > > > > When responding, please keep the subject line intact and reply to all e= mail addresses included in the To and CC lines. (Feel free to cut this intr= oductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you for writing this - it was an interesting read. > > > > I do have one issue, which I cannot tell if it is simply me being dumb,= or if the text needs more work. > > > > =E2=80=9C Doing indirect signing allows for a signature to be validated= without first downloading all of the content associated with the signatur= e. This capability > > can be of even greater importance in a constrained environment as not= all of > > the content signed may be needed by the device.=E2=80=9D > > > > I=E2=80=99m unclear how this works =E2=80=94 itseems clear enough that= I can verify that the signature matches the hash, but doesn=E2=80=99t the = device need to still download and compute the hash over all of the content? > > > > Otherwise I could take a hash and signature from content A, and claim t= hat it is for content B. Sure, if the signature **doens=E2=80=99t** match t= he hash I know not to bother downloading the content at all, but if the sig= does match the hash I still need to download the content to check that the= hash is for this content.... > > > > Please help educate me! > > > > [JLS] I am more than willing to help educate. You are going to be seei= ng some of this from the SUIT people as well. For a firmware type update y= ou might defined a structure that looks like: > > FirmwareBlock =3D Array of ( > > Text description of block > > Hardware target > > Version number > > URL to the bytes of the update > > Hash algorithm identifier > > Hash of the bytes of the update > > > > A message containing an array of these blocks is created, a COSE signed= message is then created containing this array of blocks as the content of = the message and sent to the piece of hardware. > > > > The hardware can then validate the signed message, walk the array of bl= ocks, if the block applies download the bytes pointed to by the URL, hash t= he bytes downloaded and compare the hash values. If the hash values match = then the bytes can be applied to the device. This allows a device to only = download the bytes that are needed, ignoring those which have either alread= y been applied or which are not relevant to the device. > > > > This is what I call an indirect signature, the block of data pointed to= by the URL is not part of the message is implicitly signed since the hash = of the data block is signed rather than the actual data. It is interesting= to note that this is the way that CMS has always worked, the hash of the m= essage is placed in an array of attributes and that array of attributes is = what is signed by the signature algorithm. > > > > Nit: =E2=80=9C A pointer to the value that was hashed. this could=E2= =80=9D =E2=80=94 s/this/This/ > > > > [JLS] Fixed. > > > > > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Jun 2 10:59:35 2020 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 1435B3A0E10; Tue, 2 Jun 2020 10:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 agyPvOdFWwk0; Tue, 2 Jun 2020 10:59:27 -0700 (PDT) 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 CC3323A0E4F; Tue, 2 Jun 2020 10:59:22 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 2 Jun 2020 10:58:57 -0700 From: Jim Schaad To: 'Warren Kumari' , 'Barry Leiba' CC: 'The IESG' , 'Ivaylo Petrov' , , , References: <159101794967.27986.902730371235702504@ietfa.amsl.com> <000001d6384e$3b3ac480$b1b04d80$@augustcellars.com> In-Reply-To: Date: Tue, 2 Jun 2020 10:58:54 -0700 Message-ID: <005c01d63907$7d7bfbc0$7873f340$@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: AQJYrmFvmPG4f4/C370RnJaaHX1oRQNhwyvSAemdhXwCVvVXC6eDnpzQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 17:59:29 -0000 -----Original Message----- From: Warren Kumari =20 Sent: Tuesday, June 2, 2020 6:52 AM To: Barry Leiba Cc: Jim Schaad ; The IESG ; = Ivaylo Petrov ; cose-chairs@ietf.org; = draft-ietf-cose-hash-algs@ietf.org; cose@ietf.org Subject: Re: Warren Kumari's No Objection on = draft-ietf-cose-hash-algs-04: (with COMMENT) On Mon, Jun 1, 2020 at 4:15 PM Barry Leiba = wrote: > > Put another way, I think that Warren is asking if a bad actor can=20 > trick you into downloading something anyway, and only after to wasted=20 > the download will you find out that you shouldn't have bothered. Nah, not quite -- "Doing indirect signing allows for a signature to be = validated without first downloading all of the content associated with = the signature. This capability can be of even greater importance in a = constrained environment as not all of the content signed may be needed = by the device." Sorry, I'm still not getting it I can see a signature over something like a manifest, listing all of the = "things" (firmware blocks, files, whatever). I can download this, and = validate the signature, and know that the manifest came from the e.g = device manufacturer. I can then look through and find the thing (let's = pretend it's a URL to a firmware update), go fetch that, hash it and = then check that the "Hash of the bytes of the update" match what was in = the manifest. But, in both of these cases, I have to download the entire thing that is = signed or hashed (first the manifest, and all of the bytes of the update = *for my device type*). In another example, if this were a book, if I only cared about the = chapter about doughnuts, I would check the index (and signature over the = index), and then go hash the chapter that the index points to, and make = sure that it matches -- but, I've still had to a: check the signature on = the index (which requires the entire index) and b: hash the entire = doughnuts chapter (which means I need the entire doughnuts chapter). = Yes, I don't need to hash the chapter on macarons or Mille feuilles, but = I'm still having to download / hash the content associated with the = signature... Or, is this just saying that the index contains hashes for the = individual blocks (chapters), and so I just need to download the entire = index and check the signature, and then the block(s) that I care about = (and that the hashes match what is in the index)? [JLS] This is the case, all we have is an index that contains the hashes = of the individual blocks. You only need to download what you care = about. Thus you don't need to download the chapter on macarons, even = though you have the pointer and hash of that data. If you later become = interested in macarons you can down load that chapter and check that it = has the correct hash. Jim I'm really not trying to be difficult, I'm just confused... W > The > answer to that is, "Sure." The point here is that the download can be = > saved most of the time, during normal operation. And the signature=20 > protects against the abnormal situations (such as someone trying to=20 > spoof an update). Nothing is perfect, but the combination is=20 > beneficial. > > Barry > > On Mon, Jun 1, 2020 at 3:53 PM Jim Schaad = wrote: > > > > > > > > -----Original Message----- > > From: Warren Kumari via Datatracker > > Sent: Monday, June 1, 2020 6:26 AM > > To: The IESG > > Cc: draft-ietf-cose-hash-algs@ietf.org; cose-chairs@ietf.org;=20 > > cose@ietf.org; Ivaylo Petrov ; ivaylo@ackl.io > > Subject: Warren Kumari's No Objection on=20 > > draft-ietf-cose-hash-algs-04: (with COMMENT) > > > > Warren Kumari has entered the following ballot position for > > draft-ietf-cose-hash-algs-04: No Objection > > > > When responding, please keep the subject line intact and reply to=20 > > all email addresses included in the To and CC lines. (Feel free to=20 > > cut this introductory paragraph, however.) > > > > > > Please refer to=20 > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ > > > > > > > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > Thank you for writing this - it was an interesting read. > > > > I do have one issue, which I cannot tell if it is simply me being = dumb, or if the text needs more work. > > > > =E2=80=9C Doing indirect signing allows for a signature to be = validated without first downloading all of the content associated with = the signature. This capability > > can be of even greater importance in a constrained environment as = not all of > > the content signed may be needed by the device.=E2=80=9D > > > > I=E2=80=99m unclear how this works =E2=80=94 itseems clear enough = that I can verify that the signature matches the hash, but = doesn=E2=80=99t the device need to still download and compute the hash = over all of the content? > > > > Otherwise I could take a hash and signature from content A, and = claim that it is for content B. Sure, if the signature = **doens=E2=80=99t** match the hash I know not to bother downloading the = content at all, but if the sig does match the hash I still need to = download the content to check that the hash is for this content.... > > > > Please help educate me! > > > > [JLS] I am more than willing to help educate. You are going to be = seeing some of this from the SUIT people as well. For a firmware type = update you might defined a structure that looks like: > > FirmwareBlock =3D Array of ( > > Text description of block > > Hardware target > > Version number > > URL to the bytes of the update > > Hash algorithm identifier > > Hash of the bytes of the update > > > > A message containing an array of these blocks is created, a COSE = signed message is then created containing this array of blocks as the = content of the message and sent to the piece of hardware. > > > > The hardware can then validate the signed message, walk the array of = blocks, if the block applies download the bytes pointed to by the URL, = hash the bytes downloaded and compare the hash values. If the hash = values match then the bytes can be applied to the device. This allows a = device to only download the bytes that are needed, ignoring those which = have either already been applied or which are not relevant to the = device. > > > > This is what I call an indirect signature, the block of data pointed = to by the URL is not part of the message is implicitly signed since the = hash of the data block is signed rather than the actual data. It is = interesting to note that this is the way that CMS has always worked, the = hash of the message is placed in an array of attributes and that array = of attributes is what is signed by the signature algorithm. > > > > Nit: =E2=80=9C A pointer to the value that was hashed. this = could=E2=80=9D =E2=80=94=20 > > s/this/This/ > > > > [JLS] Fixed. > > > > > > -- I don't think the execution is relevant when it was obviously a bad idea = in the first place. This is like putting rabid weasels in your pants, and later expressing = regret at having chosen those particular rabid weasels and that pair of = pants. ---maf From nobody Tue Jun 2 12:17:06 2020 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 DC4D53A0F8C; Tue, 2 Jun 2020 12:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 cQ2gzTMiYeNM; Tue, 2 Jun 2020 12:16:56 -0700 (PDT) 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 DC04D3A0F79; Tue, 2 Jun 2020 12:16:55 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 2 Jun 2020 12:16:50 -0700 From: Jim Schaad To: 'Barry Leiba' , 'The IESG' CC: , , , 'Ivaylo Petrov' References: <159107239537.28693.16065000145824637198@ietfa.amsl.com> In-Reply-To: <159107239537.28693.16065000145824637198@ietfa.amsl.com> Date: Tue, 2 Jun 2020 12:16:48 -0700 Message-ID: <006201d63912$5e7663e0$1b632ba0$@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: AQGAFY4lrc4Y2TOVahTQsjcD5477ZKlx5COw X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Barry Leiba's Yes on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 19:17:05 -0000 -----Original Message----- From: Barry Leiba via Datatracker =20 Sent: Monday, June 1, 2020 9:33 PM To: The IESG Cc: draft-ietf-cose-hash-algs@ietf.org; cose-chairs@ietf.org; = cose@ietf.org; Ivaylo Petrov ; ivaylo@ackl.io Subject: Barry Leiba's Yes on draft-ietf-cose-hash-algs-04: (with = COMMENT) Barry Leiba has entered the following ballot position for draft-ietf-cose-hash-algs-04: Yes When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- =E2=80=94 Abstract =E2=80=94 There are however circumstances where hash algorithms are used, such as indirect signatures where the hash of one or more contents are signed, and X.509 certificate or other object identification by the use of a fingerprint. I found this hard to parse, and had to read it a few times. How about = this?: NEW There are, however, circumstances where hash algorithms are used, such as in indirect signatures, where the = hash of some content is signed, and for fingerprinting of X.509 = certificates or other objects. END [JLS] I have a bit of a problem with this. If you look at things = correctly then almost all of the current signature algorithms would fit = this, but it does not match what I am trying to say. ECDSA hashes a = content and then computes the signature math on that hash value. This = is not what we want to call an indirect signature even though it could = be considered to be one. This is as oppose to Pure EdDSA where the = entire content (with modifications) is hashed internally to the = signature code. How about "where the content to be signed contains the hash of one or more = external object," =E2=80=94 Introduction =E2=80=94 This omission was intentional as a structure consisting of just a digest identifier, the content, and a digest value does not by itself provide any strong security service. Nit: this needs a few more commas... one after = =E2=80=9Cintentional=E2=80=9D, and one before and one after =E2=80=9Cby = itself=E2=80=9D. [JLS] Done One of the primary things that has been identified by a hash function for secure message is a certificate. Another that I had trouble parsing. Maybe, =E2=80=9COne of the primary = things related to secure messages that has been identified by a hash = function is a certificate.=E2=80=9D [JLS] How about "Many applications use the hash of a certificate to = replace the certificate itself, this allows for uniquely identifying the = certificate while using fewer bytes." =E2=80=94 Section 2 =E2=80=94 hash functions is part of the base design as cryptographic advances are sure to reduce the strength of a hash function. Nit: this needs a comma after =E2=80=9Cdesign=E2=80=9D. [JLS] Done The standard "Collision Attack" is one where an attacker can find two different messages that have the same hash value. If a collision attack exists, then the function SHOULD NOT be used for a cryptographic purpose. I=E2=80=99m uncomfortable with having this document give a brief = tutorial on cryptographic hashing, as it has to be oversimplified... and = it is. If it=E2=80=99s going to stay, I=E2=80=99d like to see ar least = one minor change, though I=E2=80=99ll defer to the Sec ADs on this = point: for any hash alg, it is always possible to encounter a collision, = and the text isn=E2=80=99t clear about what =E2=80=9Cif a collision = attack exists=E2=80=9D really means. I think it means not to use it if a collision attack is = practical, and maybe this is a better way to say it?: NEW A "collision attack" is one where an attacker can find two different messages that have the same hash value. A hash function that is susceptible to collision attacks, SHOULD NOT be used for cryptographic purposes. END [JLS] Done. Given how fast we are at getting hash algorithms changed, I = don't know that the trigger I would use is that the attack is practical. = Just the ability to find a collision at all is the trigger that we need = to start changing the hash algorithms we are using. People have talked = about SHA-1 collisions for the last twenty years, but only in the last = two have they become practical. Should we be suggesting the SHOULD = earlier than 2017? checked to see if they are the correct one. =E2=80=9CThey are the correct one?=E2=80=9D Oof. How about, = =E2=80=9Cto find the correct one,=E2=80=9D or (maybe better), = =E2=80=9Cto see if they are suitable.=E2=80=9D? [JLS] How about "An example of a non-cryptographic use of a hash is for = filtering from a collection of values to find a set of possible = candidates, the candidates can then be check to see if they can = successfully be used." If the fingerprint is used to verify that it is the correct certificate, then that usage is subject to a collision attack as above. If however, the fingerprint is used to sort through a collection of certificates =E2=80=9Cthen that usage is a cryptographic one and is subject to the = warning above about collision attacks.=E2=80=9D And = =E2=80=9Chowever=E2=80=9D also needs a comma before it, as well as = after. [JLS] Done In this case, one still needs to validate that the public key validates the signature Make the first =E2=80=9Cvalidate=E2=80=9D say =E2=80=9Cconfirm=E2=80=9D = instead, to avoid the awkward double use of =E2=80=9Cvalidate=E2=80=9D. [JLS] Done To distinguish between these two cases, a new value in the recommended column of the COSE Algorithms registry is to be added. "Filter Only" indicates that the only purpose of a hash function should be to filter results and not those which require collision resistance. Might it be better to have the new column be called = =E2=80=9Ccryptographic use=E2=80=9D, with values of = =E2=80=9Cyes=E2=80=9D and =E2=80=9Cno=E2=80=9D? Hint: I think it would. = Hint#2: this is a non-blocking comment, so you might disagree. [JLS] I did think about this, the issue is that I do not know what the = correct value would be to place in that column for "AES-GCM-128". The = table has things which are not hash algorithms. =E2=80=94 Section 2.1 =E2=80=94 * Additional data, this can be something as simple as a random value Nit: make the comma a semicolon. [JLS] Done appending to the content, but it is strongly suggested to it Nit: change =E2=80=9Cto it=E2=80=9D to =E2=80=9Cthat it=E2=80=9D. [JLS] Done =E2=80=94 Section 3.1 =E2=80=94 Because of the known issues for SHA-1 and the fact that is should no Nit: change =E2=80=9Cthat is=E2=80=9D to =E2=80=9Cthat it=E2=80=9D. [JLS] Done =E2=80=94 Section 3.2 =E2=80=94 Locations that use this hash function need either to analysis the potential problems with having a collision occur, or where the only function of the hash is to narrow the possible choices. Locations? And do you mean to use =E2=80=9Canalysis=E2=80=9D as a verb? = Maybe this?: NEW Use of this hash function needs analysis of the potential problems with having a collision occur, or must be limited to where the function of the hash is non-cryptographic. END [JLS] Cleaner - done =E2=80=94 Section 3.3 =E2=80=94 One of the benefits of this differences is that when computing a shorter SHAKE hash value Nit: =E2=80=9Cdifference=E2=80=9D, singular. [JLS] Done =E2=80=94 Section 5 =E2=80=94 that need the cryptographic properties, i.e. collision resistance, and properties that correspond to possible object identification. Collision resistance isn=E2=80=99t the only cryptographic property = (there=E2=80=99s also, for example, preimage resistance), so change = =E2=80=9Ci.e.=E2=80=9D to =E2=80=9Csuch as=E2=80=9D. This is another = example of the hazard of trying to explain hashing in a simple document = such as this one. [JLS] Done This is the difference between collision resistance and second pre-image resistance. If you have collision resistance, don=E2=80=99t you automatically have = second preimage resistance? What=E2=80=99s he point of mentioning = second preimage resistance here, when you don=E2=80=99t mention it nor = need it anywhere else? [JLS] Looking at this, the two sentences do not really follow from what = preceded it so I deleted the two sentences. Yes a second preimage = attack would imply a collision attack. But looking at what Warren is = having problems with, there is a difference between the originator of = the message providing two different external objects which have the same = hash value and an attacker trying to find a second external object that = has the same hash value in order to get the bad firmware installed. are under constant attack and the strength of hash algorithms will be reduced over time. I would say =E2=80=9Cthe cryptographic strength=E2=80=9D. [JLS] Done. Jim From nobody Tue Jun 2 12:35:53 2020 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 CC66E3A0F7A for ; Tue, 2 Jun 2020 12:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 2BLDRQ9mEyMl for ; Tue, 2 Jun 2020 12:35:49 -0700 (PDT) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 D22AE3A0F75 for ; Tue, 2 Jun 2020 12:35:48 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id m18so14044065ljo.5 for ; Tue, 02 Jun 2020 12:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rYeL0P3wVQtbneEYPGOioR6biB7iBUJeTmKrngbtHv0=; b=r5usDJAN9CHRViMl2Ttor7kIkBjttiu5hLAWdA63jt0tbM3Q1XgnY+OGyfJkNlGUVz qSiCAtYJ1l1i9bHKJx6JO/HcR2o+9MlSZGfCnGKsqqRsD/gCgS8569yp0hc0mXeOXUAN saC6s2diaHKWdGoddTO8viOrGmMdmmZ4UbGWdmE0+qR78nUtsb7ukx3ExhR6uGr5xBx9 Hz4HMelAnnufdEz0d91cjcrxT5cD47FkS3xnGq8OcnbJf0tMnR2gFNWuTT2LbwYDnYjp pSVZFJseTFfrr09ncy0rXpFa7NWEAiXKGTcd0/fg4u0weoebAj+HQJuB1yOSOjKJlV9i Nz5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rYeL0P3wVQtbneEYPGOioR6biB7iBUJeTmKrngbtHv0=; b=ZDWJsHBghBQ16IGt0AjsP8s64ebjpFvrnRMQ+d0CLGcZHmSHDrRuT4Rfut36ENfb11 jzJ/2fS5nIJtHRHu19YeNnR5Zg+i/qLqleBc1uQu0aOiMhge2Whbr844frFJzXUrCoqE +Fuwhi8iq1ULKOg7o4uJLdsvpR/nCXIbs8ljJlSlsFqUtXgHWoUiwFn/Uk39tzmIlVg0 TFzSNp2ntN+d0UJx+0WSpSl11ALBqnA+iRgy3DGmUC8URsIIgg0suxTGp129CSqxhdaz 0l70PXPj8rlPKTBQ0vKiBBOUJPwJQ/3FyKSKj6nyNYAbRvhUf6ev+Z5U24iKmsOEOQox 833Q== X-Gm-Message-State: AOAM5315FgkCT0HHkZ/2/fkVFaXiregswD8qilb4IaBlRHfxSwh8NxNU J4LBr4I7tPRlqN4aedXwf2iNPEmJsH1oLNFoBdrnnA== X-Google-Smtp-Source: ABdhPJw7jtj9EGWQdBNW+xkKLfyn8Yjr+AXSKtb4piBYiPctnHJnlWOyQNch8zXenF3GnQNxG/DcnKHhoB4OGnlhmMM= X-Received: by 2002:a2e:6c15:: with SMTP id h21mr317074ljc.403.1591126546526; Tue, 02 Jun 2020 12:35:46 -0700 (PDT) MIME-Version: 1.0 References: <159101794967.27986.902730371235702504@ietfa.amsl.com> <000001d6384e$3b3ac480$b1b04d80$@augustcellars.com> <005c01d63907$7d7bfbc0$7873f340$@augustcellars.com> In-Reply-To: <005c01d63907$7d7bfbc0$7873f340$@augustcellars.com> From: Warren Kumari Date: Tue, 2 Jun 2020 15:35:09 -0400 Message-ID: To: Jim Schaad Cc: Barry Leiba , The IESG , Ivaylo Petrov , cose-chairs@ietf.org, draft-ietf-cose-hash-algs@ietf.org, cose@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [COSE] Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 19:35:52 -0000 On Tue, Jun 2, 2020 at 1:59 PM Jim Schaad wrote: > > > > -----Original Message----- > From: Warren Kumari > Sent: Tuesday, June 2, 2020 6:52 AM > To: Barry Leiba > Cc: Jim Schaad ; The IESG ; Ivaylo= Petrov ; cose-chairs@ietf.org; draft-ietf-cose-hash-algs@i= etf.org; cose@ietf.org > Subject: Re: Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04= : (with COMMENT) > > On Mon, Jun 1, 2020 at 4:15 PM Barry Leiba wrot= e: > > > > Put another way, I think that Warren is asking if a bad actor can > > trick you into downloading something anyway, and only after to wasted > > the download will you find out that you shouldn't have bothered. > > Nah, not quite -- "Doing indirect signing allows for a signature to be va= lidated without first downloading all of the content associated with the si= gnature. This capability can be of even greater importance in a constrain= ed environment as not all of the content signed may be needed by the devic= e." > > Sorry, I'm still not getting it > > I can see a signature over something like a manifest, listing all of the = "things" (firmware blocks, files, whatever). I can download this, and valid= ate the signature, and know that the manifest came from the e.g device manu= facturer. I can then look through and find the thing (let's pretend it's a = URL to a firmware update), go fetch that, hash it and then check that the "= Hash of the bytes of the update" match what was in the manifest. > But, in both of these cases, I have to download the entire thing that is = signed or hashed (first the manifest, and all of the bytes of the update *f= or my device type*). > > In another example, if this were a book, if I only cared about the chapte= r about doughnuts, I would check the index (and signature over the index), = and then go hash the chapter that the index points to, and make sure that i= t matches -- but, I've still had to a: check the signature on the index (wh= ich requires the entire index) and b: hash the entire doughnuts chapter (wh= ich means I need the entire doughnuts chapter). Yes, I don't need to hash t= he chapter on macarons or Mille feuilles, but I'm still having to download = / hash the content associated with the signature... > > Or, is this just saying that the index contains hashes for the individual= blocks (chapters), and so I just need to download the entire index and che= ck the signature, and then the block(s) that I care about (and that the has= hes match what is in the index)? > > [JLS] This is the case, all we have is an index that contains the hashes = of the individual blocks. You only need to download what you care about. = Thus you don't need to download the chapter on macarons, even though you ha= ve the pointer and hash of that data. If you later become interested in ma= carons you can down load that chapter and check that it has the correct has= h. > Oh, well that's all good then, but certainly isn't what I'd initially thought the text was trying to say. Perhaps something like: "Indirect signing allows for a signature over a set of hashes of chunks of content to be validated without first downloading all of the content. This capability can be of even greater importance in a constrained environment, as the device needs only download and hash the chunks it is interested in." ? Of course, this is all just a comment, and this might be blindingly obvious to everyone else / the intended audience (AKA, I will not be offended if you choose to ignore this / leave it as is...) Thanks for the explanation, W > Jim > > I'm really not trying to be difficult, I'm just confused... > W > > > > The > > answer to that is, "Sure." The point here is that the download can be > > saved most of the time, during normal operation. And the signature > > protects against the abnormal situations (such as someone trying to > > spoof an update). Nothing is perfect, but the combination is > > beneficial. > > > > Barry > > > > On Mon, Jun 1, 2020 at 3:53 PM Jim Schaad wrot= e: > > > > > > > > > > > > -----Original Message----- > > > From: Warren Kumari via Datatracker > > > Sent: Monday, June 1, 2020 6:26 AM > > > To: The IESG > > > Cc: draft-ietf-cose-hash-algs@ietf.org; cose-chairs@ietf.org; > > > cose@ietf.org; Ivaylo Petrov ; ivaylo@ackl.io > > > Subject: Warren Kumari's No Objection on > > > draft-ietf-cose-hash-algs-04: (with COMMENT) > > > > > > Warren Kumari has entered the following ballot position for > > > draft-ietf-cose-hash-algs-04: No Objection > > > > > > When responding, please keep the subject line intact and reply to > > > all email addresses included in the To and CC lines. (Feel free to > > > cut this introductory paragraph, however.) > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > Thank you for writing this - it was an interesting read. > > > > > > I do have one issue, which I cannot tell if it is simply me being dum= b, or if the text needs more work. > > > > > > =E2=80=9C Doing indirect signing allows for a signature to be validat= ed without first downloading all of the content associated with the signat= ure. This capability > > > can be of even greater importance in a constrained environment as n= ot all of > > > the content signed may be needed by the device.=E2=80=9D > > > > > > I=E2=80=99m unclear how this works =E2=80=94 itseems clear enough th= at I can verify that the signature matches the hash, but doesn=E2=80=99t th= e device need to still download and compute the hash over all of the conten= t? > > > > > > Otherwise I could take a hash and signature from content A, and claim= that it is for content B. Sure, if the signature **doens=E2=80=99t** match= the hash I know not to bother downloading the content at all, but if the s= ig does match the hash I still need to download the content to check that t= he hash is for this content.... > > > > > > Please help educate me! > > > > > > [JLS] I am more than willing to help educate. You are going to be se= eing some of this from the SUIT people as well. For a firmware type update= you might defined a structure that looks like: > > > FirmwareBlock =3D Array of ( > > > Text description of block > > > Hardware target > > > Version number > > > URL to the bytes of the update > > > Hash algorithm identifier > > > Hash of the bytes of the update > > > > > > A message containing an array of these blocks is created, a COSE sign= ed message is then created containing this array of blocks as the content o= f the message and sent to the piece of hardware. > > > > > > The hardware can then validate the signed message, walk the array of = blocks, if the block applies download the bytes pointed to by the URL, hash= the bytes downloaded and compare the hash values. If the hash values matc= h then the bytes can be applied to the device. This allows a device to onl= y download the bytes that are needed, ignoring those which have either alre= ady been applied or which are not relevant to the device. > > > > > > This is what I call an indirect signature, the block of data pointed = to by the URL is not part of the message is implicitly signed since the has= h of the data block is signed rather than the actual data. It is interesti= ng to note that this is the way that CMS has always worked, the hash of the= message is placed in an array of attributes and that array of attributes i= s what is signed by the signature algorithm. > > > > > > Nit: =E2=80=9C A pointer to the value that was hashed. this could=E2= =80=9D =E2=80=94 > > > s/this/This/ > > > > > > [JLS] Fixed. > > > > > > > > > > > > > -- > I don't think the execution is relevant when it was obviously a bad idea = in the first place. > This is like putting rabid weasels in your pants, and later expressing re= gret at having chosen those particular rabid weasels and that pair of pants= . > ---maf > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Jun 2 13:11:08 2020 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 AF9D03A0FAA; Tue, 2 Jun 2020 13:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 BEY7XM7hWd2M; Tue, 2 Jun 2020 13:11:00 -0700 (PDT) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (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 7759F3A0D83; Tue, 2 Jun 2020 13:11:00 -0700 (PDT) Received: by mail-io1-f47.google.com with SMTP id m81so12232960ioa.1; Tue, 02 Jun 2020 13:11:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Iiq1XbO7AIIVONcek3lRCYEtWsFLLsUV4Vk03ocPR/E=; b=fW4Ii1ua5pOXNw3L6GOQfp6hx+TgL8/2tNi8h31ktF7mc5aBfC9+5QzLZRdcrmQbTX 8U8mlyUQiKNgLGnDCWU238XT+tL0BSdkYjJq+R2CqW4XgBdqM1oBDEZz/XGmbbN+sR3r VGPOWb9w4oX+fGIZAk5sxuVxDLnoMFPgC+QFk8lwkoqyZY+itZtpCWv2avfL4xsVlf3F SENJwg7327egPVKn3h3GL5Em+80HfX58H7PrRUffYGkx6tl9vg2vvHxzGoHbgOL/EBlT aAUwyp/c6aVC5JdgxXAhS+mOrhiubrVheAxIYzF51Pg5WoFNahSk5vlIPwwSk97i2WDQ SuSA== X-Gm-Message-State: AOAM532f7OxLUV/XTcw7sJIEqI1BPvMNSG6mAlhMYYxDjxFXYqGoNWqD OLMRg/P/O1G6jaVWo/U/ediTgKDIeLyVj+EW+6V+3g== X-Google-Smtp-Source: ABdhPJyml8dRT4IcoL+dHA7RnjnHX+RUMOk93yjn5VpEdtLG392fqiWkj77iVXDc7zknXP3UB6me/dG6Ts+I8Y2wgUU= X-Received: by 2002:a02:cd89:: with SMTP id l9mr25783619jap.88.1591128659619; Tue, 02 Jun 2020 13:10:59 -0700 (PDT) MIME-Version: 1.0 References: <159107239537.28693.16065000145824637198@ietfa.amsl.com> <006201d63912$5e7663e0$1b632ba0$@augustcellars.com> In-Reply-To: <006201d63912$5e7663e0$1b632ba0$@augustcellars.com> From: Barry Leiba Date: Tue, 2 Jun 2020 16:10:48 -0400 Message-ID: To: Jim Schaad Cc: Ivaylo Petrov , The IESG , cose@ietf.org, cose-chairs@ietf.org, draft-ietf-cose-hash-algs@ietf.org Content-Type: multipart/alternative; boundary="0000000000008c723b05a71f82b8" Archived-At: Subject: Re: [COSE] Barry Leiba's Yes on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 20:11:02 -0000 --0000000000008c723b05a71f82b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the response, Jim, and your counter-suggestions all look good. I appreciate your considering my comments. On this: > Might it be better to have the new column be called =E2=80=9Ccryptographi= c use=E2=80=9D, > with values of =E2=80=9Cyes=E2=80=9D and =E2=80=9Cno=E2=80=9D? Hint: I t= hink it would. Hint#2: this is a > non-blocking comment, so you might disagree. [JLS] I did think about this, the issue is that I do not know what the correct value would be to place in that column for "AES-GCM-128". The table has things which are not hash algorithms. You couldn=E2=80=99t say =E2=80=9Cyes=E2=80=9D to =E2=80=9Ccryptographic us= e=E2=80=9D for AES-GCM-128? Why would =E2=80=9CRecommend=E2=80=9D =E2=80=9Cyes=E2=80=9D be better? I kind of fee= l (though not that strongly, so I=E2=80=99ll let this be my last comment on it unless you want to continue = to chat about it) that =E2=80=9CRecommend=E2=80=9D is an odd column heading. The n= ame raises a question for me about why the entry would be there if it=E2=80=99s not Reco= mmended. b --0000000000008c723b05a71f82b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the response, Jim, and your counter-suggestion= s all look good.=C2=A0 I appreciate your considering my comments.

On this:
<= div class=3D"quoted-text" style=3D"font-size:1rem;word-spacing:1px;border-c= olor:rgb(117,117,117);color:rgb(117,117,117)" dir=3D"auto">> Might it be= better to have the new column be called =E2=80=9Ccryptographic use=E2=80= =9D,
> = with values of =E2=80=9Cyes=E2=80=9D and =E2=80=9Cno=E2=80=9D?=C2=A0 Hint: = I think it would.=C2=A0 Hint#2: this is a
> non-blocking comment, so you might dis= agree.

[JLS] I did think about this, the issue is t= hat I do not know what the correct value would be to place in that column f= or "AES-GCM-128".=C2=A0 The table has things which are not hash a= lgorithms.

You couldn=E2=80=99t say =E2= =80=9Cyes=E2=80=9D to =E2=80=9Ccryptographic use=E2=80=9D for AES-GCM-128?= =C2=A0 Why would =E2=80=9CRecommend=E2=80=9D =E2=80=9Cyes=E2=80=9D be bette= r?=C2=A0 I kind of feel (though not that strongly, so I=E2=80=99ll let this= be my last comment on it unless you want to continue to chat about it) tha= t =E2=80=9CRecommend=E2=80=9D is an odd column heading.=C2=A0 The name rais= es a question for me about why the entry would be there if it=E2=80=99s not= Recommended.

=
b

--0000000000008c723b05a71f82b8-- From nobody Tue Jun 2 14:43:45 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 574663A1030; Tue, 2 Jun 2020 14:43:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <159113421930.19924.3902870708438133297@ietfa.amsl.com> Date: Tue, 02 Jun 2020 14:43:39 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-rfc8152bis-algs-09.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 21:43:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption WG of the IETF. Title : CBOR Object Signing and Encryption (COSE): Initial Algorithms Author : Jim Schaad Filename : draft-ietf-cose-rfc8152bis-algs-09.txt Pages : 50 Date : 2020-06-02 Abstract: Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. COSE additionally describes how to represent cryptographic keys using CBOR. In this specification the conventions for the use of a number of cryptographic algorithms with COSE. The details of the structure of COSE are defined in [I-D.ietf-cose-rfc8152bis-struct]. This document along with [I-D.ietf-cose-rfc8152bis-struct] obsoletes RFC8152. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-09 https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-rfc8152bis-algs-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 2 14:43:48 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B59B3A1031; Tue, 2 Jun 2020 14:43:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <159113421931.13129.18184162952803724970@ietfa.amsl.com> Date: Tue, 02 Jun 2020 14:43:39 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-rfc8152bis-struct-10.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 21:43:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption WG of the IETF. Title : CBOR Object Signing and Encryption (COSE): Structures and Process Author : Jim Schaad Filename : draft-ietf-cose-rfc8152bis-struct-10.txt Pages : 86 Date : 2020-06-02 Abstract: Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes RFC8152. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-struct-10 https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-struct-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-rfc8152bis-struct-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 2 14:47:05 2020 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 734E23A1033 for ; Tue, 2 Jun 2020 14:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 nNUY5DYnd2oL for ; Tue, 2 Jun 2020 14:47:00 -0700 (PDT) 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 7E4CB3A103C for ; Tue, 2 Jun 2020 14:47:00 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 2 Jun 2020 14:46:55 -0700 From: Jim Schaad To: CC: 'Barry Leiba' References: <159113421955.13129.2834330510226770345@ietfa.amsl.com> In-Reply-To: <159113421955.13129.2834330510226770345@ietfa.amsl.com> Date: Tue, 2 Jun 2020 14:46:53 -0700 Message-ID: <006f01d63927$55c85b30$01591190$@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: AQGJw7smRd6e1iijhGLjr4wEykP2uqlexuiw X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] FW: New Version Notification for draft-ietf-cose-rfc8152bis-struct-10.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 21:47:03 -0000 With the expiration of the IETF last call I have published an update of = this and the -algs document with all of the comments received to date. Jim -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Tuesday, June 2, 2020 2:44 PM To: Jim Schaad Subject: New Version Notification for = draft-ietf-cose-rfc8152bis-struct-10.txt A new version of I-D, draft-ietf-cose-rfc8152bis-struct-10.txt has been successfully submitted by Jim Schaad and posted to the IETF = repository. Name: draft-ietf-cose-rfc8152bis-struct Revision: 10 Title: CBOR Object Signing and Encryption (COSE): Structures and = Process Document date: 2020-06-02 Group: cose Pages: 86 URL: = https://www.ietf.org/internet-drafts/draft-ietf-cose-rfc8152bis-struct-10= .txt Status: = https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ Htmlized: = https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-struct-10 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-struct Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-rfc8152bis-struct-10 Abstract: Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes RFC8152. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Wed Jun 3 09:45:46 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC583A0AE6; Wed, 3 Jun 2020 09:45:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <159120274039.24141.10627241675977225120@ietfa.amsl.com> Date: Wed, 03 Jun 2020 09:45:40 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-webauthn-algorithms-07.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 16:45:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption WG of the IETF. Title : COSE and JOSE Registrations for WebAuthn Algorithms Author : Michael B. Jones Filename : draft-ietf-cose-webauthn-algorithms-07.txt Pages : 13 Date : 2020-06-03 Abstract: The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms in the IANA "COSE Algorithms" registry, which are used by WebAuthn and CTAP implementations: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1, and ECDSA using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-07 https://datatracker.ietf.org/doc/html/draft-ietf-cose-webauthn-algorithms-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-webauthn-algorithms-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 3 09:50:08 2020 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 8127A3A0956; Wed, 3 Jun 2020 09:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 wbSPoopvWX1t; Wed, 3 Jun 2020 09:50:00 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640106.outbound.protection.outlook.com [40.107.64.106]) (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 672003A091C; Wed, 3 Jun 2020 09:50:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lt2Sl7tVuH+b9ko2JtIeaW5NfDD8pq1K8nLTtFcuh7XtyMXqeJGfKZvF6FYX9qErZdyfe2xYQU952GbW4eaXZ5u5KYWBNITju5EbRpzsUnvJKABjuFaX6v9+GsAdIYKsSW1Uyqd+uCFfvnmfJKO790Obbx+NnBmu5ItjCk4UuqS55V/rVcy+1JK2vz1HAvDWgGWqqSDy8h49fqOdgKXqIDmBhCA4xOnCjJGPtivfE+LV+/DqGriLvTjiYM60V0LcPUl853hingGPTTKZu6au7U3V0TUxg7UWv/TqnI93bJYtbNMh5weHklswEHCKbS7zj0hVbfEufYL8PVuv5PEEAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eAbEtqvo9B49wS7lxVV6DdkRjFsYaxA8ryJMJLgwr90=; b=isVSjWaYjXSugasHhTYfW9xFLAv0HjM3xB0hJUZ8+WvjbyeefByKODPU7xWEHNUuhtal9thyifbR7sCo4/pruvFtbzM9lLLIHzwb8SETiKx+ZzrD42rs2RyHBdRFkkGmz9TEqisUa/m7bA2zVUduJPVwcNdDzdBJQEIE31HeKk5405OdXFn+jPJ9dKO4QX04sPfHZrA1TJ4/qk8jfxQXA5DyCbNk1lGtw8uIgv9RWecB8BG6kGwSVCBywlhcqXh/39AvAnAxUoxf7xAhRGbKKtM/jdrJVlp6Wh2Bhj8faROxUH0XKTH1ygZGPSWsq+6Y91QR+noY20lHEuYc3Agq6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eAbEtqvo9B49wS7lxVV6DdkRjFsYaxA8ryJMJLgwr90=; b=ArYix5be+lz1fP1/AfJd8Zu9Rd/iGy7VIEJ/yAlc+BBngAu0VUNPsf5svhGtutxmlp6jLJGkcjcbalG/wGnms0Wbjvje7PEoD7B/icwA78+TLdzK7+ryhSnjlhR4XOqEK4PAym8eBiSICEY31aQJLFg/JL697IRh0qpaI9k8urY= Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0307.namprd00.prod.outlook.com (2603:10b6:207:1e::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3104.0; Wed, 3 Jun 2020 16:49:57 +0000 Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::c1e4:c91b:f4de:f548]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::c1e4:c91b:f4de:f548%5]) with mapi id 15.20.3107.000; Wed, 3 Jun 2020 16:49:57 +0000 From: Mike Jones To: Eric Rescorla , "rsalz@akamai.com" CC: "last-call@ietf.org" , Jim Schaad , "cose@ietf.org" Thread-Topic: [COSE] [Last-Call] Last Call: (COSE and JOSE Registrations for WebAuthn Algorithms) to Proposed Standard Thread-Index: AdYxXK5oD21D1OE4Q7aiB+KOED7TnwIaeXCg Date: Wed, 3 Jun 2020 16:49:56 +0000 Message-ID: References: In-Reply-To: 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_ActionId=6f8afca1-ed22-409e-a0ab-0000cf3991d6; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-23T23:38:37Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6bc53cc4-f3c9-4c24-52b6-08d807de25cf x-ms-traffictypediagnostic: BL0PR00MB0307: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04238CD941 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: w7lZB3mfC44GJ2T1r3afiaJnGfkJGDyYW4fM+MHR0N+njINY70uW7NTqR6Y4Nb5ekca3b8gB3Vhgpofdj7uAgoEoYy6RFQwIkrcHi4EjYABVKJ/gLUDvmltu5EHMmtU2l0qAzP24T63uGuDu6yx+mWHyW1dPcGSN1hKAWZZz7e65xnuKJR3XVjtuGZ7G++VbcPMaW+6JMUJMyzu7uE4JZwJZKbFaYBbAJteL7mWt8QDhZKADOfVZud4bGSsctSNaMcK8gwQSoJ0hElBpsnpM/OFxZyHAaTxVa5153swhcOn9xXod8Bop1lN3jal2rXv9doeq4zC6kR1CjX+DF4KUE3tKZ1rJBBmxmO1mX1YIi92A4dNwQ5wRCXWwRFrISS5rrI/5lEmBERu6+iTLKjargA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(346002)(396003)(376002)(366004)(2906002)(33656002)(966005)(66446008)(66556008)(76116006)(86362001)(64756008)(8936002)(10290500003)(478600001)(66946007)(8676002)(316002)(66476007)(83380400001)(166002)(110136005)(54906003)(9686003)(82950400001)(82960400001)(7696005)(52536014)(5660300002)(55016002)(186003)(71200400001)(4326008)(8990500004)(53546011)(26005)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: r7ktdvsjwiymmphWyc1HxN5LfRcwJXOyz3O4KKXCbycKPZ8mrdgYL2FC1rJJYCCeKMJLXp6SsFvrznpYPGU8vbmgkOncWAi2guIhjNeKSvh0t4HPdddKWrCFMqTfGFwldJZB7c5GwLeHX3BzExCYYxvnfsAAg/dOWASFrVpPJc/bhBWnBryzLP9lGKHNKsu5JIIVKrL9upc/5++KYzKQLGxR+myeVkhu5o49ZaszhR+1PVaPtjQ+x3MRjU0mPdY91KgqmSoEqGA6yJ2/ti16cRj/H553bKbvZGIfjMakiiCfPnluJdCet1XuVSMJ/mHiJUukzEtcg1ipBoRV/mA1iUZ28mb7T2CHRRJjFzHwiCgNubUd0WdeQNzdC/8ykuOgyKiRKi0FYEd17tdiqfZjmZ4Ff7k2QZ1fkhhqBpWRSDZ6oSa8cnskgGMBO9YiM8vZLn4jL7Pn1V0ERcJ8Itwe8N43wGa8SBUt5bDW7B+THA0= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0688C598816D9CFDC595BFCDF5880MN2PR00MB0688namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6bc53cc4-f3c9-4c24-52b6-08d807de25cf X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2020 16:49:56.9053 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +BPwY4uVPgsGEsEPvX8RjASWxaGOh67J3QWPFCjRSjWO4qo2xCQnRVTYtu7icJn3frQjAwkGFJ4kxWyvChfZOw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0307 Archived-At: Subject: Re: [COSE] [Last-Call] Last Call: (COSE and JOSE Registrations for WebAuthn Algorithms) to Proposed Standard X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 16:50:03 -0000 --_000_MN2PR00MB0688C598816D9CFDC595BFCDF5880MN2PR00MB0688namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29zZS13ZWJhdXRobi1hbGdv cml0aG1zLTA3IG5vdyByZWdpc3RlcnMgc2VjcDI1NmsxIGFuZCBFUzI1NksgYXMg4oCcUmVjb21t ZW5kZWQ6IE5v4oCdLCBwZXIgeW91ciByZXF1ZXN0cy4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogTWlrZSBK b25lcw0KU2VudDogU2F0dXJkYXksIE1heSAyMywgMjAyMCA0OjQ5IFBNDQpUbzogRXJpYyBSZXNj b3JsYSA8ZWtyQHJ0Zm0uY29tPjsgcnNhbHpAYWthbWFpLmNvbQ0KQ2M6IGxhc3QtY2FsbEBpZXRm Lm9yZzsgSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47IGNvc2VAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbQ09TRV0gW0xhc3QtQ2FsbF0gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1j b3NlLXdlYmF1dGhuLWFsZ29yaXRobXMtMDUudHh0PiAoQ09TRSBhbmQgSk9TRSBSZWdpc3RyYXRp b25zIGZvciBXZWJBdXRobiBBbGdvcml0aG1zKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KDQpJIGNh biBjZXJ0YWlubHkgY2hhbmdlIHRoZSBDT1NFIHJlY29tbWVuZGF0aW9uIHN0YXR1cyBmcm9tIFll cyB0byBObywgaWYgdGhhdOKAmXMgdGhlIHByZXZhaWxpbmcgb3Bpbmlvbi4gIFRob3NlIHRoYXQg aGF2ZSBkZWNpZGVkIHRvIHVzZSBzZWNwMjU2azEgb3ZlciB0aGUgTklTVCBhbmQgMjU1MTkgY3Vy dmVzIHdpbGwgbGlrZWx5IGNvbnRpbnVlIHRvIGRvIHNvIG5vIG1hdHRlciB3aGF0IHdlIGRlY2lk ZSBpbiB0aGlzIHJlZ2FyZC4NCg0KSeKAmWxsIHdhaXQgdW50aWwgdGhlIGxhc3QgY2FsbCBleHBp cmVzIG9uIFdlZG5lc2RheSB0byBzZWUgd2hhdCBvdGhlciBjb21tZW50cyBtYXkgY29tZSBpbiBh bmQgdGhlbiBwdWJsaXNoIGFuIHVwZGF0ZWQgZHJhZnQuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MgYWxsLA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0K RnJvbTogQ09TRSA8Y29zZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjb3NlLWJvdW5jZXNAaWV0 Zi5vcmc+PiBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogU2F0dXJkYXksIE1heSAy MywgMjAyMCAyOjM2IFBNDQpUbzogU2FseiwgUmljaCA8cnNhbHo9NDBha2FtYWkuY29tQGRtYXJj LmlldGYub3JnPG1haWx0bzpyc2Fsej00MGFrYW1haS5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KQ2M6 IGxhc3QtY2FsbEBpZXRmLm9yZzxtYWlsdG86bGFzdC1jYWxsQGlldGYub3JnPjsgSmltIFNjaGFh ZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4+ OyBjb3NlQGlldGYub3JnPG1haWx0bzpjb3NlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDT1NF XSBbTGFzdC1DYWxsXSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLWNvc2Utd2ViYXV0aG4tYWxnb3Jp dGhtcy0wNS50eHQ+IChDT1NFIGFuZCBKT1NFIFJlZ2lzdHJhdGlvbnMgZm9yIFdlYkF1dGhuIEFs Z29yaXRobXMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoNCkdvb2QgY2F0Y2guIFdlIGRlZmluaXRl bHkgc2hvdWxkIG5vdCBiZSByZWNvbW1lbmRpbmcgc2VwMjU2azEuDQoNCi1Fa3INCg0KDQpPbiBT YXQsIE1heSAyMywgMjAyMCBhdCAxOjMwIFBNIFNhbHosIFJpY2ggPHJzYWx6PTQwYWthbWFpLmNv bUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3JnPj4gd3Jv dGU6DQo+ICAgIEkgYmVsaWV2ZSB0aGF0IHRoZSBJRVNHIG5lZWRzIHRvIGRlYmF0ZSBpZiB0aGlz IGRvY3VtZW50IHNob3VsZCBiZSB0aGUgb25lDQogICAgd2hpY2ggbWFrZXMgdGhlIHNlY3AyNTZr MSBjdXJ2ZSBhIHJlY29tbWVuZGVkIElFVEYgY3VydmUgdG8gdXNlLg0KDQpBIGdvb2QgcG9pbnQs IGFsYmVpdCBzbGlnaHRseSBzdWJ0bGUuICArMS4NCg0KDQoNCi0tDQpsYXN0LWNhbGwgbWFpbGlu ZyBsaXN0DQpsYXN0LWNhbGxAaWV0Zi5vcmc8bWFpbHRvOmxhc3QtY2FsbEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGFzdC1jYWxsDQo= --_000_MN2PR00MB0688C598816D9CFDC595BFCDF5880MN2PR00MB0688namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjAN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29zZS13ZWJhdXRobi1hbGdvcml0aG1z LTA3Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3NlLXdlYmF1dGhu LWFsZ29yaXRobXMtMDc8L2E+IG5vdyByZWdpc3RlcnMgc2VjcDI1NmsxIGFuZCBFUzI1NksgYXMg 4oCcUmVjb21tZW5kZWQ6IE5v4oCdLCBwZXIgeW91ciByZXF1ZXN0cy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWlrZSBKb25lcyA8YnI+DQo8Yj5TZW50OjwvYj4g U2F0dXJkYXksIE1heSAyMywgMjAyMCA0OjQ5IFBNPGJyPg0KPGI+VG86PC9iPiBFcmljIFJlc2Nv cmxhICZsdDtla3JAcnRmbS5jb20mZ3Q7OyByc2FsekBha2FtYWkuY29tPGJyPg0KPGI+Q2M6PC9i PiBsYXN0LWNhbGxAaWV0Zi5vcmc7IEppbSBTY2hhYWQgJmx0O2lldGZAYXVndXN0Y2VsbGFycy5j b20mZ3Q7OyBjb3NlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ09TRV0gW0xh c3QtQ2FsbF0gTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtaWV0Zi1jb3NlLXdlYmF1dGhuLWFsZ29yaXRo bXMtMDUudHh0Jmd0OyAoQ09TRSBhbmQgSk9TRSBSZWdpc3RyYXRpb25zIGZvciBXZWJBdXRobiBB bGdvcml0aG1zKSB0byBQcm9wb3NlZCBTdGFuZGFyZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgY2FuIGNlcnRhaW5s eSBjaGFuZ2UgdGhlIENPU0UgcmVjb21tZW5kYXRpb24gc3RhdHVzIGZyb20gWWVzIHRvIE5vLCBp ZiB0aGF04oCZcyB0aGUgcHJldmFpbGluZyBvcGluaW9uLiZuYnNwOyBUaG9zZSB0aGF0IGhhdmUg ZGVjaWRlZCB0byB1c2Ugc2VjcDI1NmsxIG92ZXIgdGhlIE5JU1QgYW5kIDI1NTE5IGN1cnZlcyB3 aWxsIGxpa2VseSBjb250aW51ZSB0byBkbyBzbyBubw0KIG1hdHRlciB3aGF0IHdlIGRlY2lkZSBp biB0aGlzIHJlZ2FyZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPknigJls bCB3YWl0IHVudGlsIHRoZSBsYXN0IGNhbGwgZXhwaXJlcyBvbiBXZWRuZXNkYXkgdG8gc2VlIHdo YXQgb3RoZXIgY29tbWVudHMgbWF5IGNvbWUgaW4gYW5kIHRoZW4gcHVibGlzaCBhbiB1cGRhdGVk IGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyBhbGwsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBDT1NFICZsdDs8YSBocmVmPSJt YWlsdG86Y29zZS1ib3VuY2VzQGlldGYub3JnIj5jb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0 Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IFNh dHVyZGF5LCBNYXkgMjMsIDIwMjAgMjozNiBQTTxicj4NCjxiPlRvOjwvYj4gU2FseiwgUmljaCAm bHQ7PGEgaHJlZj0ibWFpbHRvOnJzYWx6PTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZyI+cnNh bHo9NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxh IGhyZWY9Im1haWx0bzpsYXN0LWNhbGxAaWV0Zi5vcmciPmxhc3QtY2FsbEBpZXRmLm9yZzwvYT47 IEppbSBTY2hhYWQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tIj5p ZXRmQGF1Z3VzdGNlbGxhcnMuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86Y29zZUBpZXRm Lm9yZyI+Y29zZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDT1NFXSBb TGFzdC1DYWxsXSBMYXN0IENhbGw6ICZsdDtkcmFmdC1pZXRmLWNvc2Utd2ViYXV0aG4tYWxnb3Jp dGhtcy0wNS50eHQmZ3Q7IChDT1NFIGFuZCBKT1NFIFJlZ2lzdHJhdGlvbnMgZm9yIFdlYkF1dGhu IEFsZ29yaXRobXMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Hb29kIGNhdGNoLiBXZSBkZWZpbml0ZWx5IHNob3VsZCBu b3QgYmUgcmVjb21tZW5kaW5nIHNlcDI1NmsxLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBNYXkgMjMsIDIwMjAgYXQgMToz MCBQTSBTYWx6LCBSaWNoICZsdDtyc2Fsej08YSBocmVmPSJtYWlsdG86NDBha2FtYWkuY29tQGRt YXJjLmlldGYub3JnIj40MGFrYW1haS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7ICZuYnNwOyBJ IGJlbGlldmUgdGhhdCB0aGUgSUVTRyBuZWVkcyB0byBkZWJhdGUgaWYgdGhpcyBkb2N1bWVudCBz aG91bGQgYmUgdGhlIG9uZTxicj4NCiZuYnNwOyAmbmJzcDsgd2hpY2ggbWFrZXMgdGhlIHNlY3Ay NTZrMSBjdXJ2ZSBhIHJlY29tbWVuZGVkIElFVEYgY3VydmUgdG8gdXNlLjxicj4NCjxicj4NCkEg Z29vZCBwb2ludCwgYWxiZWl0IHNsaWdodGx5IHN1YnRsZS4mbmJzcDsgJiM0MzsxLjxicj4NCjxi cj4NCjxicj4NCjxicj4NCi0tIDxicj4NCmxhc3QtY2FsbCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86bGFzdC1jYWxsQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bGFzdC1jYWxs QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbGFzdC1jYWxsIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9sYXN0LWNhbGw8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR00MB0688C598816D9CFDC595BFCDF5880MN2PR00MB0688namp_-- From nobody Wed Jun 3 09:51:47 2020 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 9DBE93A0963; Wed, 3 Jun 2020 09:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 VCZvD-DfiwtH; Wed, 3 Jun 2020 09:51:44 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640108.outbound.protection.outlook.com [40.107.64.108]) (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 473F13A091C; Wed, 3 Jun 2020 09:51:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jvg1WbAkNi2+/TVyHDd7fVa0wzVBS4ub1sl6Rihsz5V0Sp0c+YEyOawf5+EXsJaBnoeW9hnnmwM9oGRnjwocIbueabgeqxvVUJA7ArnOXso9oztMQ2SF5C8TJOs8vkgWytZP5yBPsEpkzg9XxiJMbWog3mRZke2yQzN80er+NLA7RcmPG9gX+zDBu0kayinF9YzX6eN4lDIZOVjOrpsfwWL+mPR59cG7juPEnNQ4BBS9q8sDLVoHRZS+wcqGUHp3ygF5CBt45UEepeKGQqBTzA72PiT3AKovzXVSouhdqXYEbekSNm92HS17clKmmjkFnTSJowW7dF9+C0P10X+3Zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zk8MOzPUIALS04cQarCgPhWaUeVvkxuxcR+4qRTeGX0=; b=DJxjQHVkgbq9Lqws0mpTA0zFWlxt1BtzZlHWvrslhg+wfWyqgRYxCq/kizj2I48RL/w2WqWQy9y4o6zUNivb4YzjZ5wBSaDTyMMl9abakfRDscGfExuUnwtzXBpedF/Fr+R/EnLhQoKCCiIjmtDCfiMy9K2Uy0teFUCEo7uMvPM1tXwhedz+kUne4V0tE2/svL7uxU2v+miOfRU0UJloi/GmlL7P8DUO0XpG9iK/R5AcQF9M95bAxRHmyx/v/tuEJptIWrQBYo94XwuQsO607V3nqaHEG1OXCNgy8qLczqa0aJUWnQkCBsAEShwHOoXa7hLSG9xkM//8ydP9j3/vTw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zk8MOzPUIALS04cQarCgPhWaUeVvkxuxcR+4qRTeGX0=; b=AGPIDwOoFjV52bbYJhgo7/Cl1dhxk8mIL+QSyRMzF1a7Rou7baSrw+jCTiaHPug471c7H28RmOhUnVkePM7xCNz+7+EGZPkLjM5/+UdGUHjoDch/BpYy7NfyoRh1z6naz61Y47HAhR1iw5dTo1EUJQLWzRp0af9ALkaJo8nocgQ= Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0307.namprd00.prod.outlook.com (2603:10b6:207:1e::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3104.0; Wed, 3 Jun 2020 16:51:34 +0000 Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::c1e4:c91b:f4de:f548]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::c1e4:c91b:f4de:f548%5]) with mapi id 15.20.3107.000; Wed, 3 Jun 2020 16:51:34 +0000 From: Mike Jones To: Linda Dunbar , "Matthew A. Miller" , "secdir@ietf.org" CC: "cose@ietf.org" , "draft-ietf-cose-webauthn-algorithms.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-cose-webauthn-algorithms-06 Thread-Index: AQHWNIYAZ9wJpsSs30mTfNXJra/es6jHJQSg Date: Wed, 3 Jun 2020 16:51:34 +0000 Message-ID: References: <159053708200.16306.10159573848968846851@ietfa.amsl.com> In-Reply-To: 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_ActionId=efc2d60a-0ed4-43b6-8f8a-000013c750c0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-03T16:50:06Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8368a755-352a-46cc-8ca1-08d807de600c x-ms-traffictypediagnostic: BL0PR00MB0307: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04238CD941 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aF4Jlsx6NScYqaiFYiaqum7yW39WcmlLUExDLGYIRgjyyrqwofo0Ehtc2Svk30vxbpHBMqwbz4wzAog95+8bPKP8fvZSvPzkYU9y3/QvcsE518SKvo4ab6r48wmzyr/EmBNraFUU7zUsM29VjY8QdlEEubiw9f4W2fh12B+FT1+zA+teuxIFYaLF+3F//atCHhrzYEK1QEzkQx/nlFipRzIeypjV/EBS+KSWOMESejUQICQm7HD03TKm3opFhD72UMyCJROBYT7bgxgoTxIQ3uL9aFRrUiyN2sfkkCT4XIzKYd8cmuaSpUuvT6itPRm7K1g01qlqf1vcPKpyg/Z+o8FQoFDYMWV1uVnBvjk3GwcHpXC6A7p/YQ/UVwAmMdwTLdHfLlLLWM3b+jq6UtUVng== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(346002)(396003)(376002)(366004)(2906002)(33656002)(966005)(66446008)(66556008)(76116006)(86362001)(64756008)(8936002)(10290500003)(478600001)(66946007)(8676002)(316002)(66476007)(83380400001)(110136005)(54906003)(9686003)(82950400001)(82960400001)(7696005)(52536014)(5660300002)(55016002)(186003)(71200400001)(4326008)(8990500004)(53546011)(26005)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: JahTPlw/n9e+uPfBVeFnEKjFtajEs6MQ8Z1M/2JGh67oRW8MrjTNhgqO3R2tl4xZHoXqNQmnjbPfAHhGcBeI8AXpYTCePsVSvc+vyazU+vq81BwOrBWf3qyhPKDBw2k0zT0tLf9MppCEBJIutMl+T39oj5Y2ChfAP76sKGzWB2KIa4g8dkEL9YYpkLH1mEZc9adaRz9N+EOHmT7VzGszKa6S1Xq0Yxyso4wjjD9l+GHMlAFEVYC0zCJ6bMKVOtDs3bR4AHFvyF3Y8i9fR53IbrBtDMvGAeT8a7oYNj+lWlsfgIi5TgNxpVT8sknrzJpdjSz630qS0y53yd4+UqYS/ZwvwaRnqQGkNrGChvPI/1IjPbWTFDUioVAowsE5muypt0jBc3hf6UXxu2jnHiYHBkF610YbtTiFxXP/viHDS2MSPo60uphB2vFGE4mfrCxD1HJ50qfPwM2UITlNXfw5ABzv0rXLX2rngU9bG3TTYDI= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8368a755-352a-46cc-8ca1-08d807de600c X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2020 16:51:34.6851 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tC5yx/qMigw/yPCbXEI6MMrQ2voeMIPBnVZw+TE6HRCSTq+uP6hqT/UiMJ+7Iyl5axgOmKXIdrY6D8H33ZFlFg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0307 Archived-At: Subject: Re: [COSE] Secdir last call review of draft-ietf-cose-webauthn-algorithms-06 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 16:51:46 -0000 VGhhbmtzIGFnYWluIGZvciB5b3VyIHJldmlldywgTGluZGEuICBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3NlLXdlYmF1dGhuLWFsZ29yaXRobXMtMDcjc2VjdGlvbi01 LjIgYWRkcyB0aGUgcmVxdWVzdGVkIGNsYXJpZmljYXRpb24gdGhhdCBTSEEtMjU2LCBTSEEtMzg0 LCBhbmQgU0hBLTUxMiBhcmUgdGhlIFNIQS0yIGhhc2ggZnVuY3Rpb25zLg0KDQoJCQkJLS0gTWlr ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTGluZGEgRHVuYmFyIDxsaW5k YS5kdW5iYXJAZnV0dXJld2VpLmNvbT4gDQpTZW50OiBXZWRuZXNkYXksIE1heSAyNywgMjAyMCA1 OjIyIFBNDQpUbzogTWF0dGhldyBBLiBNaWxsZXIgPGxpbnV4d29sZitpZXRmQG91dGVyLXBsYW5l cy5uZXQ+OyBzZWNkaXJAaWV0Zi5vcmcNCkNjOiBjb3NlQGlldGYub3JnOyBkcmFmdC1pZXRmLWNv c2Utd2ViYXV0aG4tYWxnb3JpdGhtcy5hbGxAaWV0Zi5vcmc7IGxhc3QtY2FsbEBpZXRmLm9yZw0K U3ViamVjdDogW0VYVEVSTkFMXSBSRTogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQt aWV0Zi1jb3NlLXdlYmF1dGhuLWFsZ29yaXRobXMtMDYNCg0KTWF0dGhldywgDQoNClRoYXQgaXMg d2hhdCBJIHdhcyB0aGlua2luZy4gQ2FuIHlvdSBhZGQgYSBzZW50ZW5jZSBpbiBTZWN0aW9uIDUu MiB0byBzYXkgdGhhdCB0aGlzIGlzIGZvciB0aGUgY29sbGVjdGlvbiBvZiBTSEEtMjU2LCBTSEEt Mzg0LCBTSEEtNTEyIGFsZ29yaXRobXM/IA0KT3RoZXJ3aXNlLCB0aGUgdHdvIHNlY3Rpb25zIG9m IHRoZSBkb2N1bWVudCBkb24ndCAgbWF0Y2guIA0KDQpUaGFuayB5b3UNCkxpbmRhIER1bmJhcg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWF0dGhldyBBLiBNaWxsZXIgPGxp bnV4d29sZitpZXRmQG91dGVyLXBsYW5lcy5uZXQ+DQpTZW50OiBXZWRuZXNkYXksIE1heSAyNywg MjAyMCA0OjU1IFBNDQpUbzogTGluZGEgRHVuYmFyIDxsaW5kYS5kdW5iYXJAZnV0dXJld2VpLmNv bT47IHNlY2RpckBpZXRmLm9yZw0KQ2M6IGNvc2VAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY29zZS13 ZWJhdXRobi1hbGdvcml0aG1zLmFsbEBpZXRmLm9yZzsgbGFzdC1jYWxsQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb3NlLXdlYmF1 dGhuLWFsZ29yaXRobXMtMDYNCg0KSGVsbG8gTGluZGEsDQoNClRoYW5rcyBmb3IgdGhlIHJldmll dy4gIFNwZWFraW5nIG9uIHRoZSBhdXRob3IncyBiZWhhbGYsIFNIQS0yIGlzIGRlZmluZWQgYXMg dGhlIGNvbGxlY3Rpb24gb2YgaGFzaCBhbGdvcml0aG1zLCBpbmNsdWRpbmcgYWxsIG9mIHRob3Nl IGNpdGVkIChTSEEtMjU2LCBTSEEtMzg0LCBTSEEtNTEyKS4gIERvIHlvdSBiZWxpZXZlIGl0IGlz IGNyaXRpY2FsIHRvIGNhbGwgdGhpcyBvdXQgZXhwbGljaXRseT8NCg0KDQotIG0mbQ0KDQpNYXR0 aGV3IEEuIE1pbGxlcg0KT24gMjAvMDUvMjYgMTc6NTEsIExpbmRhIER1bmJhciB2aWEgRGF0YXRy YWNrZXIgd3JvdGU6DQo+IFJldmlld2VyOiBMaW5kYSBEdW5iYXINCj4gUmV2aWV3IHJlc3VsdDog Tm90IFJlYWR5DQo+IA0KPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9m IHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIA0KPiBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcg YWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgDQo+IElFU0cuICBUaGVz ZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUg c2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuDQo+ICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFp cnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSANCj4gYW55IG90aGVyICBs YXN0IGNhbGwgY29tbWVudHMuDQo+IA0KPiBUaGlzIGRvY3VtZW50IGlzIHRvIGxpc3QgZG93biB0 aGUgQ09TRSZKT1NFIEFsZ29yaXRobXMgdG8gYmUgDQo+IHJlZ2lzdGVyZWQgdG8gSUFOQS4gQnV0 IGl0IHNlZW1zIHRoZSBkZXNjcmlwdGlvbiBpcyBub3QgY29tcGxldGUuIEluIA0KPiB0aGUgU2Vj dGlvbiAyOiBhbW9uZyB0aGUNCj4gNCBhbGdvcml0aG1zIGxpc3RlZCB1bmRlciBSU0FTU0EtUEtD UzEtdjFfNSwgdGhyZWUgYXJlIE5PVCANCj4gcmVjb21tZW5kZWQsIG9uZSBpcyBkZXByZWNhdGVk LiBVbmRlciB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbiANCj4gKFNlY3Rpb24gNSksIFNlY3Rp b24gNS4yIGRlc2NyaWJlcyB3aHkgU0hBLTIgaXMgIk5vdCBSZWNvbW1lbmRlZCIsIA0KPiBTZWN0 aW9uIDUuMyBkZXNjcmliZXMgd2h5IFNIQS0xIGlzICJEZXByZWNhdGVkIi4gIFdoYXQgYWJvdXQg dGhlIA0KPiBkZXNjcmlwdGlvbiBvbiB3aHkgU0hBLTUxMiwgIFNIQS0zODQsIGFuZCBTSEEtMjU2 IGFyZSBub3QgcmVjb21tZW5kZWQ/ICBJcyB0aGUgbWlzc2luZyBkZXNjcmlwdGlvbiBpbnRlbmRl ZD8NCj4gDQo+IEJlc3QgUmVnYXJkcywNCj4gDQo+IExpbmRhIER1bmJhcg0KPiANCj4gDQo+IA0K From nobody Wed Jun 3 09:57:16 2020 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 5D3C03A09C9; Wed, 3 Jun 2020 09:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 dlshEpXGYai6; Wed, 3 Jun 2020 09:57:09 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 913533A08E4; Wed, 3 Jun 2020 09:57:09 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 053Gt9uW026715; Wed, 3 Jun 2020 17:57:02 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=o4vJoS4sR6va7HYOYXz0Bzm7vKQGBxgGgiMrJcALpQk=; b=LK3SVrlF+ZmY9VeJuy2tEoyiERz1WtaSai8JIGk+bnxD+uvz83wBsS/jWxgqez1Y70il cOiZChU9VXaY88ETTpUiOUr9SmxFl2JkWEd9562PuWL1DAAL13vCuRL0+eB7LKqqWpZL apJSwEkw8TfpSvTP2L2CjO338KCBf7azSgqIiufBCkjQhs56joKlaa9IgYqWkZyNcUV0 mC2L6SJI32L5oDDWLtZMNn+7KB3mStqVVazi8LQ+pzTwRNtWT6QvxSA/eDYAMDKZl7Op poR/gZv2RkjabchaBw5/SQo7tuXsMzdo71mKxc/u4oFa9DcmqUcn+7YOR9J0A6R550N0 jQ== Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 31d8rum1sw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Jun 2020 17:57:02 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 053Gleuq016420; Wed, 3 Jun 2020 12:57:01 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.112]) by prod-mail-ppoint4.akamai.com with ESMTP id 31bjtvne9t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 03 Jun 2020 12:57:00 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Jun 2020 11:56:59 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.006; Wed, 3 Jun 2020 11:56:59 -0500 From: "Salz, Rich" To: Mike Jones , Eric Rescorla CC: "last-call@ietf.org" , Jim Schaad , "cose@ietf.org" Thread-Topic: [COSE] [Last-Call] Last Call: (COSE and JOSE Registrations for WebAuthn Algorithms) to Proposed Standard Thread-Index: AdYxXK5oD21D1OE4Q7aiB+KOED7TnwIaeXCgAAJy8wA= Date: Wed, 3 Jun 2020 16:56:58 +0000 Message-ID: <29A8131D-0E3B-41EA-9A4B-6EA05D94DEB8@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.118.24] Content-Type: multipart/alternative; boundary="_000_29A8131D0E3B41EA9A4B6EA05D94DEB8akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-03_13:2020-06-02, 2020-06-03 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2006030132 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-03_13:2020-06-02, 2020-06-03 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 spamscore=0 adultscore=0 phishscore=0 clxscore=1011 impostorscore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 cotscore=-2147483648 mlxlogscore=999 priorityscore=1501 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006030133 Archived-At: Subject: Re: [COSE] [Last-Call] Last Call: (COSE and JOSE Registrations for WebAuthn Algorithms) to Proposed Standard X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 16:57:11 -0000 --_000_29A8131D0E3B41EA9A4B6EA05D94DEB8akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IGZvciBhY2NvbW1vZGF0aW5nIHRoZSBmZWVkYmFjayENCg0KRnJvbTogTWlrZSBK b25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBKdW5l IDMsIDIwMjAgYXQgMTI6NTAgUE0NClRvOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+LCBS aWNoIFNhbHogPHJzYWx6QGFrYW1haS5jb20+DQpDYzogImxhc3QtY2FsbEBpZXRmLm9yZyIgPGxh c3QtY2FsbEBpZXRmLm9yZz4sICJpZXRmQGF1Z3VzdGNlbGxhcnMuY29tIiA8aWV0ZkBhdWd1c3Rj ZWxsYXJzLmNvbT4sICJjb3NlQGlldGYub3JnIiA8Y29zZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJF OiBbQ09TRV0gW0xhc3QtQ2FsbF0gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1jb3NlLXdlYmF1dGhu LWFsZ29yaXRobXMtMDUudHh0PiAoQ09TRSBhbmQgSk9TRSBSZWdpc3RyYXRpb25zIGZvciBXZWJB dXRobiBBbGdvcml0aG1zKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KDQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jb3NlLXdlYmF1dGhuLWFsZ29yaXRobXMtMDc8aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRm Lm9yZ19odG1sX2RyYWZ0LTJEaWV0Zi0yRGNvc2UtMkR3ZWJhdXRobi0yRGFsZ29yaXRobXMtMkQw NyZkPUR3TUdhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj00TE0wR2JSMGg5RnZ4ODZGdHNL SS13Jm09RHZmc0xfOUI4bHhza1FRbno1bjFoVlpkeE9jbWNzcGw5RUxMTW9KWWg5cyZzPWVzamhl bEtOQ09hQXN0bXhIenlDQkpsZlNremM1WE1SRFR4ZWE5SHVYTXcmZT0+IG5vdyByZWdpc3RlcnMg c2VjcDI1NmsxIGFuZCBFUzI1NksgYXMg4oCcUmVjb21tZW5kZWQ6IE5v4oCdLCBwZXIgeW91ciBy ZXF1ZXN0cy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogTWlrZSBKb25lcw0KU2VudDogU2F0dXJkYXksIE1h eSAyMywgMjAyMCA0OjQ5IFBNDQpUbzogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPjsgcnNh bHpAYWthbWFpLmNvbQ0KQ2M6IGxhc3QtY2FsbEBpZXRmLm9yZzsgSmltIFNjaGFhZCA8aWV0ZkBh dWd1c3RjZWxsYXJzLmNvbT47IGNvc2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ09TRV0gW0xh c3QtQ2FsbF0gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1jb3NlLXdlYmF1dGhuLWFsZ29yaXRobXMt MDUudHh0PiAoQ09TRSBhbmQgSk9TRSBSZWdpc3RyYXRpb25zIGZvciBXZWJBdXRobiBBbGdvcml0 aG1zKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KDQpJIGNhbiBjZXJ0YWlubHkgY2hhbmdlIHRoZSBD T1NFIHJlY29tbWVuZGF0aW9uIHN0YXR1cyBmcm9tIFllcyB0byBObywgaWYgdGhhdOKAmXMgdGhl IHByZXZhaWxpbmcgb3Bpbmlvbi4gIFRob3NlIHRoYXQgaGF2ZSBkZWNpZGVkIHRvIHVzZSBzZWNw MjU2azEgb3ZlciB0aGUgTklTVCBhbmQgMjU1MTkgY3VydmVzIHdpbGwgbGlrZWx5IGNvbnRpbnVl IHRvIGRvIHNvIG5vIG1hdHRlciB3aGF0IHdlIGRlY2lkZSBpbiB0aGlzIHJlZ2FyZC4NCg0KSeKA mWxsIHdhaXQgdW50aWwgdGhlIGxhc3QgY2FsbCBleHBpcmVzIG9uIFdlZG5lc2RheSB0byBzZWUg d2hhdCBvdGhlciBjb21tZW50cyBtYXkgY29tZSBpbiBhbmQgdGhlbiBwdWJsaXNoIGFuIHVwZGF0 ZWQgZHJhZnQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBUaGFua3MgYWxsLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogQ09TRSA8Y29zZS1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgRXJp YyBSZXNjb3JsYQ0KU2VudDogU2F0dXJkYXksIE1heSAyMywgMjAyMCAyOjM2IFBNDQpUbzogU2Fs eiwgUmljaCA8cnNhbHo9NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpyc2Fsej00 MGFrYW1haS5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KQ2M6IGxhc3QtY2FsbEBpZXRmLm9yZzxtYWls dG86bGFzdC1jYWxsQGlldGYub3JnPjsgSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNv bTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4+OyBjb3NlQGlldGYub3JnPG1haWx0bzpj b3NlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDT1NFXSBbTGFzdC1DYWxsXSBMYXN0IENhbGw6 IDxkcmFmdC1pZXRmLWNvc2Utd2ViYXV0aG4tYWxnb3JpdGhtcy0wNS50eHQ+IChDT1NFIGFuZCBK T1NFIFJlZ2lzdHJhdGlvbnMgZm9yIFdlYkF1dGhuIEFsZ29yaXRobXMpIHRvIFByb3Bvc2VkIFN0 YW5kYXJkDQoNCkdvb2QgY2F0Y2guIFdlIGRlZmluaXRlbHkgc2hvdWxkIG5vdCBiZSByZWNvbW1l bmRpbmcgc2VwMjU2azEuDQoNCi1Fa3INCg0KDQpPbiBTYXQsIE1heSAyMywgMjAyMCBhdCAxOjMw IFBNIFNhbHosIFJpY2ggPHJzYWx6PTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86 NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQo+ICAgIEkgYmVsaWV2ZSB0aGF0 IHRoZSBJRVNHIG5lZWRzIHRvIGRlYmF0ZSBpZiB0aGlzIGRvY3VtZW50IHNob3VsZCBiZSB0aGUg b25lDQogICAgd2hpY2ggbWFrZXMgdGhlIHNlY3AyNTZrMSBjdXJ2ZSBhIHJlY29tbWVuZGVkIElF VEYgY3VydmUgdG8gdXNlLg0KDQpBIGdvb2QgcG9pbnQsIGFsYmVpdCBzbGlnaHRseSBzdWJ0bGUu ICArMS4NCg0KDQoNCi0tDQpsYXN0LWNhbGwgbWFpbGluZyBsaXN0DQpsYXN0LWNhbGxAaWV0Zi5v cmc8bWFpbHRvOmxhc3QtY2FsbEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbGFzdC1jYWxsPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbGFzdC0yRGNh bGwmZD1Ed01HYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9NExNMEdiUjBoOUZ2eDg2RnRz S0ktdyZtPUR2ZnNMXzlCOGx4c2tRUW56NW4xaFZaZHhPY21jc3BsOUVMTE1vSlloOXMmcz0zWWt3 c2F3bDQ1XzJCNVVFSEpZdjNWaTd3R2NjRGZwcnAtMy1zbFl6TDRnJmU9Pg0K --_000_29A8131D0E3B41EA9A4B6EA05D94DEB8akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IGZvciBhY2NvbW1vZGF0aW5nIHRoZSBmZWVkYmFjayE8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk1pa2UgSm9uZXMgJmx0 O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVz ZGF5LCBKdW5lIDMsIDIwMjAgYXQgMTI6NTAgUE08YnI+DQo8Yj5UbzogPC9iPkVyaWMgUmVzY29y bGEgJmx0O2VrckBydGZtLmNvbSZndDssIFJpY2ggU2FseiAmbHQ7cnNhbHpAYWthbWFpLmNvbSZn dDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O2xhc3QtY2FsbEBpZXRmLm9yZyZxdW90OyAmbHQ7bGFz dC1jYWxsQGlldGYub3JnJmd0OywgJnF1b3Q7aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSZxdW90OyAm bHQ7aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSZndDssICZxdW90O2Nvc2VAaWV0Zi5vcmcmcXVvdDsg Jmx0O2Nvc2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJFOiBbQ09TRV0gW0xh c3QtQ2FsbF0gTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtaWV0Zi1jb3NlLXdlYmF1dGhuLWFsZ29yaXRo bXMtMDUudHh0Jmd0OyAoQ09TRSBhbmQgSk9TRSBSZWdpc3RyYXRpb25zIGZvciBXZWJBdXRobiBB bGdvcml0aG1zKSB0byBQcm9wb3NlZCBTdGFuZGFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJh ZnQtMkRpZXRmLTJEY29zZS0yRHdlYmF1dGhuLTJEYWxnb3JpdGhtcy0yRDA3JmFtcDtkPUR3TUdh USZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPTRMTTBHYlIwaDlGdng4NkZ0c0tJ LXcmYW1wO209RHZmc0xfOUI4bHhza1FRbno1bjFoVlpkeE9jbWNzcGw5RUxMTW9KWWg5cyZhbXA7 cz1lc2poZWxLTkNPYUFzdG14SHp5Q0JKbGZTa3pjNVhNUkRUeGVhOUh1WE13JmFtcDtlPSI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29zZS13ZWJhdXRobi1hbGdvcml0 aG1zLTA3PC9hPg0KIG5vdyByZWdpc3RlcnMgc2VjcDI1NmsxIGFuZCBFUzI1NksgYXMg4oCcUmVj b21tZW5kZWQ6IE5v4oCdLCBwZXIgeW91ciByZXF1ZXN0cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE1pa2UgSm9uZXMgPGJy Pg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBNYXkgMjMsIDIwMjAgNDo0OSBQTTxicj4NCjxiPlRv OjwvYj4gRXJpYyBSZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0OzsgcnNhbHpAYWthbWFpLmNv bTxicj4NCjxiPkNjOjwvYj4gbGFzdC1jYWxsQGlldGYub3JnOyBKaW0gU2NoYWFkICZsdDtpZXRm QGF1Z3VzdGNlbGxhcnMuY29tJmd0OzsgY29zZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW0NPU0VdIFtMYXN0LUNhbGxdIExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtY29zZS13 ZWJhdXRobi1hbGdvcml0aG1zLTA1LnR4dCZndDsgKENPU0UgYW5kIEpPU0UgUmVnaXN0cmF0aW9u cyBmb3IgV2ViQXV0aG4gQWxnb3JpdGhtcykgdG8gUHJvcG9zZWQgU3RhbmRhcmQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij5JIGNhbiBjZXJ0YWlubHkgY2hhbmdlIHRoZSBDT1NFIHJlY29tbWVuZGF0aW9uIHN0YXR1cyBm cm9tIFllcyB0byBObywgaWYgdGhhdOKAmXMgdGhlIHByZXZhaWxpbmcgb3Bpbmlvbi4mbmJzcDsg VGhvc2UgdGhhdCBoYXZlIGRlY2lkZWQgdG8gdXNlIHNlY3AyNTZrMSBvdmVyIHRoZSBOSVNUIGFu ZCAyNTUxOSBjdXJ2ZXMgd2lsbCBsaWtlbHkgY29udGludWUgdG8gZG8gc28gbm8NCiBtYXR0ZXIg d2hhdCB3ZSBkZWNpZGUgaW4gdGhpcyByZWdhcmQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj5J4oCZbGwgd2FpdCB1bnRpbCB0aGUgbGFzdCBjYWxsIGV4cGlyZXMgb24gV2Vk bmVzZGF5IHRvIHNlZSB3aGF0IG90aGVyIGNvbW1lbnRzIG1heSBjb21lIGluIGFuZCB0aGVuIHB1 Ymxpc2ggYW4gdXBkYXRlZCBkcmFmdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgYWxsLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0g TWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gQ09T RSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvc2UtYm91bmNlc0BpZXRmLm9yZyI+Y29zZS1ib3VuY2Vz QGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBSZXNjb3JsYTxicj4N CjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTWF5IDIzLCAyMDIwIDI6MzYgUE08YnI+DQo8Yj5Ubzo8 L2I+IFNhbHosIFJpY2ggJmx0OzxhIGhyZWY9Im1haWx0bzpyc2Fsej00MGFrYW1haS5jb21AZG1h cmMuaWV0Zi5vcmciPnJzYWx6PTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86bGFzdC1jYWxsQGlldGYub3JnIj5sYXN0LWNh bGxAaWV0Zi5vcmc8L2E+OyBKaW0gU2NoYWFkICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBhdWd1 c3RjZWxsYXJzLmNvbSI+aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0i bWFpbHRvOmNvc2VAaWV0Zi5vcmciPmNvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbQ09TRV0gW0xhc3QtQ2FsbF0gTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtaWV0Zi1jb3Nl LXdlYmF1dGhuLWFsZ29yaXRobXMtMDUudHh0Jmd0OyAoQ09TRSBhbmQgSk9TRSBSZWdpc3RyYXRp b25zIGZvciBXZWJBdXRobiBBbGdvcml0aG1zKSB0byBQcm9wb3NlZCBTdGFuZGFyZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R29vZCBjYXRjaC4gV2UgZGVm aW5pdGVseSBzaG91bGQgbm90IGJlIHJlY29tbWVuZGluZyBzZXAyNTZrMS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgTWF5 IDIzLCAyMDIwIGF0IDE6MzAgUE0gU2FseiwgUmljaCAmbHQ7cnNhbHo9PGEgaHJlZj0ibWFpbHRv OjQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZyI+NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3Jn PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OyZuYnNwOyAmbmJzcDsgSSBiZWxpZXZlIHRoYXQgdGhlIElFU0cgbmVlZHMgdG8gZGViYXRlIGlm IHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIHRoZSBvbmU8YnI+DQombmJzcDsgJm5ic3A7IHdoaWNo IG1ha2VzIHRoZSBzZWNwMjU2azEgY3VydmUgYSByZWNvbW1lbmRlZCBJRVRGIGN1cnZlIHRvIHVz ZS48YnI+DQo8YnI+DQpBIGdvb2QgcG9pbnQsIGFsYmVpdCBzbGlnaHRseSBzdWJ0bGUuJm5ic3A7 ICYjNDM7MS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+DQpsYXN0LWNhbGwgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmxhc3QtY2FsbEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmxhc3QtY2FsbEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2xhc3QtMkRjYWxsJmFtcDtkPUR3TUdhUSZhbXA7Yz05NlpiWlpjYU1GNHcw RjRqcE42TFpnJmFtcDtyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmYW1wO209RHZmc0xfOUI4bHhz a1FRbno1bjFoVlpkeE9jbWNzcGw5RUxMTW9KWWg5cyZhbXA7cz0zWWt3c2F3bDQ1XzJCNVVFSEpZ djNWaTd3R2NjRGZwcnAtMy1zbFl6TDRnJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGFzdC1jYWxsPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_29A8131D0E3B41EA9A4B6EA05D94DEB8akamaicom_-- From nobody Wed Jun 3 12:49:03 2020 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 A5D763A0EE1; Wed, 3 Jun 2020 12:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=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=futurewei.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 y9-6Idoai1B2; Wed, 3 Jun 2020 12:48:59 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2102.outbound.protection.outlook.com [40.107.92.102]) (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 F30FE3A0EE0; Wed, 3 Jun 2020 12:48:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QxWpiNrTLDLbtUrmA4ye5eGe6lCwGxl035MNnhOMIQjgeOoyKGkYQZsixd9u4CIyyzjTh+bpP+6NVaCMDqHt3qYt673DwYFl/veicRpJc7aVteVS1syFg4FEy4rdy2iPkreSLitdpIY85LUqrhW4ochKGgRPC3S+SdiABjBDOpOCLxO1/ftoXY68EN+nYx3BN58wDiqJxA322JcRSwIl+bjm7O0C/4OAIxKtSkKrSL01ln4V8LOer4ASFwOuNj2rcNJGT8p4nDKvQIZ/IepYdJo8GuVNdBeQUlbHpOCnUdQoUzbjf+Zt7qAyS2S6NMIRsykK7Siis0gWkJY5c/7MMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pkvndGe5dNzAFO4eDi1s75MdfMwfNOsye2WOzNLnKXs=; b=csVkpiXYZ8+tqm5q1VhQeYxgWBKLd+yY4AaolBIIKzzH6jTIZIPShxJGFyl19PkO6HoiESUYeaADvHdejGBzITtcnwCCgTkL4U+vtmZsJm09irDDfpL+wQQM0UZtrU3aefngNzfXa/yaoemOZLnhlHMOw/GG3LhrPOF9W5Ab9e7LXrlU8+zAT9iJxelTRYpWIS5njD4GzhuAnSah0OwvwPOTuw1l6kZEPfteiirnyXBW5e1vp8+zTDZI8RgW2VSrbBY2izikD6Bd9shi9G4Ot9QMN0FFeoQ+kSgI7YyEHpcvlDf1ym/P9RFKhcarQ6XsyFi4oaqJr6AIYGhf5Bw2sQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pkvndGe5dNzAFO4eDi1s75MdfMwfNOsye2WOzNLnKXs=; b=lIRRvmJRsiyMRwVm+d7L7b03jXXzA+erJDhs5nggahSFCt0inzqXPlBck0dHqYq/a+WBcMdbPhUGuZ6B3GdtTTGyThOPeTHK1UUB2gmgbL22XhPtbIE7VSG7ax8toU8iHT71biJw+GYKnNlzLXmvI3i3/cXk3m6pEJTURIqKdD8= Received: from DM6PR13MB2330.namprd13.prod.outlook.com (2603:10b6:5:cc::16) by DM6PR13MB2874.namprd13.prod.outlook.com (2603:10b6:5:144::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.12; Wed, 3 Jun 2020 19:48:56 +0000 Received: from DM6PR13MB2330.namprd13.prod.outlook.com ([fe80::95a6:b46f:dc31:3fdd]) by DM6PR13MB2330.namprd13.prod.outlook.com ([fe80::95a6:b46f:dc31:3fdd%7]) with mapi id 15.20.3045.024; Wed, 3 Jun 2020 19:48:56 +0000 From: Linda Dunbar To: Mike Jones , "Matthew A. Miller" , "secdir@ietf.org" CC: "cose@ietf.org" , "draft-ietf-cose-webauthn-algorithms.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-cose-webauthn-algorithms-06 Thread-Index: AQHWNHF88QTcU9SYR0Gbkbt6ssDowai8okawgAqDUQCAADFioA== Date: Wed, 3 Jun 2020 19:48:56 +0000 Message-ID: References: <159053708200.16306.10159573848968846851@ietfa.amsl.com> In-Reply-To: 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_ActionId=efc2d60a-0ed4-43b6-8f8a-000013c750c0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-03T16:50:06Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [72.180.73.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 01afa5be-88d5-4943-b2c8-08d807f726e8 x-ms-traffictypediagnostic: DM6PR13MB2874: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 04238CD941 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bRhi0Bbd/N+/DXK/elaq2duyZMSKsiWtDda8vg960Pn95TfVoqmBqwkUMx4bXl0NM5tvoXUdw63QrZcgJ+yzN4338CL89b8lo1L0wYT9TKrYBlMI2BG3uLsMxjjtVLai6hVVoaz4OE9FBK5W8Tetn8W+5WbGddY1Tn709uRWvN0VM7ts7L0B+Iu9UXEVoyIfUx5Up+gsaxHTqTDBmSvTi9KNSMmUVz5JUZaRILmv2qMd5aZWY7/LFcKRmVMoSCEcHyJyF8CJw/9qUDer/n7vz7oQU6id7jfPCPx75xMURmbcfQRil5QBCpbQUeQfxqZODgMusyRb94RdQ7h0KJgGsxlfjImrpwG9iKGwH4DYfF1yLoIDNkHvEThjuJzEPU8I3jf9Rk5/9+X4hWHMsR2DTw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR13MB2330.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(346002)(366004)(136003)(39850400004)(55016002)(2906002)(9686003)(8676002)(86362001)(64756008)(966005)(71200400001)(83380400001)(45080400002)(7696005)(66476007)(66446008)(44832011)(66946007)(66556008)(5660300002)(8936002)(316002)(6506007)(478600001)(33656002)(54906003)(110136005)(26005)(53546011)(186003)(52536014)(76116006)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: WER4U6aAKRAOsTNPApORATawod+jbsKBR6Z4NDc4cyuva4s3xmgfMTDKK7qhclUHfnfMBTHmJKYdoi+SWdMIX91IWR0J64RcjHumnfPCGRqP8vkfrjMMJFTXAtqb2VxSVqHiO5TJn6sm9jm+0nh/k8bDaeYUP/obw0CQkOWoPjmpAgoKQ7VCBQ+cqdqNAI2YYNHR4WLwm8V/p+quHdjV6FCOHvqLfDYzuz6pVMtnD1m5FtuitMVuq+RjjiRsC/q2lpfBZpCk7TII8RwXh4CGBTGpFll+qR626WpysxGftEHljyI3wcP/XcC2Wn7DHf3fzKf9nPfVm7j4/id6A22rlCvpB7aEawNt7mZJ70edzfB8brQoV3hewWlYg/2QJ6+HoPcSwuxj7rNyzEEd85MGAgWfoC8WGPSDhrwpgFNjn/hlMK0kEYdmYgZ0ctoMQLtmlGNqAqldLyqVfDSrWNaYgL0ioUjKfpsmL1kBhpmoA8c= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: 01afa5be-88d5-4943-b2c8-08d807f726e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2020 19:48:56.3276 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vrTTdsVEMucKhZoPj5tWGjfrKjCe8z/SH11fC/sEYSSYhHOJ/TpFQep4xkaz5yHsbggG0i9751WnzoV/88Ue2g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB2874 Archived-At: Subject: Re: [COSE] Secdir last call review of draft-ietf-cose-webauthn-algorithms-06 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 19:49:01 -0000 TWlrZSwNCg0KVGhhbmsgeW91IGZvciB0aGUgY2hhbmdlLg0KDQpMaW5kYQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPiANClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAzLCAyMDIwIDExOjUyIEFNDQpUbzogTGlu ZGEgRHVuYmFyIDxsaW5kYS5kdW5iYXJAZnV0dXJld2VpLmNvbT47IE1hdHRoZXcgQS4gTWlsbGVy IDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0Pjsgc2VjZGlyQGlldGYub3JnDQpDYzog Y29zZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb3NlLXdlYmF1dGhuLWFsZ29yaXRobXMuYWxsQGll dGYub3JnOyBsYXN0LWNhbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBTZWNkaXIgbGFzdCBjYWxs IHJldmlldyBvZiBkcmFmdC1pZXRmLWNvc2Utd2ViYXV0aG4tYWxnb3JpdGhtcy0wNg0KDQpUaGFu a3MgYWdhaW4gZm9yIHlvdXIgcmV2aWV3LCBMaW5kYS4gIGh0dHBzOi8vbmFtMTEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3Jn JTJGaHRtbCUyRmRyYWZ0LWlldGYtY29zZS13ZWJhdXRobi1hbGdvcml0aG1zLTA3JTIzc2VjdGlv bi01LjImYW1wO2RhdGE9MDIlN0MwMSU3Q2xpbmRhLmR1bmJhciU0MGZ1dHVyZXdlaS5jb20lN0M0 MDI1ZDM4ODg0YWU0ZDFhOWE1YjA4ZDgwN2RlNjU2MiU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2Ex ZDU1OTFmZWRjJTdDMSU3QzElN0M2MzcyNjc5OTkwNDg2MzUzMjgmYW1wO3NkYXRhPW9Hc2Fmazgw ZkFGeGdmTWZ4M3dVUHdsclZleGpHeVZ2c0hEWmZyS2RweW8lM0QmYW1wO3Jlc2VydmVkPTAgYWRk cyB0aGUgcmVxdWVzdGVkIGNsYXJpZmljYXRpb24gdGhhdCBTSEEtMjU2LCBTSEEtMzg0LCBhbmQg U0hBLTUxMiBhcmUgdGhlIFNIQS0yIGhhc2ggZnVuY3Rpb25zLg0KDQoJCQkJLS0gTWlrZQ0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTGluZGEgRHVuYmFyIDxsaW5kYS5kdW5i YXJAZnV0dXJld2VpLmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDI3LCAyMDIwIDU6MjIgUE0N ClRvOiBNYXR0aGV3IEEuIE1pbGxlciA8bGludXh3b2xmK2lldGZAb3V0ZXItcGxhbmVzLm5ldD47 IHNlY2RpckBpZXRmLm9yZw0KQ2M6IGNvc2VAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY29zZS13ZWJh dXRobi1hbGdvcml0aG1zLmFsbEBpZXRmLm9yZzsgbGFzdC1jYWxsQGlldGYub3JnDQpTdWJqZWN0 OiBbRVhURVJOQUxdIFJFOiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWNv c2Utd2ViYXV0aG4tYWxnb3JpdGhtcy0wNg0KDQpNYXR0aGV3LCANCg0KVGhhdCBpcyB3aGF0IEkg d2FzIHRoaW5raW5nLiBDYW4geW91IGFkZCBhIHNlbnRlbmNlIGluIFNlY3Rpb24gNS4yIHRvIHNh eSB0aGF0IHRoaXMgaXMgZm9yIHRoZSBjb2xsZWN0aW9uIG9mIFNIQS0yNTYsIFNIQS0zODQsIFNI QS01MTIgYWxnb3JpdGhtcz8gDQpPdGhlcndpc2UsIHRoZSB0d28gc2VjdGlvbnMgb2YgdGhlIGRv Y3VtZW50IGRvbid0ICBtYXRjaC4gDQoNClRoYW5rIHlvdQ0KTGluZGEgRHVuYmFyDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXR0aGV3IEEuIE1pbGxlciA8bGludXh3b2xm K2lldGZAb3V0ZXItcGxhbmVzLm5ldD4NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDI3LCAyMDIwIDQ6 NTUgUE0NClRvOiBMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJhckBmdXR1cmV3ZWkuY29tPjsgc2Vj ZGlyQGlldGYub3JnDQpDYzogY29zZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb3NlLXdlYmF1dGhu LWFsZ29yaXRobXMuYWxsQGlldGYub3JnOyBsYXN0LWNhbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWNvc2Utd2ViYXV0aG4tYWxn b3JpdGhtcy0wNg0KDQpIZWxsbyBMaW5kYSwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgU3Bl YWtpbmcgb24gdGhlIGF1dGhvcidzIGJlaGFsZiwgU0hBLTIgaXMgZGVmaW5lZCBhcyB0aGUgY29s bGVjdGlvbiBvZiBoYXNoIGFsZ29yaXRobXMsIGluY2x1ZGluZyBhbGwgb2YgdGhvc2UgY2l0ZWQg KFNIQS0yNTYsIFNIQS0zODQsIFNIQS01MTIpLiAgRG8geW91IGJlbGlldmUgaXQgaXMgY3JpdGlj YWwgdG8gY2FsbCB0aGlzIG91dCBleHBsaWNpdGx5Pw0KDQoNCi0gbSZtDQoNCk1hdHRoZXcgQS4g TWlsbGVyDQpPbiAyMC8wNS8yNiAxNzo1MSwgTGluZGEgRHVuYmFyIHZpYSBEYXRhdHJhY2tlciB3 cm90ZToNCj4gUmV2aWV3ZXI6IExpbmRhIER1bmJhcg0KPiBSZXZpZXcgcmVzdWx0OiBOb3QgUmVh ZHkNCj4gDQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNl Y3VyaXR5IGRpcmVjdG9yYXRlJ3MgDQo+IG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVU RiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSANCj4gSUVTRy4gIFRoZXNlIGNvbW1l bnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0 eSBhcmVhIGRpcmVjdG9ycy4NCj4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91 bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIA0KPiBhbnkgb3RoZXIgIGxhc3QgY2Fs bCBjb21tZW50cy4NCj4gDQo+IFRoaXMgZG9jdW1lbnQgaXMgdG8gbGlzdCBkb3duIHRoZSBDT1NF JkpPU0UgQWxnb3JpdGhtcyB0byBiZSANCj4gcmVnaXN0ZXJlZCB0byBJQU5BLiBCdXQgaXQgc2Vl bXMgdGhlIGRlc2NyaXB0aW9uIGlzIG5vdCBjb21wbGV0ZS4gSW4gDQo+IHRoZSBTZWN0aW9uIDI6 IGFtb25nIHRoZQ0KPiA0IGFsZ29yaXRobXMgbGlzdGVkIHVuZGVyIFJTQVNTQS1QS0NTMS12MV81 LCB0aHJlZSBhcmUgTk9UIA0KPiByZWNvbW1lbmRlZCwgb25lIGlzIGRlcHJlY2F0ZWQuIFVuZGVy IHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9uIA0KPiAoU2VjdGlvbiA1KSwgU2VjdGlvbiA1LjIg ZGVzY3JpYmVzIHdoeSBTSEEtMiBpcyAiTm90IFJlY29tbWVuZGVkIiwgDQo+IFNlY3Rpb24gNS4z IGRlc2NyaWJlcyB3aHkgU0hBLTEgaXMgIkRlcHJlY2F0ZWQiLiAgV2hhdCBhYm91dCB0aGUgDQo+ IGRlc2NyaXB0aW9uIG9uIHdoeSBTSEEtNTEyLCAgU0hBLTM4NCwgYW5kIFNIQS0yNTYgYXJlIG5v dCByZWNvbW1lbmRlZD8gIElzIHRoZSBtaXNzaW5nIGRlc2NyaXB0aW9uIGludGVuZGVkPw0KPiAN Cj4gQmVzdCBSZWdhcmRzLA0KPiANCj4gTGluZGEgRHVuYmFyDQo+IA0KPiANCj4gDQo= From nobody Sat Jun 6 11:40:07 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 789243A0936; Sat, 6 Jun 2020 11:40:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Theresa Enghardt via Datatracker To: Cc: draft-ietf-cose-rfc8152bis-struct.all@ietf.org, cose@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159146880445.25410.16088064230335087109@ietfa.amsl.com> Reply-To: Theresa Enghardt Date: Sat, 06 Jun 2020 11:40:04 -0700 Archived-At: Subject: [COSE] Genart telechat review of draft-ietf-cose-rfc8152bis-struct-10 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 18:40:05 -0000 Reviewer: Theresa Enghardt Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-cose-rfc8152bis-struct-10 Reviewer: Theresa Enghardt Review Date: 2020-06-06 IETF LC End Date: 2020-05-29 IESG Telechat date: 2020-06-11 Summary: Thank you for addressing the comments in my last call review. I think this is now ready to be published. Major issues: None. Minor issues: None. Nits/editorial comments: None. From nobody Mon Jun 8 15:02:06 2020 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 1BD743A0819; Mon, 8 Jun 2020 15:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 2gZ-X0c0TH5X; Mon, 8 Jun 2020 15:02:02 -0700 (PDT) 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 E83DA3A081C; Mon, 8 Jun 2020 15:02:01 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jun 2020 15:01:55 -0700 From: Jim Schaad To: CC: Date: Mon, 8 Jun 2020 15:01:52 -0700 Message-ID: <004201d63de0$6cc61da0$465258e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdY9t1uc/2ioWMVyTwiC/DibhirO0g== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] Review draft-ietf-ace-mqtt-tls-profile-05 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 22:02:04 -0000 * Style Issue. "Abbreviations should be expanded in document title and upon first use in the document. Full expansion of the text should be followed by the abbreviation in parentheses." Some items such as TLS are considered to be known by everybody and thus do not need to be expanded. https://www.rfc-editor.org/materials/abbrev.expansion.txt contains both "known" and "unknown" abbreviations. (Yes this means you are going to have a really long title.) (I might argue that OASIS should be listed as well known.) * Section 1 - para 1 - Sentence two has a plurality mismatch between client and server. I think in this case server (and broker) should be pluralized. * Section 1.3 - Broker - s/publishes/publish/ The set of pluralized items seems to be too large by one. * Section 1.3 - I think we ought to define Session given that we no longer require that Clean Session be used. * Section 1.3 - I do not believe that CONNACK is always the first packet from the broker to a client. An AUTH message may be the first one. * Section 2.1 - para 3 s/the public key used by the RS/the public key to be used by the RS/ * Section 2.1 - I think (but am not sure) that we may need to do some registrations around the use of thumbprints in a confirmation claim. If I forget, please remind me to track this down. * Section 2.2.2 - para #1 - s/using client authentication/using server authentication/ If we are doing MQTT as the default then the server not the client is authenticated here. You may not want to have lost the potentially here. * Section 2.2.3 - I think that the client state MUST include the token and either the same token is supplied or a token with the same key is supplied in order to match with an existing state. * Section 6.2 - I think it makes sense to put in a note that between the fact that the server will disconnect on almost any error and is not required to keep session state between connections, clients need to make a greater effort to ensure that tokens remain valid and they do not attempt to publish to topics that they do not have permissions for. * Section 8 - The storage of tokens long term can be restricted to only current valid ones if an immediate validation of the token is done. This means that the RS spends time doing the validation, but does not need to consume memory. This is looking really good. I think we have only two technical issues open at this point. The question of registrations for hash identifications in confirmation claims and if changes to the default scope structure are to be done. Jim From nobody Mon Jun 8 16:11:48 2020 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 B48083A00B3 for ; Mon, 8 Jun 2020 16:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 AVCuQ0qjM8ON for ; Mon, 8 Jun 2020 16:11:45 -0700 (PDT) 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 B30E83A00B2 for ; Mon, 8 Jun 2020 16:11:44 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jun 2020 16:11:39 -0700 From: Jim Schaad To: References: <004201d63de0$6cc61da0$465258e0$@augustcellars.com> In-Reply-To: <004201d63de0$6cc61da0$465258e0$@augustcellars.com> Date: Mon, 8 Jun 2020 16:11:37 -0700 Message-ID: <004b01d63dea$2adbae50$80930af0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG0ulPj3r3WResRXVjgGN1MrXnGK6kSX52Q Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] FW: Review draft-ietf-ace-mqtt-tls-profile-05 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 23:11:47 -0000 Wrong list. -----Original Message----- From: COSE On Behalf Of Jim Schaad Sent: Monday, June 8, 2020 3:02 PM To: draft-ietf-ace-mqtt-tls-profile@ietf.org Cc: cose@ietf.org Subject: [COSE] Review draft-ietf-ace-mqtt-tls-profile-05 * Style Issue. "Abbreviations should be expanded in document title and upon first use in the document. Full expansion of the text should be followed by the abbreviation in parentheses." Some items such as TLS are considered to be known by everybody and thus do not need to be expanded. https://www.rfc-editor.org/materials/abbrev.expansion.txt contains both "known" and "unknown" abbreviations. (Yes this means you are going to have a really long title.) (I might argue that OASIS should be listed as well known.) * Section 1 - para 1 - Sentence two has a plurality mismatch between client and server. I think in this case server (and broker) should be pluralized. * Section 1.3 - Broker - s/publishes/publish/ The set of pluralized items seems to be too large by one. * Section 1.3 - I think we ought to define Session given that we no longer require that Clean Session be used. * Section 1.3 - I do not believe that CONNACK is always the first packet from the broker to a client. An AUTH message may be the first one. * Section 2.1 - para 3 s/the public key used by the RS/the public key to be used by the RS/ * Section 2.1 - I think (but am not sure) that we may need to do some registrations around the use of thumbprints in a confirmation claim. If I forget, please remind me to track this down. * Section 2.2.2 - para #1 - s/using client authentication/using server authentication/ If we are doing MQTT as the default then the server not the client is authenticated here. You may not want to have lost the potentially here. * Section 2.2.3 - I think that the client state MUST include the token and either the same token is supplied or a token with the same key is supplied in order to match with an existing state. * Section 6.2 - I think it makes sense to put in a note that between the fact that the server will disconnect on almost any error and is not required to keep session state between connections, clients need to make a greater effort to ensure that tokens remain valid and they do not attempt to publish to topics that they do not have permissions for. * Section 8 - The storage of tokens long term can be restricted to only current valid ones if an immediate validation of the token is done. This means that the RS spends time doing the validation, but does not need to consume memory. This is looking really good. I think we have only two technical issues open at this point. The question of registrations for hash identifications in confirmation claims and if changes to the default scope structure are to be done. Jim _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Mon Jun 8 19:08:08 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9CB3A0924; Mon, 8 Jun 2020 19:08:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller , linuxwolf+ietf@outer-planes.net X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <159166848640.5501.9902316470501703521@ietfa.amsl.com> Date: Mon, 08 Jun 2020 19:08:06 -0700 Archived-At: Subject: [COSE] Roman Danyliw's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 02:08:07 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-cose-rfc8152bis-struct-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Are the wrong data structures being referenced or did I misunderstand something? ** Section 5. Per “Abbreviated counter signatures use the structure COSE_Countersign1”, this doesn’t seem consistent with the more detailed write-up in Section 5.2 which says that “The byte string representing the signature value is placed in the CounterSignature0 attribute”. The document makes no other reference to COSE_Countersign1. The shepherd write-up notes that ‘one item to note is the decision to keep the context string "COSE_Countersign1" for abbreviated countersignatures’. However, I found no such reference in Step 1 of Section 4.4 (page 22) which enumerated the possible strings. ** What is the intended name of the structure for the Counter Signature -- is it COSE_Countersignature or COSE_Countersign? -- Table 1, Section 2, Section 4.4 and Section 5.1 (to include the CDDL) reference COSE_Countersignature but -- Section 5. Per “Full counter signatures use the structure COSE_Countersign …” -- Section 5.1. Per “A tagged COSE_Countersign structure …” ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for making an easy to read and compare bis document. ** Section 4.4. Per the the following item in the list, ‘"CounterSignature" for signatures used as counter signature attributes.’, can this be more precisely stated as to reference the particular COSE_* data type? The other items in this list are more precise in naming the corresponding structure/attributes. From nobody Mon Jun 8 20:12:47 2020 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 7A8D23A07E6; Mon, 8 Jun 2020 20:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=cert.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 YKaTxKKHNgT7; Mon, 8 Jun 2020 20:12:44 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 6F1EB3A07E3; Mon, 8 Jun 2020 20:12:44 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0593CXXc042661; Mon, 8 Jun 2020 23:12:33 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 0593CXXc042661 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1591672353; bh=WJXURWCZjtV+FH4K2fsHAKWaBSzYJ+hL32gYahfp5cE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Xm1ddXeivGibBmgWGzN5SIpdLNB3XSwYAZhjT6DI6BneFrPDjOIaa3hSBOnscPWqb AyprjwSXt77VAC45vCFwM7Aot4tBcPO24amzmehGGzOtbLeJh+bZfkjlKrMN6XK9Xj jNgI5qgfy6KUMXtb06haeQ+YTTF0y72NN9HQHzkY= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0593CWTQ043129; Mon, 8 Jun 2020 23:12:32 -0400 Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 8 Jun 2020 23:12:32 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 8 Jun 2020 23:12:31 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Mon, 8 Jun 2020 23:12:31 -0400 From: Roman Danyliw To: Jim Schaad , "'Barry Leiba'" , "'The IESG'" CC: "'Ivaylo Petrov'" , "cose-chairs@ietf.org" , "draft-ietf-cose-hash-algs@ietf.org" , "cose@ietf.org" Thread-Topic: Barry Leiba's Yes on draft-ietf-cose-hash-algs-04: (with COMMENT) Thread-Index: AQHWORJ0yI0vY8L1OE+96dC4L61gBKjPoflg Date: Tue, 9 Jun 2020 03:12:31 +0000 Message-ID: References: <159107239537.28693.16065000145824637198@ietfa.amsl.com> <006201d63912$5e7663e0$1b632ba0$@augustcellars.com> In-Reply-To: <006201d63912$5e7663e0$1b632ba0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.211] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [COSE] Barry Leiba's Yes on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 03:12:46 -0000 SGkgSmltIQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGllc2cgPGll c2ctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEppbSBTY2hhYWQNCj4gU2VudDogVHVl c2RheSwgSnVuZSAyLCAyMDIwIDM6MTcgUE0NCj4gVG86ICdCYXJyeSBMZWliYScgPGJhcnJ5bGVp YmFAY29tcHV0ZXIub3JnPjsgJ1RoZSBJRVNHJyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6ICdJdmF5 bG8gUGV0cm92JyA8aXZheWxvQGFja2wuaW8+OyBjb3NlLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQt aWV0Zi1jb3NlLWhhc2gtDQo+IGFsZ3NAaWV0Zi5vcmc7IGNvc2VAaWV0Zi5vcmcNCj4gU3ViamVj dDogUkU6IEJhcnJ5IExlaWJhJ3MgWWVzIG9uIGRyYWZ0LWlldGYtY29zZS1oYXNoLWFsZ3MtMDQ6 ICh3aXRoIENPTU1FTlQpDQo+IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IEJhcnJ5IExlaWJhIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4N Cj4gU2VudDogTW9uZGF5LCBKdW5lIDEsIDIwMjAgOTozMyBQTQ0KPiBUbzogVGhlIElFU0cgPGll c2dAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1pZXRmLWNvc2UtaGFzaC1hbGdzQGlldGYub3JnOyBj b3NlLWNoYWlyc0BpZXRmLm9yZzsgY29zZUBpZXRmLm9yZzsNCj4gSXZheWxvIFBldHJvdiA8aXZh eWxvQGFja2wuaW8+OyBpdmF5bG9AYWNrbC5pbw0KPiBTdWJqZWN0OiBCYXJyeSBMZWliYSdzIFll cyBvbiBkcmFmdC1pZXRmLWNvc2UtaGFzaC1hbGdzLTA0OiAod2l0aCBDT01NRU5UKQ0KPiANCj4g QmFycnkgTGVpYmEgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9y DQo+IGRyYWZ0LWlldGYtY29zZS1oYXNoLWFsZ3MtMDQ6IFllcw0KPiANCj4gV2hlbiByZXNwb25k aW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxs IGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVl bCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0K PiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRl bWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg SUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1l bnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6 DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29zZS1oYXNo LWFsZ3MvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQpbc25pcF0NCg0KPiAgICBUaGUgc3RhbmRhcmQgIkNvbGxpc2lvbiBBdHRhY2si IGlzIG9uZSB3aGVyZSBhbiBhdHRhY2tlciBjYW4NCj4gICAgZmluZCB0d28gZGlmZmVyZW50IG1l c3NhZ2VzIHRoYXQgaGF2ZSB0aGUgc2FtZSBoYXNoIHZhbHVlLiAgSWYgYQ0KPiAgICBjb2xsaXNp b24gYXR0YWNrIGV4aXN0cywgdGhlbiB0aGUgZnVuY3Rpb24gU0hPVUxEIE5PVCBiZSB1c2VkIGZv ciBhDQo+ICAgIGNyeXB0b2dyYXBoaWMgcHVycG9zZS4NCj4gDQo+IEnigJltIHVuY29tZm9ydGFi bGUgd2l0aCBoYXZpbmcgdGhpcyBkb2N1bWVudCBnaXZlIGEgYnJpZWYgdHV0b3JpYWwgb24NCj4g Y3J5cHRvZ3JhcGhpYyBoYXNoaW5nLCBhcyBpdCBoYXMgdG8gYmUgb3ZlcnNpbXBsaWZpZWQuLi4g YW5kIGl0IGlzLiAgSWYgaXTigJlzIGdvaW5nIHRvDQo+IHN0YXksIEnigJlkIGxpa2UgdG8gc2Vl IGFyIGxlYXN0IG9uZSBtaW5vciBjaGFuZ2UsIHRob3VnaCBJ4oCZbGwgZGVmZXIgdG8gdGhlIFNl YyBBRHMNCj4gb24gdGhpcyBwb2ludDogZm9yIGFueSBoYXNoIGFsZywgaXQgaXMgYWx3YXlzIHBv c3NpYmxlIHRvIGVuY291bnRlciBhIGNvbGxpc2lvbiwgYW5kDQo+IHRoZSB0ZXh0IGlzbuKAmXQg Y2xlYXIgYWJvdXQgd2hhdCDigJxpZiBhIGNvbGxpc2lvbiBhdHRhY2sgZXhpc3Rz4oCdDQo+IHJl YWxseSBtZWFucy4gIEkgdGhpbmsgaXQgbWVhbnMgbm90IHRvIHVzZSBpdCBpZiBhIGNvbGxpc2lv biBhdHRhY2sgaXMgcHJhY3RpY2FsLCBhbmQNCj4gbWF5YmUgdGhpcyBpcyBhIGJldHRlciB3YXkg dG8gc2F5IGl0PzoNCj4gDQo+IE5FVw0KPiAgICBBICJjb2xsaXNpb24gYXR0YWNrIiBpcyBvbmUg d2hlcmUgYW4gYXR0YWNrZXIgY2FuDQo+ICAgIGZpbmQgdHdvIGRpZmZlcmVudCBtZXNzYWdlcyB0 aGF0IGhhdmUgdGhlIHNhbWUgaGFzaCB2YWx1ZS4gIEENCj4gICAgaGFzaCBmdW5jdGlvbiB0aGF0 IGlzIHN1c2NlcHRpYmxlIHRvIGNvbGxpc2lvbiBhdHRhY2tzLCBTSE9VTEQNCj4gICAgTk9UIGJl IHVzZWQgZm9yIGNyeXB0b2dyYXBoaWMgcHVycG9zZXMuDQo+IEVORA0KPiANCj4gW0pMU10gRG9u ZS4gIEdpdmVuIGhvdyBmYXN0IHdlIGFyZSBhdCBnZXR0aW5nIGhhc2ggYWxnb3JpdGhtcyBjaGFu Z2VkLCBJIGRvbid0DQo+IGtub3cgdGhhdCB0aGUgdHJpZ2dlciBJIHdvdWxkIHVzZSBpcyB0aGF0 IHRoZSBhdHRhY2sgaXMgcHJhY3RpY2FsLiAgSnVzdCB0aGUgYWJpbGl0eQ0KPiB0byBmaW5kIGEg Y29sbGlzaW9uIGF0IGFsbCBpcyB0aGUgdHJpZ2dlciB0aGF0IHdlIG5lZWQgdG8gc3RhcnQgY2hh bmdpbmcgdGhlIGhhc2gNCj4gYWxnb3JpdGhtcyB3ZSBhcmUgdXNpbmcuICBQZW9wbGUgaGF2ZSB0 YWxrZWQgYWJvdXQgU0hBLTEgY29sbGlzaW9ucyBmb3IgdGhlIGxhc3QNCj4gdHdlbnR5IHllYXJz LCBidXQgb25seSBpbiB0aGUgbGFzdCB0d28gaGF2ZSB0aGV5IGJlY29tZSBwcmFjdGljYWwuICBT aG91bGQgd2UNCj4gYmUgc3VnZ2VzdGluZyB0aGUgU0hPVUxEIGVhcmxpZXIgdGhhbiAyMDE3Pw0K DQpQZXJoYXBzIHdlIHNpbXBseSBzdGF0ZSB0aGUgZ3VpZGluZyBkZXNpZ24gcHJpbmNpcGFsLiAg U2F5Og0KDQpBICJjb2xsaXNpb24gYXR0YWNrIiBpcyBvbmUgd2hlcmUgYW4gYXR0YWNrZXIgY2Fu IGZpbmQgdHdvIGRpZmZlcmVudCBtZXNzYWdlcyB0aGF0IGhhdmUgdGhlIHNhbWUgaGFzaCB2YWx1 ZS4gIEEgaGFzaCBmdW5jdGlvbiB0aGF0IGlzIHN1c2NlcHRpYmxlIHRvIHByYWN0aWNhbCBjb2xs aXNpb24gYXR0YWNrcyBTSE9VTEQgTk9UIGJlIHVzZWQgZm9yIGNyeXB0b2dyYXBoaWMgcHVycG9z ZXMuICBUaGUgZGlzY292ZXJ5IG9mIHRoZW9yZXRpY2FsIGNvbGxpc2lvbiBhdHRhY2tzIGFnYWlu c3QgYSBnaXZlbiBoYXNoIGZ1bmN0aW9uIFNIT1VMRCB0cmlnZ2VyIGEgcmV2aWV3IG9mIHRoZSBj b250aW51ZWQgc3VpdGFiaWxpdHkgb2YgdGhlIGFsZ29yaXRobSBpZiBhbHRlcm5hdGl2ZXMgYXJl IGF2YWlsYWJsZSBhbmQgbWlncmF0aW9uIGlzIHZpYWJsZS4NCg0KUmVnYXJkcywNClJvbWFuDQoN Cg0K From nobody Mon Jun 8 20:22:56 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 166D63A07F5; Mon, 8 Jun 2020 20:22:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-cose-hash-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov , ivaylo@ackl.io X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <159167297006.10862.5277339478597521934@ietfa.amsl.com> Date: Mon, 08 Jun 2020 20:22:50 -0700 Archived-At: Subject: [COSE] Roman Danyliw's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 03:22:50 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-cose-hash-algs-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for extending COSE for this additional use. ** I added my thoughts on the Section 2 language to the email thread of Barry’s ballot ** Per “To distinguish between these two cases, a new value in the recommended column of the COSE Algorithms registry is to be added. "Filter Only" indicates that the only purpose of a hash function should be to filter results and not those which require collision resistance”, I would recommend: NEW: To distinguish between these two cases, a new value in the recommended column of the COSE Algorithms registry is to be added. "Filter Only" indicates that the only purpose of a hash function should be to filter results and it is not intended for applications which require a cryptographically strong algorithm is needed. It doesn’t change the intent, but it does generalize to all the security properties we might want of a hash algorithm. ** Section 5. Since collision and second-preimage attacks are mentioned, for completeness it would be worth mentioning the need for preimage resistance for cryptographic usage too. ** Editorial nits: -- Abstract. Editorial. The abstract has an explicit reference, [I-D.ietf-cose-rfc8152bis-struct], which abstracts are not permitted to have. -- Section 2.1. Editorial. s/this could /This could/ -- Section 3.1. Editorial. s/assign a point/assign a code point/ -- Section 3.2. Editorial. OLD Locations that use this hash function need either to analysis the potential problems with having a collision occur, or where the only function of the hash is to narrow the possible choices. NEW Applications that use this hash function need either to analyze the potential impact with having a collision occur, or use it only where the function of the hash is to narrow the possible choices. -- Section 3.3. Per “The pair of algorithms known as SHAKE-128 and SHAKE-256 are the instances of SHA-3 that are currently being standardized in the IETF”, it isn’t clear this sentence will age well. -- Section 4. Typo. s/preseved/preserved/ From nobody Mon Jun 8 21:17:24 2020 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 E0ED03A07CB; Mon, 8 Jun 2020 21:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 T1YcQaUFOPgp; Mon, 8 Jun 2020 21:17:16 -0700 (PDT) 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 C0FD03A087B; Mon, 8 Jun 2020 21:17:15 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jun 2020 21:17:06 -0700 From: Jim Schaad To: 'Roman Danyliw' , 'The IESG' CC: , , , 'Ivaylo Petrov' References: <159167297006.10862.5277339478597521934@ietfa.amsl.com> In-Reply-To: <159167297006.10862.5277339478597521934@ietfa.amsl.com> Date: Mon, 8 Jun 2020 21:17:04 -0700 Message-ID: <005c01d63e14$d74aa630$85dff290$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLJv5mSacbh4oVR80Nh1hyu/luYvqboqF7Q Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Roman Danyliw's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 04:17:18 -0000 -----Original Message----- From: Roman Danyliw via Datatracker =20 Sent: Monday, June 8, 2020 8:23 PM To: The IESG Cc: draft-ietf-cose-hash-algs@ietf.org; cose-chairs@ietf.org; = cose@ietf.org; Ivaylo Petrov ; ivaylo@ackl.io Subject: Roman Danyliw's No Objection on draft-ietf-cose-hash-algs-04: = (with COMMENT) Roman Danyliw has entered the following ballot position for draft-ietf-cose-hash-algs-04: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for extending COSE for this additional use. ** I added my thoughts on the Section 2 language to the email thread of = Barry=E2=80=99s ballot ** Per =E2=80=9CTo distinguish between these two cases, a new value in = the recommended column of the COSE Algorithms registry is to be added. "Filter Only" indicates that the only purpose of a hash function should be to filter results and not those which require collision resistance=E2=80=9D, I would recommend: NEW: To distinguish between these two cases, a new value in the recommended = column of the COSE Algorithms registry is to be added. "Filter Only" = indicates that the only purpose of a hash function should be to filter = results and it is not intended for applications which require a = cryptographically strong algorithm is needed. It doesn=E2=80=99t change the intent, but it does generalize to all the = security properties we might want of a hash algorithm. [JLS] Yes that makes sense, but I removed the trailing "is needed" = because it does not read well. ** Section 5. Since collision and second-preimage attacks are = mentioned, for completeness it would be worth mentioning the need for = preimage resistance for cryptographic usage too. ** Editorial nits: -- Abstract. Editorial. The abstract has an explicit reference, = [I-D.ietf-cose-rfc8152bis-struct], which abstracts are not permitted to = have. [JLS] ACK - I left it this way because it is a draft and not an RFC to = make sure that it is highlighted for the RFC Editor. -- Section 2.1. Editorial. s/this could /This could/ [JLS] Already caught. -- Section 3.1. Editorial. s/assign a point/assign a code point/ [JLS] Done. -- Section 3.2. Editorial. OLD Locations that use this hash function need either to analysis the potential problems with having a collision occur, or where the only function of the hash is to narrow the possible choices. NEW Applications that use this hash function need either to analyze the = potential impact with having a collision occur, or use it only where the = function of the hash is to narrow the possible choices. [JLS] This was already rewritten in response to comments from Barry. Use of this hash function needs analysis of the potential = problems with having a collision occur, or must be limited to where the = function of the hash is non-cryptographic. -- Section 3.3. Per =E2=80=9CThe pair of algorithms known as SHAKE-128 = and SHAKE-256 are the instances of SHA-3 that are currently being = standardized in the IETF=E2=80=9D, it isn=E2=80=99t clear this sentence = will age well. [JLS] It may not age well but it is why these are the ones in the = document. Perhaps "currently being standardized in the IETF. This is = the reason for including these algorithms in this document." -- Section 4. Typo. s/preseved/preserved/ [JLS] Fixed From nobody Mon Jun 8 21:17:27 2020 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 101ED3A087B; Mon, 8 Jun 2020 21:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 4BVQPZR5bR-T; Mon, 8 Jun 2020 21:17:19 -0700 (PDT) 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 31EE03A07CB; Mon, 8 Jun 2020 21:17:19 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jun 2020 21:17:13 -0700 From: Jim Schaad To: 'Roman Danyliw' , 'The IESG' CC: , , , 'Matthew Miller' References: <159166848640.5501.9902316470501703521@ietfa.amsl.com> In-Reply-To: <159166848640.5501.9902316470501703521@ietfa.amsl.com> Date: Mon, 8 Jun 2020 21:17:13 -0700 Message-ID: <005d01d63e14$db544790$91fcd6b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQDl0iZ7IQSe6C7mARwWxD+Yl5RxK6qwdYMg Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Roman Danyliw's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 04:17:22 -0000 -----Original Message----- From: Roman Danyliw via Datatracker =20 Sent: Monday, June 8, 2020 7:08 PM To: The IESG Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org; cose-chairs@ietf.org; = cose@ietf.org; Matthew Miller ; = linuxwolf+ietf@outer-planes.net Subject: Roman Danyliw's Discuss on = draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) Roman Danyliw has entered the following ballot position for draft-ietf-cose-rfc8152bis-struct-10: Discuss When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Are the wrong data structures being referenced or did I misunderstand = something? ** Section 5. Per =E2=80=9CAbbreviated counter signatures use the = structure COSE_Countersign1=E2=80=9D, this doesn=E2=80=99t seem = consistent with the more detailed write-up in Section 5.2 which says = that =E2=80=9CThe byte string representing the signature value is placed = in the CounterSignature0 attribute=E2=80=9D. The document makes no = other reference to COSE_Countersign1. [JLS] I added a CDDL type of COSE_CounterSignature0 and refer to it now. The shepherd write-up notes that =E2=80=98one item to note is the = decision to keep the context string "COSE_Countersign1" for abbreviated = countersignatures=E2=80=99.=20 However, I found no such reference in Step 1 of Section 4.4 (page 22) = which enumerated the possible strings. [JLS] The write-up has it backwards. The question was change '0' to '1' = and the decision was made not to do so. ** What is the intended name of the structure for the Counter Signature = -- is it COSE_Countersignature or COSE_Countersign? -- Table 1, Section 2, Section 4.4 and Section 5.1 (to include the CDDL) = reference COSE_Countersignature but -- Section 5. Per =E2=80=9CFull counter signatures use the structure = COSE_Countersign =E2=80=A6=E2=80=9D -- Section 5.1. Per =E2=80=9CA tagged COSE_Countersign structure = =E2=80=A6=E2=80=9D [JLS] All is now made consistent to COSE_Countersignature and = COSE_Countersignature0 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for making an easy to read and compare bis document. ** Section 4.4. Per the the following item in the list, = =E2=80=98"CounterSignature" for signatures used as counter signature attributes.=E2=80=99, can this = be more precisely stated as to reference the particular COSE_* data = type? The other items in this list are more precise in naming the = corresponding structure/attributes. [JLS] Both of the countersignature now refer to CDDL types and a new = type is defined for COSE_Countersignature0 so that it can be referred to = here and in the attribute table. =20 Additionally, I update the IANA considerations to reflect the change in = the type of the CounterSignature0 attribute. From nobody Mon Jun 8 21:19:46 2020 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 DF3383A087C; Mon, 8 Jun 2020 21:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 TPyeT2Iellu1; Mon, 8 Jun 2020 21:19:42 -0700 (PDT) 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 CB8523A07CB; Mon, 8 Jun 2020 21:19:41 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jun 2020 21:19:32 -0700 From: Jim Schaad To: 'Roman Danyliw' , 'Barry Leiba' , 'The IESG' CC: 'Ivaylo Petrov' , , , References: <159107239537.28693.16065000145824637198@ietfa.amsl.com> <006201d63912$5e7663e0$1b632ba0$@augustcellars.com> In-Reply-To: Date: Mon, 8 Jun 2020 21:19:30 -0700 Message-ID: <005e01d63e15$2e64c680$8b2e5380$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGAFY4lrc4Y2TOVahTQsjcD5477ZAIyszN8Af+rR9GpWmvkwA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Barry Leiba's Yes on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 04:19:45 -0000 -----Original Message----- From: Roman Danyliw =20 Sent: Monday, June 8, 2020 8:13 PM To: Jim Schaad ; 'Barry Leiba' = ; 'The IESG' Cc: 'Ivaylo Petrov' ; cose-chairs@ietf.org; = draft-ietf-cose-hash-algs@ietf.org; cose@ietf.org Subject: RE: Barry Leiba's Yes on draft-ietf-cose-hash-algs-04: (with = COMMENT) Hi Jim! > -----Original Message----- > From: iesg On Behalf Of Jim Schaad > Sent: Tuesday, June 2, 2020 3:17 PM > To: 'Barry Leiba' ; 'The IESG'=20 > > Cc: 'Ivaylo Petrov' ; cose-chairs@ietf.org;=20 > draft-ietf-cose-hash- algs@ietf.org; cose@ietf.org > Subject: RE: Barry Leiba's Yes on draft-ietf-cose-hash-algs-04: (with=20 > COMMENT) >=20 >=20 >=20 > -----Original Message----- > From: Barry Leiba via Datatracker > Sent: Monday, June 1, 2020 9:33 PM > To: The IESG > Cc: draft-ietf-cose-hash-algs@ietf.org; cose-chairs@ietf.org;=20 > cose@ietf.org; Ivaylo Petrov ; ivaylo@ackl.io > Subject: Barry Leiba's Yes on draft-ietf-cose-hash-algs-04: (with=20 > COMMENT) >=20 > Barry Leiba has entered the following ballot position for > draft-ietf-cose-hash-algs-04: Yes >=20 > When responding, please keep the subject line intact and reply to all=20 > email addresses included in the To and CC lines. (Feel free to cut=20 > this introductory paragraph, however.) >=20 >=20 > Please refer to=20 > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- [snip] > The standard "Collision Attack" is one where an attacker can > find two different messages that have the same hash value. If a > collision attack exists, then the function SHOULD NOT be used for a > cryptographic purpose. >=20 > I=E2=80=99m uncomfortable with having this document give a brief = tutorial on=20 > cryptographic hashing, as it has to be oversimplified... and it is. =20 > If it=E2=80=99s going to stay, I=E2=80=99d like to see ar least one = minor change,=20 > though I=E2=80=99ll defer to the Sec ADs on this point: for any hash = alg, it=20 > is always possible to encounter a collision, and the text = isn=E2=80=99t clear about what =E2=80=9Cif a collision attack = exists=E2=80=9D > really means. I think it means not to use it if a collision attack is = > practical, and maybe this is a better way to say it?: >=20 > NEW > A "collision attack" is one where an attacker can > find two different messages that have the same hash value. A > hash function that is susceptible to collision attacks, SHOULD > NOT be used for cryptographic purposes. > END >=20 > [JLS] Done. Given how fast we are at getting hash algorithms changed, = > I don't know that the trigger I would use is that the attack is=20 > practical. Just the ability to find a collision at all is the trigger = > that we need to start changing the hash algorithms we are using. =20 > People have talked about SHA-1 collisions for the last twenty years,=20 > but only in the last two have they become practical. Should we be = suggesting the SHOULD earlier than 2017? Perhaps we simply state the guiding design principal. Say: A "collision attack" is one where an attacker can find two different = messages that have the same hash value. A hash function that is = susceptible to practical collision attacks SHOULD NOT be used for = cryptographic purposes. The discovery of theoretical collision attacks = against a given hash function SHOULD trigger a review of the continued = suitability of the algorithm if alternatives are available and migration = is viable. [JLS] That makes sense. Regards, Roman From nobody Tue Jun 9 05:24:25 2020 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 9996F3A085A; Tue, 9 Jun 2020 05:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=cert.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 unv4etti6-i5; Tue, 9 Jun 2020 05:24:19 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 7611F3A00C1; Tue, 9 Jun 2020 05:24:11 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 059CO3np023598; Tue, 9 Jun 2020 08:24:04 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 059CO3np023598 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1591705444; bh=ISLaSj4r5F2at/lPCWM9rIhi1VhZCeZamgXf3J4hQ+g=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=S8+0Y0m5yuTUFC5USu4+174EcBviKJY4WrFWxlhO63uwXdFq1lqypn3cPkFxC7JES gRnc7ChQd3zUhA0g65tYaP/L8KI80ienp/doHbPoXKuRHUb7g6UPajrYb4q3ELuT6t hknk36jrksYAwl20C8ZZ9QAw+K1JFbJol72uIiwk= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 059CO2Jn021392; Tue, 9 Jun 2020 08:24:02 -0400 Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 9 Jun 2020 08:24:02 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 9 Jun 2020 08:24:01 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Tue, 9 Jun 2020 08:24:01 -0400 From: Roman Danyliw To: Jim Schaad , "'The IESG'" CC: "draft-ietf-cose-hash-algs@ietf.org" , "cose-chairs@ietf.org" , "cose@ietf.org" , "'Ivaylo Petrov'" Thread-Topic: Roman Danyliw's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT) Thread-Index: AQHWPg1EBs7HJMbIWkaTKkd0YFguUajP8JwAgABEUFA= Date: Tue, 9 Jun 2020 12:24:01 +0000 Message-ID: <7ee5a04ba88142dfaf1d5ad4c6a7a825@cert.org> References: <159167297006.10862.5277339478597521934@ietfa.amsl.com> <005c01d63e14$d74aa630$85dff290$@augustcellars.com> In-Reply-To: <005c01d63e14$d74aa630$85dff290$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.211] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [COSE] Roman Danyliw's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 12:24:22 -0000 SGkgSmltIQ0KDQpUaGFua3MgZm9yIHRoZSBxdWljayByZXNwb25zZS4gWW91IHJlZmluZW1lbnRz IGJlbG93IGFyZSBhbiBpbXByb3ZlbWVudCBvdmVyIG1pbmUuICBUaGFua3MgZm9yIG1ha2luZyB0 aGVtLg0KDQpSZWdhcmRzLA0KUm9tYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPg0KPiBTZW50OiBUdWVz ZGF5LCBKdW5lIDksIDIwMjAgMTI6MTcgQU0NCj4gVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0 Lm9yZz47ICdUaGUgSUVTRycgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1pZXRmLWNvc2Ut aGFzaC1hbGdzQGlldGYub3JnOyBjb3NlLWNoYWlyc0BpZXRmLm9yZzsgY29zZUBpZXRmLm9yZzsN Cj4gJ0l2YXlsbyBQZXRyb3YnIDxpdmF5bG9AYWNrbC5pbz4NCj4gU3ViamVjdDogUkU6IFJvbWFu IERhbnlsaXcncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1jb3NlLWhhc2gtYWxncy0wNDoN Cj4gKHdpdGggQ09NTUVOVCkNCj4gDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogUm9tYW4gRGFueWxpdyB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5v cmc+DQo+IFNlbnQ6IE1vbmRheSwgSnVuZSA4LCAyMDIwIDg6MjMgUE0NCj4gVG86IFRoZSBJRVNH IDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1jb3NlLWhhc2gtYWxnc0BpZXRmLm9y ZzsgY29zZS1jaGFpcnNAaWV0Zi5vcmc7IGNvc2VAaWV0Zi5vcmc7DQo+IEl2YXlsbyBQZXRyb3Yg PGl2YXlsb0BhY2tsLmlvPjsgaXZheWxvQGFja2wuaW8NCj4gU3ViamVjdDogUm9tYW4gRGFueWxp dydzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWNvc2UtaGFzaC1hbGdzLTA0OiAod2l0aA0K PiBDT01NRU5UKQ0KPiANCj4gUm9tYW4gRGFueWxpdyBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5n IGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1jb3NlLWhhc2gtYWxncy0wNDogTm8g T2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0 IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVk IGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0 b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0 dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0K PiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9z aXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3Qg cG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3NlLWhhc2gtYWxncy8NCj4gDQo+IA0KPiANCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBUaGFua3MgZm9yIGV4 dGVuZGluZyBDT1NFIGZvciB0aGlzIGFkZGl0aW9uYWwgdXNlLg0KPiANCj4gKiogSSBhZGRlZCBt eSB0aG91Z2h0cyBvbiB0aGUgU2VjdGlvbiAyIGxhbmd1YWdlIHRvIHRoZSBlbWFpbCB0aHJlYWQg b2YNCj4gQmFycnnigJlzIGJhbGxvdA0KPiANCj4gKiogUGVyIOKAnFRvIGRpc3Rpbmd1aXNoIGJl dHdlZW4gdGhlc2UgdHdvIGNhc2VzLCBhIG5ldyB2YWx1ZSBpbiB0aGUNCj4gICAgcmVjb21tZW5k ZWQgY29sdW1uIG9mIHRoZSBDT1NFIEFsZ29yaXRobXMgcmVnaXN0cnkgaXMgdG8gYmUgYWRkZWQu DQo+ICAgICJGaWx0ZXIgT25seSIgaW5kaWNhdGVzIHRoYXQgdGhlIG9ubHkgcHVycG9zZSBvZiBh IGhhc2ggZnVuY3Rpb24NCj4gICAgc2hvdWxkIGJlIHRvIGZpbHRlciByZXN1bHRzIGFuZCBub3Qg dGhvc2Ugd2hpY2ggcmVxdWlyZSBjb2xsaXNpb24NCj4gICAgcmVzaXN0YW5jZeKAnSwgSSB3b3Vs ZCByZWNvbW1lbmQ6DQo+IA0KPiBORVc6DQo+IFRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gdGhlc2Ug dHdvIGNhc2VzLCBhIG5ldyB2YWx1ZSBpbiB0aGUgcmVjb21tZW5kZWQNCj4gY29sdW1uIG9mIHRo ZSBDT1NFIEFsZ29yaXRobXMgcmVnaXN0cnkgaXMgdG8gYmUgYWRkZWQuICAiRmlsdGVyIE9ubHki IGluZGljYXRlcw0KPiB0aGF0IHRoZSBvbmx5IHB1cnBvc2Ugb2YgYSBoYXNoIGZ1bmN0aW9uIHNo b3VsZCBiZSB0byBmaWx0ZXIgcmVzdWx0cyBhbmQgaXQgaXMgbm90DQo+IGludGVuZGVkIGZvciBh cHBsaWNhdGlvbnMgd2hpY2ggcmVxdWlyZSBhIGNyeXB0b2dyYXBoaWNhbGx5IHN0cm9uZyBhbGdv cml0aG0gaXMNCj4gbmVlZGVkLg0KPiANCj4gSXQgZG9lc27igJl0IGNoYW5nZSB0aGUgaW50ZW50 LCBidXQgaXQgZG9lcyBnZW5lcmFsaXplIHRvIGFsbCB0aGUgc2VjdXJpdHkgcHJvcGVydGllcw0K PiB3ZSBtaWdodCB3YW50IG9mIGEgaGFzaCBhbGdvcml0aG0uDQo+IFtKTFNdIFllcyB0aGF0IG1h a2VzIHNlbnNlLCBidXQgSSByZW1vdmVkIHRoZSB0cmFpbGluZyAiaXMgbmVlZGVkIiBiZWNhdXNl IGl0DQo+IGRvZXMgbm90IHJlYWQgd2VsbC4NCj4gDQo+ICoqIFNlY3Rpb24gNS4gIFNpbmNlIGNv bGxpc2lvbiBhbmQgc2Vjb25kLXByZWltYWdlIGF0dGFja3MgYXJlIG1lbnRpb25lZCwgZm9yDQo+ IGNvbXBsZXRlbmVzcyBpdCB3b3VsZCBiZSB3b3J0aCBtZW50aW9uaW5nIHRoZSBuZWVkIGZvciBw cmVpbWFnZSByZXNpc3RhbmNlDQo+IGZvciBjcnlwdG9ncmFwaGljIHVzYWdlIHRvby4NCj4gDQo+ ICoqIEVkaXRvcmlhbCBuaXRzOg0KPiANCj4gLS0gQWJzdHJhY3QuICBFZGl0b3JpYWwuIFRoZSBh YnN0cmFjdCBoYXMgYW4gZXhwbGljaXQgcmVmZXJlbmNlLCBbSS1ELmlldGYtY29zZS0NCj4gcmZj ODE1MmJpcy1zdHJ1Y3RdLCB3aGljaCBhYnN0cmFjdHMgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gaGF2 ZS4NCj4gW0pMU10gQUNLIC0gSSBsZWZ0IGl0IHRoaXMgd2F5IGJlY2F1c2UgaXQgaXMgYSBkcmFm dCBhbmQgbm90IGFuIFJGQyB0byBtYWtlIHN1cmUNCj4gdGhhdCBpdCBpcyBoaWdobGlnaHRlZCBm b3IgdGhlIFJGQyBFZGl0b3IuDQo+IA0KPiAtLSBTZWN0aW9uIDIuMS4gRWRpdG9yaWFsLiAgcy90 aGlzIGNvdWxkIC9UaGlzIGNvdWxkLyBbSkxTXSBBbHJlYWR5IGNhdWdodC4NCj4gDQo+IC0tIFNl Y3Rpb24gMy4xLiBFZGl0b3JpYWwuIHMvYXNzaWduIGEgcG9pbnQvYXNzaWduIGEgY29kZSBwb2lu dC8gW0pMU10gRG9uZS4NCj4gDQo+IC0tIFNlY3Rpb24gMy4yLiBFZGl0b3JpYWwuDQo+IA0KPiBP TEQNCj4gTG9jYXRpb25zIHRoYXQgdXNlIHRoaXMgaGFzaCBmdW5jdGlvbg0KPiAgICAgICBuZWVk IGVpdGhlciB0byBhbmFseXNpcyB0aGUgcG90ZW50aWFsIHByb2JsZW1zIHdpdGggaGF2aW5nIGEN Cj4gICAgICAgY29sbGlzaW9uIG9jY3VyLCBvciB3aGVyZSB0aGUgb25seSBmdW5jdGlvbiBvZiB0 aGUgaGFzaCBpcyB0bw0KPiAgICAgICBuYXJyb3cgdGhlIHBvc3NpYmxlIGNob2ljZXMuDQo+IA0K PiBORVcNCj4gQXBwbGljYXRpb25zIHRoYXQgdXNlIHRoaXMgaGFzaCBmdW5jdGlvbiBuZWVkIGVp dGhlciB0byBhbmFseXplIHRoZSBwb3RlbnRpYWwNCj4gaW1wYWN0IHdpdGggaGF2aW5nIGEgY29s bGlzaW9uIG9jY3VyLCBvciB1c2UgaXQgb25seSB3aGVyZSB0aGUgZnVuY3Rpb24gb2YgdGhlDQo+ IGhhc2ggaXMgdG8gbmFycm93IHRoZSBwb3NzaWJsZSBjaG9pY2VzLg0KPiBbSkxTXSBUaGlzIHdh cyBhbHJlYWR5IHJld3JpdHRlbiBpbiByZXNwb25zZSB0byBjb21tZW50cyBmcm9tIEJhcnJ5Lg0K PiANCj4gICAgICAgICAgICAgICBVc2Ugb2YgdGhpcyBoYXNoIGZ1bmN0aW9uIG5lZWRzIGFuYWx5 c2lzIG9mIHRoZSBwb3RlbnRpYWwgcHJvYmxlbXMgd2l0aA0KPiBoYXZpbmcgYSBjb2xsaXNpb24g b2NjdXIsIG9yIG11c3QgYmUgbGltaXRlZCB0byB3aGVyZSB0aGUgZnVuY3Rpb24gb2YgdGhlIGhh c2ggaXMNCj4gbm9uLWNyeXB0b2dyYXBoaWMuDQo+IA0KPiAtLSBTZWN0aW9uIDMuMy4gIFBlciDi gJxUaGUgcGFpciBvZiBhbGdvcml0aG1zIGtub3duIGFzIFNIQUtFLTEyOCBhbmQgU0hBS0UtMjU2 DQo+IGFyZSB0aGUgaW5zdGFuY2VzIG9mIFNIQS0zIHRoYXQgYXJlIGN1cnJlbnRseSBiZWluZyBz dGFuZGFyZGl6ZWQgaW4gdGhlIElFVEbigJ0sIGl0DQo+IGlzbuKAmXQgY2xlYXIgdGhpcyBzZW50 ZW5jZSB3aWxsIGFnZSB3ZWxsLg0KPiBbSkxTXSBJdCBtYXkgbm90IGFnZSB3ZWxsIGJ1dCBpdCBp cyB3aHkgdGhlc2UgYXJlIHRoZSBvbmVzIGluIHRoZSBkb2N1bWVudC4NCj4gUGVyaGFwcyAiY3Vy cmVudGx5IGJlaW5nIHN0YW5kYXJkaXplZCBpbiB0aGUgSUVURi4gIFRoaXMgaXMgdGhlIHJlYXNv biBmb3INCj4gaW5jbHVkaW5nIHRoZXNlIGFsZ29yaXRobXMgaW4gdGhpcyBkb2N1bWVudC4iDQo+ IA0KPiAtLSBTZWN0aW9uIDQuICBUeXBvLiBzL3ByZXNldmVkL3ByZXNlcnZlZC8gW0pMU10gRml4 ZWQNCj4gDQo+IA0KDQo= From nobody Tue Jun 9 06:05:51 2020 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 BF9A33A08DB; Tue, 9 Jun 2020 06:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=cert.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 rcEj70JQSNCY; Tue, 9 Jun 2020 06:05:44 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 1443B3A0873; Tue, 9 Jun 2020 06:05:44 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 059D3SDQ029230; Tue, 9 Jun 2020 09:03:28 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 059D3SDQ029230 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1591707808; bh=2F1Td8lrpHUUMtSpPIEbz3W2NybUncJYtx2Q8p9h5sM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=cYG8hW0Mc9vSU6vdjVCaT/9/SriQuYZ8DHaGu+Ij9AeETwtIFBBsQIQRiNmPgcJhd fDLARuZNxdKJIrGDR/nGZceHyqH4/zSl2Obc8918tFfyR5yHMyYmrtbKgtVmR2tm+5 uoVIWgDXiErkIJrpWmaGveyHz0XO8oAzEgr19dLM= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 059D3QOk048285; Tue, 9 Jun 2020 09:03:26 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 9 Jun 2020 09:03:26 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 9 Jun 2020 09:03:25 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Tue, 9 Jun 2020 09:03:25 -0400 From: Roman Danyliw To: Jim Schaad , "'The IESG'" CC: "draft-ietf-cose-rfc8152bis-struct@ietf.org" , "cose-chairs@ietf.org" , "cose@ietf.org" , "'Matthew Miller'" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) Thread-Index: AQHWPhTkzlPRv8qZp0K2f/tx3jknc6jQNZTg Date: Tue, 9 Jun 2020 13:03:25 +0000 Message-ID: References: <159166848640.5501.9902316470501703521@ietfa.amsl.com> <005d01d63e14$db544790$91fcd6b0$@augustcellars.com> In-Reply-To: <005d01d63e14$db544790$91fcd6b0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.211] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [COSE] Roman Danyliw's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 13:05:46 -0000 SGkgSmltIQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEppbSBTY2hh YWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+DQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgOSwgMjAy MCAxMjoxNyBBTQ0KPiBUbzogUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPjsgJ1RoZSBJRVNH JyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlzLXN0cnVj dEBpZXRmLm9yZzsgY29zZS1jaGFpcnNAaWV0Zi5vcmc7DQo+IGNvc2VAaWV0Zi5vcmc7ICdNYXR0 aGV3IE1pbGxlcicgPGxpbnV4d29sZitpZXRmQG91dGVyLXBsYW5lcy5uZXQ+DQo+IFN1YmplY3Q6 IFJFOiBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWNvc2UtcmZjODE1MmJp cy1zdHJ1Y3QtMTA6DQo+ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiANCj4gDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJvbWFuIERhbnlsaXcgdmlhIERh dGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPg0KPiBTZW50OiBNb25kYXksIEp1bmUgOCwgMjAy MCA3OjA4IFBNDQo+IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0LWll dGYtY29zZS1yZmM4MTUyYmlzLXN0cnVjdEBpZXRmLm9yZzsgY29zZS1jaGFpcnNAaWV0Zi5vcmc7 DQo+IGNvc2VAaWV0Zi5vcmc7IE1hdHRoZXcgTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1w bGFuZXMubmV0PjsNCj4gbGludXh3b2xmK2lldGZAb3V0ZXItcGxhbmVzLm5ldA0KPiBTdWJqZWN0 OiBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWNvc2UtcmZjODE1MmJpcy1z dHJ1Y3QtMTA6ICh3aXRoDQo+IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBSb21hbiBEYW55 bGl3IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFm dC1pZXRmLWNvc2UtcmZjODE1MmJpcy1zdHJ1Y3QtMTA6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVz cG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRv IGFsbCBlbWFpbA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4g KEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVy LikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9z dGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRv Y3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBo ZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvc2Ut cmZjODE1MmJpcy1zdHJ1Y3QvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRElTQ1VT UzoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gQXJlIHRoZSB3cm9uZyBkYXRhIHN0cnVjdHVyZXMg YmVpbmcgcmVmZXJlbmNlZCBvciBkaWQgSSBtaXN1bmRlcnN0YW5kDQo+IHNvbWV0aGluZz8NCj4g DQo+ICoqIFNlY3Rpb24gNS4gIFBlciDigJxBYmJyZXZpYXRlZCBjb3VudGVyIHNpZ25hdHVyZXMg dXNlIHRoZSBzdHJ1Y3R1cmUNCj4gQ09TRV9Db3VudGVyc2lnbjHigJ0sIHRoaXMgZG9lc27igJl0 IHNlZW0gY29uc2lzdGVudCB3aXRoIHRoZSBtb3JlIGRldGFpbGVkDQo+IHdyaXRlLXVwIGluIFNl Y3Rpb24gNS4yIHdoaWNoIHNheXMgdGhhdCDigJxUaGUgYnl0ZSBzdHJpbmcgcmVwcmVzZW50aW5n IHRoZQ0KPiBzaWduYXR1cmUgdmFsdWUgaXMgcGxhY2VkIGluIHRoZSBDb3VudGVyU2lnbmF0dXJl MCBhdHRyaWJ1dGXigJ0uICBUaGUgZG9jdW1lbnQNCj4gbWFrZXMgbm8gb3RoZXIgcmVmZXJlbmNl IHRvIENPU0VfQ291bnRlcnNpZ24xLg0KPiBbSkxTXSBJIGFkZGVkIGEgQ0RETCB0eXBlIG9mIENP U0VfQ291bnRlclNpZ25hdHVyZTAgYW5kIHJlZmVyIHRvIGl0IG5vdy4NCg0KVGhhbmtzIGZvciB0 aGlzIHVwZGF0ZS4gIFRoYXQncyB3aGF0IEkgdGhvdWdodCBpdCBzaG91bGQgc2F5IGJhc2VkIG9u IHRoZSBkZXRhaWxzIGluIFNlY3Rpb24gNS4yDQoNCj4gVGhlIHNoZXBoZXJkIHdyaXRlLXVwIG5v dGVzIHRoYXQg4oCYb25lIGl0ZW0gdG8gbm90ZSBpcyB0aGUgZGVjaXNpb24gdG8ga2VlcCB0aGUN Cj4gY29udGV4dCBzdHJpbmcgIkNPU0VfQ291bnRlcnNpZ24xIiBmb3IgYWJicmV2aWF0ZWQgY291 bnRlcnNpZ25hdHVyZXPigJkuDQo+IEhvd2V2ZXIsIEkgZm91bmQgbm8gc3VjaCByZWZlcmVuY2Ug aW4gU3RlcCAxIG9mIFNlY3Rpb24gNC40IChwYWdlIDIyKSB3aGljaA0KPiBlbnVtZXJhdGVkIHRo ZSBwb3NzaWJsZSBzdHJpbmdzLg0KPiBbSkxTXSBUaGUgd3JpdGUtdXAgaGFzIGl0IGJhY2t3YXJk cy4gIFRoZSBxdWVzdGlvbiB3YXMgY2hhbmdlICcwJyB0byAnMScgYW5kIHRoZQ0KPiBkZWNpc2lv biB3YXMgbWFkZSBub3QgdG8gZG8gc28uDQo+IA0KPiAqKiBXaGF0IGlzIHRoZSBpbnRlbmRlZCBu YW1lIG9mIHRoZSBzdHJ1Y3R1cmUgZm9yIHRoZSBDb3VudGVyIFNpZ25hdHVyZSAtLSBpcyBpdA0K PiBDT1NFX0NvdW50ZXJzaWduYXR1cmUgb3IgQ09TRV9Db3VudGVyc2lnbj8NCj4gDQo+IC0tIFRh YmxlIDEsIFNlY3Rpb24gMiwgU2VjdGlvbiA0LjQgYW5kIFNlY3Rpb24gNS4xICh0byBpbmNsdWRl IHRoZSBDRERMKQ0KPiByZWZlcmVuY2UgQ09TRV9Db3VudGVyc2lnbmF0dXJlDQo+IA0KPiBidXQN Cj4gLS0gU2VjdGlvbiA1LiBQZXIg4oCcRnVsbCBjb3VudGVyIHNpZ25hdHVyZXMgdXNlIHRoZSBz dHJ1Y3R1cmUgQ09TRV9Db3VudGVyc2lnbg0KPiDigKbigJ0NCj4gDQo+IC0tIFNlY3Rpb24gNS4x LiAgUGVyIOKAnEEgdGFnZ2VkIENPU0VfQ291bnRlcnNpZ24gc3RydWN0dXJlIOKApuKAnQ0KPiAN Cj4gW0pMU10gQWxsIGlzIG5vdyBtYWRlIGNvbnNpc3RlbnQgdG8gQ09TRV9Db3VudGVyc2lnbmF0 dXJlIGFuZA0KPiBDT1NFX0NvdW50ZXJzaWduYXR1cmUwDQoNCk1ha2VzIHNlbnNlLiAgVGhhbmtz IGZvciBtYWtpbmcgdGhpcyB1cGRhdGUuDQoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBUaGFua3MgZm9yIG1ha2luZyBhbiBlYXN5IHRvIHJlYWQg YW5kIGNvbXBhcmUgYmlzIGRvY3VtZW50Lg0KPiANCj4gKiogU2VjdGlvbiA0LjQuICBQZXIgdGhl IHRoZSBmb2xsb3dpbmcgaXRlbSBpbiB0aGUgbGlzdCwg4oCYIkNvdW50ZXJTaWduYXR1cmUiDQo+ IGZvciBzaWduYXR1cmVzIHVzZWQgYXMgY291bnRlciBzaWduYXR1cmUgYXR0cmlidXRlcy7igJks IGNhbiB0aGlzIGJlIG1vcmUgcHJlY2lzZWx5DQo+IHN0YXRlZCBhcyB0byByZWZlcmVuY2UgdGhl IHBhcnRpY3VsYXIgQ09TRV8qIGRhdGEgdHlwZT8gIFRoZSBvdGhlciBpdGVtcyBpbiB0aGlzDQo+ IGxpc3QgYXJlIG1vcmUgcHJlY2lzZSBpbiBuYW1pbmcgdGhlIGNvcnJlc3BvbmRpbmcgc3RydWN0 dXJlL2F0dHJpYnV0ZXMuDQo+IA0KPiBbSkxTXSBCb3RoIG9mIHRoZSBjb3VudGVyc2lnbmF0dXJl IG5vdyByZWZlciB0byBDRERMIHR5cGVzIGFuZCBhIG5ldyB0eXBlIGlzDQo+IGRlZmluZWQgZm9y IENPU0VfQ291bnRlcnNpZ25hdHVyZTAgc28gdGhhdCBpdCBjYW4gYmUgcmVmZXJyZWQgdG8gaGVy ZSBhbmQgaW4NCj4gdGhlIGF0dHJpYnV0ZSB0YWJsZS4NCg0KVGhhbmtzLg0KDQo+IEFkZGl0aW9u YWxseSwgSSB1cGRhdGUgdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgdG8gcmVmbGVjdCB0aGUgY2hh bmdlIGluIHRoZSB0eXBlDQo+IG9mIHRoZSBDb3VudGVyU2lnbmF0dXJlMCBhdHRyaWJ1dGUuDQoN Ckdvb2QgY2F0Y2guICBUaGF0IG5lZWRlZCB0byBiZSBkb25lIHRvby4gIA0KDQpSZWdhcmRzLA0K Um9tYW4NCg0KDQo= From nobody Tue Jun 9 07:08:11 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 304603A0528; Tue, 9 Jun 2020 07:08:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-cose-webauthn-algorithms@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov , ivaylo@ackl.io X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <159171168997.18642.3523407941144113205@ietfa.amsl.com> Date: Tue, 09 Jun 2020 07:08:10 -0700 Archived-At: Subject: [COSE] Roman Danyliw's No Objection on draft-ietf-cose-webauthn-algorithms-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 14:08:10 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-cose-webauthn-algorithms-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the updates in -07 in response to LC feedback on secp256k1 and ES256K being registered as “Recommend: No”. Two additional items in that vein: ** Table 2. ES256K should read Recommended = NO (i.e., not recommended) consistent with the registration guidance in Section 4.1 and Section 4.2. ** Section 5.4. The basis of the “not recommended” is explained in Section 5.2 and 5.3. Can that be done here too. From nobody Tue Jun 9 09:42:38 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A103A0985; Tue, 9 Jun 2020 09:42:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-cose-hash-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov , ivaylo@ackl.io X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <159172095262.24997.15438689683390108475@ietfa.amsl.com> Date: Tue, 09 Jun 2020 09:42:33 -0700 Archived-At: Subject: [COSE] Robert Wilton's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 16:42:33 -0000 Robert Wilton has entered the following ballot position for draft-ietf-cose-hash-algs-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thank you for this document, I found it easy to read and understand. A few minor comments: 1. Introduction Indirect signing of content is a paradigm where the content is not directly signed, but instead a hash of the content is computed and that hash value, along with the hash algorithm, is included in the content that will be signed. Doing indirect signing allows for a signature to be validated without first downloading all of the content associated with the signature. This capability can be of even greater importance in a constrained environment as not all of the content signed may be needed by the device. Would it be better to write "along with an identifier for the hash algorithm"? 1. Introduction The use of hashes to identify objects is something that has been very common. One of the primary things that has been identified by a hash function for secure message is a certificate. Two examples of this can be found in [ESS] and the newly defined COSE equivalents in [I-D.ietf-cose-x509]. Perhaps drop "newly defined"? 3.2. SHA-2 Hash Algorithms * *SHA-256* is probably the most common hash function used currently. SHA-256 is an efficient hash algorithm for 32-bit hardware. Is this intended to imply that SHA-256 is not an efficient hash algorithm when running on 64-bit hardware? If so, that might be worth explicitly stating, although it is implied by the description for SHA-512/256. 3.3. SHAKE Algorithms Would this be more clear to be titled as SHA-3 Algorithms? Thanks, Rob From nobody Tue Jun 9 10:27:15 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B593E3A0AF4; Tue, 9 Jun 2020 10:27:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller , linuxwolf+ietf@outer-planes.net X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <159172362923.2755.16291108469492738933@ietfa.amsl.com> Date: Tue, 09 Jun 2020 10:27:09 -0700 Archived-At: Subject: [COSE] Roman Danyliw's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 17:27:10 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-cose-rfc8152bis-algs-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the easy to read diff on a bis document, and for addressing the SecDir feedback. ** Section 8. Per “For an algorithm, the first element should always be a key type value, but the items that are specific to a key should not be included in the algorithm capabilities” and later “For a key, the first element should also be a key type value” is there a reason for not making these “should” into normative MUSTs? ** Section 8. I would have benefited from more text to understand how to parse a capabilities field. IMO, it would have been helpful to say that the first element of the array maps to the Value column of the COSE Key Type registry. The new Capabilities column of that corresponding entry describes the semantics of the second array element. ** Editorial Nits: -- The text in the header notes this document is standards track. However, the datatracker and shepherd write-up note that it is informational. I suspect it should be fixed in this document to be informational. -- Abstract. Please remove the explicit references from abstract (as they are not permitted to be there) -- Abstraction. Editorial. The sentence “In this specification the conventions …” is incomplete. -- Section 1. Editorial. “Additional algorithms beyond what are in this document are defined elsewhere”. IMO, this sentence doesn’t appear to add anything. Recommend removal. -- Section 8. Per ”There is a presumption in the way that this is laid out is that the algorithm identifier itself is not needed to be a part of this as it is specified in a different location”, I had trouble following this sentence from the previous one – what is the double reference to “this” here? -- Section 8.3. Typo. s/it is encodes/, they encode/ -- Section 10.2. Typo. s/rquested/requested/ From nobody Tue Jun 9 10:28:43 2020 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 246E53A0B1F; Tue, 9 Jun 2020 10:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 D-3-7iMeTG19; Tue, 9 Jun 2020 10:28:36 -0700 (PDT) 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 D6A303A0B1E; Tue, 9 Jun 2020 10:28:35 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 9 Jun 2020 10:28:29 -0700 From: Jim Schaad To: 'Robert Wilton' , 'The IESG' CC: , , , 'Ivaylo Petrov' References: <159172095262.24997.15438689683390108475@ietfa.amsl.com> In-Reply-To: <159172095262.24997.15438689683390108475@ietfa.amsl.com> Date: Tue, 9 Jun 2020 10:28:27 -0700 Message-ID: <009901d63e83$6502d290$2f0877b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFIhZBpFVfilUfhwKdQdsgpo++9SKnr+UNA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Robert Wilton's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 17:28:38 -0000 -----Original Message----- From: Robert Wilton via Datatracker =20 Sent: Tuesday, June 9, 2020 9:43 AM To: The IESG Cc: draft-ietf-cose-hash-algs@ietf.org; cose-chairs@ietf.org; = cose@ietf.org; Ivaylo Petrov ; ivaylo@ackl.io Subject: Robert Wilton's No Objection on draft-ietf-cose-hash-algs-04: = (with COMMENT) Robert Wilton has entered the following ballot position for draft-ietf-cose-hash-algs-04: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thank you for this document, I found it easy to read and understand. A = few minor comments: 1. Introduction Indirect signing of content is a paradigm where the content is not directly signed, but instead a hash of the content is computed and that hash value, along with the hash algorithm, is included in the content that will be signed. Doing indirect signing allows for a signature to be validated without first downloading all of the content associated with the signature. This capability can be of even greater importance in a constrained environment as not all of the content signed may be needed by the device. Would it be better to write "along with an identifier for the hash = algorithm"? [JLS] Totally makes sense - done 1. Introduction The use of hashes to identify objects is something that has been very common. One of the primary things that has been identified by a hash function for secure message is a certificate. Two examples of this can be found in [ESS] and the newly defined COSE equivalents in [I-D.ietf-cose-x509]. Perhaps drop "newly defined"? [JLS] done 3.2. SHA-2 Hash Algorithms * *SHA-256* is probably the most common hash function used currently. SHA-256 is an efficient hash algorithm for 32-bit hardware. Is this intended to imply that SHA-256 is not an efficient hash = algorithm when running on 64-bit hardware? If so, that might be worth = explicitly stating, although it is implied by the description for = SHA-512/256. [JLS] I don't think so, the algorithm is less efficient than SHA-512 on = 64-bit hardware but without making the relative statement it is less = useful. I think that we are making statements about efficiency in the = next line is sufficiently close. 3.3. SHAKE Algorithms Would this be more clear to be titled as SHA-3 Algorithms? [JLS] No I don't think so. The SHA-3 family defined SHA3-256 and = SHAKE-256. I think that using SHAKE in the title makes it clear we are = not dealing with the first group of hash functions. JIM Thanks, Rob From nobody Tue Jun 9 10:37:13 2020 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 5072A3A0ACE; Tue, 9 Jun 2020 10:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=cert.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 Jwch6uiV4v2V; Tue, 9 Jun 2020 10:37:05 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 4368C3A0988; Tue, 9 Jun 2020 10:37:05 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 059Haqt9022512; Tue, 9 Jun 2020 13:36:52 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 059Haqt9022512 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1591724212; bh=NTYim7DEuWDJJAnrcERFzk/bLJPtag4dLZ14mqDNtWA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ZJf4rKHzner0BfGqAXMLS52YOPWpe4wq7nybx8WKoe3SP1IhR9ajeZBiP4juBuPte YwVXGJgwpp/ggxeeLcbJ9IhZjlax+zt8kOPfGS7AiPZ8uTxwqbb92ktWy84GOJk25v RufsiULTclyW5H244wraiNJ7V9tdWBgMxv/6B+g0= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 059HapZk009196; Tue, 9 Jun 2020 13:36:51 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 9 Jun 2020 13:36:51 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 9 Jun 2020 13:36:51 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Tue, 9 Jun 2020 13:36:51 -0400 From: Roman Danyliw To: "Nancy Cam-Winget (ncamwing)" , Jim Schaad , "secdir@ietf.org" CC: "cose@ietf.org" , "draft-ietf-cose-rfc8152bis-algs.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 Thread-Index: AQHWNeFt5VhUvxstA0OWoBPYMGiOqajQnTHA Date: Tue, 9 Jun 2020 17:36:51 +0000 Message-ID: <835a6903f5204feab56d4f76901bb0e1@cert.org> References: <159052818935.17307.5095159295288146706@ietfa.amsl.com> <041f01d635dd$ad489cf0$07d9d6d0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.211] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [COSE] Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 17:37:07 -0000 SGkgTmFuY3ksIHRoYW5rIHlvdSBmb3IgdGhpcyByZXZpZXcuICANCg0KSGkgSmltLCB0aGFuayB5 b3UgZm9yIGluY29ycG9yYXRpbmcgdGhlIGZlZWRiYWNrIGluIC0wOQ0KDQpJIGVudGVyZWQgYSBO byBPYmplY3Rpb24gYmFsbG90Lg0KDQpSZWdhcmRzLA0KUm9tYW4NCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBOYW5jeSBDYW0tV2luZ2V0IChuY2Ftd2luZykgPG5jYW13 aW5nQGNpc2NvLmNvbT4NCj4gU2VudDogRnJpZGF5LCBNYXkgMjksIDIwMjAgMTo0OSBQTQ0KPiBU bzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47IHNlY2RpckBpZXRmLm9yZw0K PiBDYzogY29zZUBpZXRmLm9yZzsgbGFzdC1jYWxsQGlldGYub3JnOyBkcmFmdC1pZXRmLWNvc2Ut cmZjODE1MmJpcy0NCj4gYWxncy5hbGxAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFNlY2RpciBs YXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlzLWFsZ3MtMDgNCj4g DQo+IEhpIEppbSwNCj4gVGhhbmtzIGZvciBhZGRyZXNzaW5nIHRoZSBjb21tZW50cyEgIEFuc3dl cnMgYmVsb3c6DQo+IA0KPiDvu79PbiA1LzI5LzIwLCAxMDoyMiBBTSwgIkppbSBTY2hhYWQiIDxp ZXRmQGF1Z3VzdGNlbGxhcnMuY29tPiB3cm90ZToNCj4gDQo+ICAgICBIaSBOYW5jeSwNCj4gDQo+ ICAgICBDb21tZW50cyBpbmxpbmUuDQo+IA0KPiAgICAgSmltDQo+IA0KPiANCj4gICAgIC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICAgICBGcm9tOiBOYW5jeSBDYW0tV2luZ2V0IHZpYSBE YXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4NCj4gICAgIFNlbnQ6IFR1ZXNkYXksIE1heSAy NiwgMjAyMCAyOjIzIFBNDQo+ICAgICBUbzogc2VjZGlyQGlldGYub3JnDQo+ICAgICBDYzogY29z ZUBpZXRmLm9yZzsgbGFzdC1jYWxsQGlldGYub3JnOyBkcmFmdC1pZXRmLWNvc2UtcmZjODE1MmJp cy0NCj4gYWxncy5hbGxAaWV0Zi5vcmcNCj4gICAgIFN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwg cmV2aWV3IG9mIGRyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlzLWFsZ3MtMDgNCj4gDQo+ICAgICBS ZXZpZXdlcjogTmFuY3kgQ2FtLVdpbmdldA0KPiAgICAgUmV2aWV3IHJlc3VsdDogSGFzIE5pdHMN Cj4gDQo+ICAgICBJT1RESVIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlzLWFs Z3MtMDgNCj4gDQo+ICAgICBSZXZpZXdlcjogTmFuY3kgQ2FtLVdpbmdldA0KPiANCj4gICAgIEkg aGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVj dG9yYXRlJ3PDiiBvbmdvaW5nDQo+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRz IGJlaW5nIHByb2Nlc3NlZCBieSB0aGXDiiBJRVNHLsOKw4pUaGVzZQ0KPiBjb21tZW50cyB3ZXJl IHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGXDiiBzZWN1cml0eSBhcmVh DQo+IGRpcmVjdG9ycy7DisOKRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0 cmVhdMOKIHRoZXNlIGNvbW1lbnRzDQo+IGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNv bW1lbnRzLg0KPiANCj4gICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGluaXRpYWwgc2V0 IG9mIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyB1c2VkIHRvDQo+IHByb3RlY3QgQ0JPUiwgSSBi ZWxpZXZlIHRoaXMgZG9jdW1lbnQgaXMgYWxtb3N0IHJlYWR5LCBiYXJyaW5nIHNvbWUgZWRpdG9y aWFsDQo+IG5pdHMgKEkgb25seSBtYWRlIGEgZmV3IGJlbG93KS4gIEluIGdlbmVyYWwsIHRoZSBk ZXNjcmlwdGlvbiBvZiB0aGUgImluaXRpYWwiDQo+ICAgICBzZXQgb2YgYWxnb3JpdGhtcyB1c2Vk IGluIENPU0UgbWFrZSBzZW5zZSBhbmQgaXQgaXMgZ29vZCB0byBzZWUgZWFjaCBzZWN0aW9uDQo+ IGNhcnJ5IHRoZWlyIG93biBzZWN1cml0eSBzZWN0aW9uIGZvciBiZXR0ZXIgbWFwcGluZyBvZiB0 aGUgY29uc2lkZXJhdGlvbnMgYmFzZWQNCj4gb24gdGhlIHNlY3VyaXR5IGFsZ29yaXRobSBhcHBs aWVkLiAgQXMgYSByZWFkZXIgKGxpa2UgbXlzZWxmKSB3aG8gaXMgbm90IGZ1bGx5DQo+IHZlcnNh bnQgdG8gdGhlIG51YW5jZXMgb2YgQ0JPUiBpdCB3YXMgYSBsaXR0bGUgaGFyZCB0byBmb2xsb3cg YXMgdGhlIHN0cnVjdHVyZXMNCj4gYW5kIHRheG9ub215IGlzIGRlc2NyaWJlZCBpbiB0aGUgY29t cGFuaW9uIGRyYWZ0IChkcmFmdC1pZXRmLWNvc2UtcmZjODE1MmJpcy0NCj4gc3RydWN0KS4gQXMg YSB3aG9sZSwgSSB0aGluayB0aGUgZG9jdW1lbnQgaXMgY2xvc2UgdG8gcmVhZHksIEkgb25seSBu b3RlZCBhIGZldw0KPiB0ZWNobmljYWwgYW5kIGVkaXRvcmlhbCBuaXRzIGZvciB0aGUgZWFybGll ciBzZWN0aW9ucyBiZWxvdzoNCj4gDQo+ICAgICBTZWN0aW9uIDIuMToNCj4gICAgIC0gV2hhdCBm aWVsZCBkb2VzIHRoZSBFQ0RTQSBhbGdvcml0aG0gdmFsdWUgbWFwIHRvPyBJIHByZXN1bWUgaXQg aXMgdGhlICdhbGcnDQo+ICAgICBmaWVsZCAoaWYgcHJlc2VudCk/IEJ1dCBzaG91bGQgYmUgbWFk ZSBleHBsaWNpdC4gLSBJdCBzZWVtcyB0aGF0IHRoZSAic2hvdWxkIg0KPiAgICAgaW4gdGhlIDR0 aCBwYXJhZ3JhcGggaXMgbm9ybWF0aXZlIChlLmcuIFNIT1VMRCkgYXMgaXQgaXMgbmVlZGVkIGZv cg0KPiBpbnRlcm9wZXJhYmlsaXR5LCBhbmQgcGVyaGFwcyBldmVuIGEgTVVTVCBhcyBJJ20gbm90 IHNlZWluZyBuZWdvdGlhdGlvbiBvcg0KPiBzZWxlY3Rpb24gb2YgY3VydmUgY2hvaWNlLiAgU28s IGlmIGl0IGlzIHRvIGJlIGltcGxpY2l0LCB0aGVuIGEgTVVTVCB3b3VsZCBiZSBtb3JlDQo+IGFw cHJvcHJpYXRlLg0KPiAgICAgW0pMU10gSSBoYXZlIGFkZGVkIHRleHQgdG8gc2VjdGlvbiAxLjMg KHRlcm1pbm9sb2d5KSB0byBkZXNjcmliZSB0aGUgY29udGVudHMNCj4gb2YgdGhlIHRhYmxlcyB0 byBtYWtlIHdoYXQgdGhlIHZhbHVlIGlzIGNsZWFyZXIuDQo+IFtOQ1ddIFRoYW5rcywgdGhhdCB3 aWxsIGhlbHAuDQo+IA0KPiAgICAgW0pMU10gVGhlcmUgaXMgbm8gbmVlZCB0byBuZWdvdGlhdGUg dGhlIGN1cnZlIGFzIHRoaXMgaXMgaW1wbGljaXQgZnJvbSB0aGUgc2l6ZQ0KPiBvZiB0aGUgc2ln bmF0dXJlLiAgVGhhdCBpcyBQLTI1NiBpcyBnb2luZyB0byBlbmQgdXAgd2l0aCB0d28gMjU2LWJp dCB2YWx1ZXMgYXMNCj4gdGhlIHNpZ25hdHVyZS4gIE9uZSBpbXBsaWNhdGlvbiBpcyB0aGF0IG9u bHkgYSBzaW5nbGUgY3VydmUgb2YgYW55IGdpdmVuIGxlbmd0aA0KPiBjYW4gYmUgYXNzaWduZWQg dG8gRUNEU0EsIHRodXMgdGhlIGVmZm9ydCB0byB1c2UgdGhlIEVkMjU1MTkgY3VydmUgd2l0aCBF Q0RTQQ0KPiByZXF1aXJlcyBhIGRpZmZlcmVudCBpZGVudGlmaWVyIHNvIHRoYXQgdGhlcmUgaXMg bm8gY29uZnVzaW9uIG9uIHdoYXQgY3VydmUgaXMNCj4gYmVpbmcgdXNlZC4gIFRoaXMgbWVhbnMg dGhhdCB0aGUgbGVuZ3RoIG9mIHRoZSBoYXNoIGFsZ29yaXRobSBpcyBub3QgcGFydCBvZiB0aGlz DQo+IHNlbGVjdGlvbiBwcm9jZXNzLiAgSXQgaXMgdGhlcmVmb3JlIHBvc3NpYmxlIHRvIHVzZSBT SEEtMjU2IHdpdGggUC01MjEgYW5kIFNIQS0NCj4gNTEyIHdpdGggUC0yNTYgKHRoZSBoYXNoIHZh bHVlIGlzIHRydW5jYXRlZCBpbiB0aGlzIGNhc2UpLiAgVGhlIG9ubHkgaXNzdWUgaXMgdGhhdA0K PiBpZiBhIHBpZWNlIG9mIGhhcmR3YXJlIHN1cHBvcnRzIHRoZSBQLTI1NiBjdXJ2ZSB0aGVuIGl0 IG1pZ2h0IG9ubHkgc3VwcG9ydCBTSEEtDQo+IDI1NiBhbmQgdGh1cyB3b3VsZCBub3QgYmUgYWJs ZSB0byB2YWxpZGF0ZSBhIHNpZ25hdHVyZSB0aGF0IHVzZXMgU0hBLTUxMi4NCj4gVGhlcmUgaXMg bm8gc3BlY2lhbCBzZWN1cml0eSBpc3N1ZSBoZXJlLCB0aGlzIGlzIGp1c3QgYSByZWNvbW1lbmRh dGlvbiBmb3IgbWFraW5nDQo+IHRoaW5ncyBtb3JlIGxpa2VseSB0byBzdWNjZWVkLiBUaGlzIGlz IHRoZSByZWFzb24gdGhhdCBpdCBpcyBub3QgYSAnU0hPVUxEJyBvcg0KPiAnTVVTVCcgYnV0IGlz IGFuICdzdWdnZXN0ZWQnLiAgRG9lcyB0aGlzIGJvdGggbWFrZSB0aGluZ3MgY2xlYXJlciBhbmQg cmVkdWNlDQo+IHRoZSBmZWVsaW5nIG9uIHlvdSBwYXJ0IHRoYXQgYSBzdHJvbmdlciBzdGF0ZW1l bnQgaXMgbmVlZGVkPw0KPiBbTkNXXSBBZ3JlZSB0aGF0IHRoZXJlIGlzIG5vIHNlY3VyaXR5IGlz c3VlLCBpdCB3YXMgbW9yZSBvZiBicmVha2luZw0KPiBpbnRlcm9wZXJhYmlsaXR5LiAgSSBkb24n dCBmZWVsIHN0cm9uZ2x5IGVpdGhlciB3YXksIGl0IHdhcyBieSB0aGUgd2F5IGl0IHJlYWRzLi4u LmlmDQo+IHlvdSB3YW50IHRvIGVuc3VyZSBpbnRlcm9wZXJhYmlsaXR5IHRoZSBpdCBzZWVtcyB0 aGF0IHN0cm9uZ2VyIGxhbmd1YWdlIHdvdWxkDQo+IGJlIG5lZWRlZCAoYnV0IHRoYXTigJlzIG15 IHBlcnNvbmFsIGJpYXMpLg0KPiANCj4gICAgIFNlY3Rpb24gMi4yOg0KPiAgICAgLSBUaGUgcmF0 aW9uYWxlVGhlcmUgbWF5IGJlIHNvbWUgY29ybmVyIGNhc2UgaW4gd2hpY2ggdGhlcmUgbWF5IGJl IGEgdmVyeQ0KPiBsYXJnZQ0KPiAgICAgKDJLPykgc3RydWN0dXJlIHRvIGJlIHByb3RlY3RlZC4g IEl0IHdvdWxkIGJlIGJldHRlciB0byBxdWFudGlmeSAiZXh0cmVtZWx5DQo+IGxhcmdlIiBvciBw ZXJoYXBzIGFub3RoZXIvYWRkaXRpb25hbCByYXRpb25hbGUgZm9yIHRoZSBuZWVkIHRvIE9OTFkg ZG8gUHVyZQ0KPiBlZERTQSBpcyB0aGUgaW50ZW50IGZvciBjb25zdHJhaW5lZCBkZXZpY2VzIG5v dCBoYXZlIGVub3VnaCBtZW1vcnkgdG8NCj4gY29tcHV0ZSB0aGUgYmxvY2sgdXBkYXRlcy4NCj4g DQo+ICAgICBbSkxTXSBJIGRvbid0IGtub3cgdGhhdCBJIHdvdWxkIGNvbnNpZGVyIGEgMksgbWVz c2FnZSB0byBiZSB2ZXJ5IGxhcmdlLCBJDQo+IHdvdWxkIGV4cGVjdCBhIGZpcm13YXJlIHVwZGF0 ZSB0byBiZSBhdCBsZWFzdCB0aGF0IGxhcmdlLiAgVGhlIGlzc3VlIGlzIHRoYXQNCj4gRWREU0Eg bmVlZHMgdG8gZG8gdHdvIHBhc3NlcyBvdmVyIHRoZSBtZXNzYWdlLCB0aGlzIG1lYW5zIHRoYXQg dGhlIGVudGlyZQ0KPiBtZXNzYWdlIG5lZWRzIHRvIGJlIGhlbGQgaW4gbWVtb3J5LiAgVGhhdCB3 b3VsZCBiZSBsaW1pdGF0aW9uIG9uIHdoYXQgSQ0KPiB3b3VsZCBjb25zaWRlciB0byBiZSAiZXh0 cmVtZWx5IGxhcmdlIi4gIFRoZSBwcmVzdW1wdGlvbiBpcyB0aGF0IG9uZSBpcyBub3QNCj4gZ29p bmcgdG8gdHJ5IGFuZCBjcmVhdGUgYW5kIHN0cmVhbSB0aGUgb2JqZWN0IG91dCBhcyB0aGlzIHdv dWxkIGFsc28gcmVxdWlyZSBhDQo+IHN0cmVhbWluZyBwcm9jZXNzaW5nIG9uIHRoZSByZWNpcGll bnQuICBJZiBzdHJlYW1pbmcgaXMgcmVtb3ZlZCBmcm9tIHRoZQ0KPiBlcXVhdGlvbiB0aGVuIHRo ZXJlIGlzIG5vIGJlbmVmaXQgbm90IHRvIHVzZSBQdXJlIEVkRFNBLiAgIFRoaXMgbWVhbnMgdGhh dCBvbmVzDQo+IGlkZWEgb2YgbGFyZ2UgaXMgZ29pbmcgdG8gYmUgdmVyeSBkZXZpY2Ugc3BlY2lm aWMuICBJIHdpbGwgbm90IGJlIHN1cnByaXNlZCBpZiBzb21lDQo+IGZpcm13YXJlIHBhY2thZ2Vz IGRvIGluZGlyZWN0IHNpZ25pbmcsIGJ1dCB0aGUgbWFuaWZlc3QgZGVzY3JpcHRpb24gaXMgc3Rp bGwgZ29pbmcNCj4gdG8gbmVlZCB0byBmaXQgaW4gbWVtb3J5Lg0KPiBbTkNXXSAyS2J5dGVzIGNh biBzZWVtIHZlcnkgbGFyZ2UgdG8gc29tZSBJb1QgZGV2aWNlcyBfXy4gIEJ1dCB5b3VyIHBvaW50 IGlzDQo+IHdlbGwgdGFrZW4uLi5zb3JyeSBpZiBJIHdhcyB0b28gbml0LXBpY2t5Li4uLmFzIGZv ciBndWlkYW5jZSBJIHBlcnNvbmFsbHkgcHJlZmVyIHRvDQo+IGhhdmUgcXVhbnRpZmljYXRpb24g KHJhbmdlcykuDQo+IA0KPiAgICAgU2VjdGlvbiA0LjEuMToNCj4gICAgIC0gR0NNJ3MgbGltaXRh dGlvbiBmb3Igb25lIGVuY3J5cHRpb24gc3RyaW5nIGlzIDJeMzktMjU2IGUuZy4gbm90ICJhIHNp bmdsZQ0KPiBrZXkiLi4uLnNvIHN1ZmZpY2llbnRseSBsYXJnZSBmb3IgQ09TRSEgIEhvd2V2ZXIs IGl0IGRvZXMgbWVhbiB0aGF0IHRoZSBub25jZQ0KPiBNVVNUIGJlIHVuaXF1ZSBmb3IgZXZlcnkg ZW5jcnlwdGVkIG1lc3NhZ2UgKGUuZy4gdGhlIGJ1bGxldCBiZWZvcmUgdGhpcyBvbmUgaXMNCj4g Y29ycmVjdCkuICBJIHRoaW5rIHRoZSBsaW1pdCBmb3Igb25lIGtleSB1c2luZyBHQ00gaXMgYmFz ZWQgb24gdGhlIHNpemUgb2YgdGhlDQo+IG5vbmNlIGFzIGl0IG11c3QgYmUgdW5pcXVlLg0KPiAg ICAgW0pMU10gWW91IGFyZSBnb2luZyB0byBtYWtlIG1lIGxvb2sgdGhpcyB1cCBhZ2Fpbi4gIEhv d2V2ZXIgSSB0aGluayB0aGF0IHRoaXMNCj4gbGltaXQgbWF5IGVuZCB1cCBiZWluZyBzbWFsbGVy IHdpdGggbW9yZSBtb2Rlcm4gYW5hbHlzaXMgc28gZ29pbmcgYmFjayBhbmQNCj4gcmUtLWNoZWNr aW5nIHRoaXMgaXMgZ29pbmcgdG8gYmUgd29ydGh3aGlsZS4gIEl0IGp1c3Qgd2lsbCB0YWtlIGEg ZmV3IGRheXMuDQo+IFtOQ1ddIE5vIHdvcnJpZXMsIGFzIGFuIGVhcmx5IGFkb3B0ZXIgb2YgR0NN LCBJIGRvIHJlY2FsbCB0aGF0IG51bWJlciBiZWluZw0KPiBmb3IgYSBwYWNrZXQuLi4uDQo+IA0K PiAgICAgU2VjdGlvbiA0LjI6DQo+ICAgICAtICdrJyBpcyB0aGUga2V5IHNpemUgaW4gYml0cyAo SSBwcmVzdW1lKSwgd291bGQgYmUgZ29vZCB0byBkZXNjcmliZSB0aGF0IGJlZm9yZQ0KPiB0aGUg dGFibGUuDQo+ICAgICBbSkxTXSBJIGNoYW5nZWQgdGhlIHRpdGxlIG9mIHRoZSBjb2x1bW4gdG8g J0tleSBMZW5ndGgnDQo+IFtOQ1ddIFRoYW5rcy4NCj4gDQo+ICAgICBFZGl0b3JpYWwgbml0czoN Cj4gICAgIFNlY3Rpb24gMS41DQo+ICAgICAtIFRoZSBzZWNvbmQgc2VudGVuY2UgaXMgaGFyZCB0 byBwYXJzZS4gIElzIGl0IHRoYXQgdGhlIGludGVybWVkaWF0ZSB2YWx1ZXMNCj4gdXNlZCBmb3Ig ZGVidWdnaW5nIGFyZSByZXByZXNlbnRlZCBpbiBib3RoIGEgaGV4IGFzIHdlbGwgYXMgYSBDQk9S IGRpYWdub3N0aWMNCj4gbm90YXRpb24gZm9ybWF0Ij8gLSBUaGlyZCBzZW50ZW5jZSwgaXMgaXQg dGhhdCBzb21lIGV4YW1wbGVzIHdlcmUgZGVzaWduZWQgdG8NCj4gZmFpbCAoZS5nLiB0aGV5IGFy ZSAiZmFpbHVyZSB0ZXN0IGJhc2VzIik/DQo+ICAgICBbSkxTXSAgSSBoYXZlIHVwZGF0ZWQgdGhp cyBzZWN0aW9uLiAgSSB0aGluayB0aGF0IHRoaXMgc2hvdWxkIHNvbHZlIHlvdXIgaXNzdWVzLg0K PiAgICAgICAgICAgICA8dD4NCj4gICAgICAgICAgICAgICBBIEdpdEh1YiBwcm9qZWN0IGhhcyBi ZWVuIGNyZWF0ZWQgYXQgJmx0O2h0dHBzOi8vZ2l0aHViLmNvbS9jb3NlLQ0KPiB3Zy9FeGFtcGxl cyZndDsgdGhhdCBjb250YWlucyBhIHNldCBvZiB0ZXN0aW5nIGV4YW1wbGVzIGFzIHdlbGwuDQo+ ICAgICAgICAgICAgICAgRWFjaCBleGFtcGxlIGlzIGZvdW5kIGluIGEgSlNPTiBmaWxlIHRoYXQg Y29udGFpbnMgdGhlIGlucHV0cyB1c2VkIHRvDQo+IGNyZWF0ZSB0aGUgZXhhbXBsZSwgc29tZSBv ZiB0aGUgaW50ZXJtZWRpYXRlIHZhbHVlcyB0aGF0IGNhbiBiZSB1c2VkIGZvcg0KPiBkZWJ1Z2dp bmcsIGFuZCB0aGUgb3V0cHV0IG9mIHRoZSBleGFtcGxlLg0KPiAgICAgICAgICAgICAgIFRoZSBy ZXN1bHRzIGFyZSBlbmNvZGVkIHVzaW5nIGJvdGggaGV4YWRlY2ltYWwgYW5kIENCT1IgZGlhZ25v c3RpYw0KPiBub3RhdGlvbiBmb3JtYXQuDQo+ICAgICAgICAgICAgIDwvdD4NCj4gICAgICAgICAg ICAgPHQ+DQo+ICAgICAgICAgICAgICAgU29tZSBvZiB0aGUgZXhhbXBsZXMgYXJlIGRlc2lnbmVk IHRvIHRlc3QgZmFpbHVyZSBjYXNlOyB0aGVzZSBhcmUNCj4gY2xlYXJseSBtYXJrZWQgYXMgc3Vj aCBpbiB0aGUgSlNPTiBmaWxlLg0KPiAgICAgICAgICAgICAgIElmIGVycm9ycyBpbiB0aGUgZXhh bXBsZXMgaW4gdGhpcyBkb2N1bWVudCBhcmUgZm91bmQsIHRoZSBleGFtcGxlcyBvbg0KPiBHaXRI dWIgd2lsbCBiZSB1cGRhdGVkLCBhbmQgYSBub3RlIHRvIHRoYXQgZWZmZWN0IHdpbGwgYmUgcGxh Y2VkIGluIHRoZSBKU09OIGZpbGUuDQo+ICAgICAgICAgICAgIDwvdD4NCj4gICAgIFtOQ1ddIFRo YW5rIHlvdSwgSSBjYW4gcGFyc2UgdGhpcyBiZXR0ZXIuDQo+IA0KPiAgICAgU2VjdGlvbiAyLjI6 DQo+ICAgICAtIFRoZSByYXRpb25hbGUgZm9yIHdoeSBQdXJlIEVkRFNBIGlzIHVzZWQgb25seSAo dnMuIEhhc2hFZERTQSkgbWF5IGxlYXZlDQo+IG1vcmUgcm9vbSBmb3IgcXVlc3Rpb25zOyBhcyB0 aGVyZSBtYXkgYmUgc29tZSBjb3JuZXIgY2FzZSBpbiB3aGljaCB0aGVyZSBtYXkNCj4gYmUgYSB2 ZXJ5IGxhcmdlICgySz8pIHN0cnVjdHVyZSB0byBiZSBwcm90ZWN0ZWQuICBGb3IgdGhvc2UgdGhh dCBhcmUgaW4gdGhlDQo+IGhlYWx0aGNhcmUgc2VjdG9yIChvZiBJb1QpLCBJIGNvdWxkIHNlZSBw b3RlbnRpYWwgZm9yIGxhcmdlIGJsb2NrcyBhbmQgbWF5IHdvbmRlcg0KPiB3aGF0IHF1YWxpZmll cyBhcyAiZXh0cmVtZWx5IGxhcmdlIi4gIFJGQyA4MDMyIHNwZWFrcyB0byBIYXNoRWREU0EgYXMN Cj4gcHJvdmlkaW5nIGJldHRlciBjb2xsaXNpb24gcmVzaWxpZW5jZS4uLnNvIGFtIGluY2xpbmVk IHRvIHN1Z2dlc3QgdG8gZWl0aGVyIHJlbW92ZQ0KPiB0aGlzIHJhdGlvbmFsZSBvciBiZSBtb3Jl IGNvbXBsZXRlIGluIGp1c3RpZmljYXRpb24uDQo+ICAgICBbSkxTXSBTZWUgYWJvdmUuDQo+IFtO Q1ddIE9LDQo+IA0KPiAgICAgU2VjdGlvbiAzLjENCj4gICAgIC0gM3JkIHBhcmFncmFwaDogIlNv bWUgcmVjaXBpZW50IGFsZ29yaXRobXMgY2FycnkgdGhlIGtleSB3aGlsZSBvdGhlcnMgZGVyaXZl DQo+IGEga2V5IGZyb20gc2VjcmV0IGRhdGEiLi4uLkkgdGhpbmsgeW91IG1lYW4gIlNvbWUgYWxn b3JpdGhtcyBhcmUgdXNlZCB0bw0KPiB0cmFuc21pdCBhIGtleSwgZS5nLiBrZXkgd3JhcHBpbmcu IiAgIkNhcnJ5IHRoZSBrZXkiLCBpbiB0aGlzIHNlbnRlbmNlIGxlYWRzIG1lDQo+IHRvIGltcGx5 IGl0J3MgdGhlIHNhbWUga2V5IGJlaW5nIHVzZWQgaW4gdGhlIEhNQUMuDQo+ICAgICBbSkxTXSAg VGhpcyBpcyB0aGUgc2FtZSBrZXkgdGhhdCBpcyBiZWluZyB1c2VkIGluIHRoZSBITUFDIGFsZ29y aXRobS4gIEkgaGF2ZQ0KPiBjaGFuZ2VkICJjYXJyeSIgdG8gInRyYW5zcG9ydCIgYmVjYXVzZSBJ IHRoaW5rIHRoYXQgaXMgZ29pbmcgdG8gYmUgY2xlYXJlci4NCj4gW05DV10gWWVzLCBpbmRlZWQs IHRoYXQgbWFrZXMgaXQgYmV0dGVyLg0KPiANCj4gDQo+IA0KPiANCg0K From nobody Tue Jun 9 11:16:38 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C52A3A0C44; Tue, 9 Jun 2020 11:16:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller , linuxwolf+ietf@outer-planes.net X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <159172658835.26172.4590101163395195141@ietfa.amsl.com> Date: Tue, 09 Jun 2020 11:16:28 -0700 Archived-At: Subject: [COSE] Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 18:16:28 -0000 Robert Wilton has entered the following ballot position for draft-ietf-cose-rfc8152bis-algs-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, I've only reviewed the diff against RFC8152. The vast majority of this document seemed to have only minimal changes and looked fine from what I could see. A few minor comments that may help improve the document: Abstract Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. COSE additionally describes how to represent cryptographic keys using CBOR. In this specification the conventions for the use of a number of cryptographic algorithms with COSE. First sentence of the second paragraph doesn't quite scan, and I wasn't convinced that the first paragraph is necessarily correct/accurate after the document split (in particular the "This document" and "This specification" bits). Section 7.2 x: This contains the public key. The byte string contains the public key as defined by the algorithm. (For X25591, internally it is a little-endian integer.) d: This contains the private key. One minor thing that I noted, is that you define that the public key is defined by the algorithm, but don't say the same thing for the private key. If you change this, then you might want to check other references to "private key" as well. 8. COSE Capabilities The concept is being pulled forward and defined now for COSE. Perhaps rephrase this to: "This document defines the same concept for COSE." 8. COSE Capabilities The algorithm identifier is not part of the capabilities data as it should already be part of message structure. There is a presumption in the way that this is laid out is that the algorithm identifier itself is not needed to be a part of this as it is specified in a different location. I found the second sentence somewhat unclear and could probably be wordsmithed, in particular does "this" refer to the capabilities data or the message structure. 8. COSE Capabilities Two different types of capabilities are defined: capabilities for algorithms and capabilities for key structures. Once defined by registration with IANA, the list of capabilities is immutable. If it is later found that a new capability is needed for a key type or an algorithm, it will require that a new code point be assigned to deal with that. As a general rule, the capabilities are going to map to algorithm-specific header parameters or key parameters, but they do not need to do so. An example of this is the HSS-LMS key capabilities defined below where the hash algorithm used is included. Defining the capabilities list as immutable seemed like a misnomer to me because a new IANA registration would mutate the list. Perhaps this sentence, and the one following it, could be removed? The capability structure is an array of values, the order being dependent on the specific algorithm or key. For an algorithm, the first element should always be a key type value, but the items that are specific to a key should not be included in the algorithm capabilities. This means that if one wishes to enumerate all of the capabilities for a device which implements ECDH, it requires multiple pairs of capability structures (algorithm, key) to deal with the different key types and curves that are supported. For a key, the first element should also be a key type value. While this means that this value will be duplicated if both an algorithm and key capability are used, the key type is needed in order to understand the rest of the values. Should you be using RFC 2119 language here? And should " key should not be included" be "MUST NOT"? For the ECDH case, does that mean that the "algorithm" entry will be duplicated with different "key" entries? If so, would it help clarify to explicitly state this? Thanks, Rob From nobody Tue Jun 9 12:07:52 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2062C3A0DF0; Tue, 9 Jun 2020 12:07:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <159172966432.25988.15915230396771082634@ietfa.amsl.com> Date: Tue, 09 Jun 2020 12:07:45 -0700 Archived-At: Subject: [COSE] Alvaro Retana's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 19:07:50 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-cose-rfc8152bis-algs-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) I am concerned -- confused may be a better word -- about the status of this document for several reasons: (a) The header on this document still says that it is intended to remain in the Standards Track -- but the datatracker says that is should be Informational. This is simply a nit. (b) Except for a note when the publication was requested [1], I didn't find any other discussion in the mail archive. Was the status discussed in the WG? The Shepherd writeup [2] does say that the status "marks the state of consensus at the time of publication, and allows for the flexibility to deprecate and obsolete in the future." Except for potentially a higher bar when updating an Internet Standard, the process is the same... (c) The fact that this document resulted from the split of rfc8152 confuses me even more: the "other half" (rfc8152bis-struct) is moving on as an Internet Standard and it includes a Normative reference to this document. Note that the Normative reference makes sense, but the Informational status of this document doesn't...at least to me. Even though we can use DownRefs, it seems unnecessary to "downgrade" this part of the document and end up with a downref to an Informational document... This is a non-blocking comment...I simply don't understand. [1] https://mailarchive.ietf.org/arch/msg/cose/tVDVZtfBhfYsKiqT0kCtkGoL_2U/ [2] https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/shepherdwriteup/ (2) §10.1/§10.2: The references should be changed from rfc8152 to this document. (3) §10.2 (Changes to "COSE Algorithms" registry) IANA is requested to create a new column in the "COSE Algorithms" registry. The new column is to be labeled "Capabilities". The new column is populated with "[kty]" for all current, non-provisional, registrations. It is expected that the documents which define those algorithms will be expanded to include this registration, if this is not done then the DE should be consulted before final registration for this document is done. I am not sure what is the expectation here; a new column is added and all the entries are populated with "[kty]" -- so far so good. What I don't understand is the part about other "documents...will be expanded to include this registration". Does that mean that the other documents need to be updated? What should the DE do if the work is not completed? I am even more confused because this document doesn't seem to take an action related to that new column for the algorithms defined here, and the new row (in this same section) doesn't include the Capabilities column. (4) §10.2: "Note to IANA: There is an action in [I-D.ietf-cose-rfc8152bis-struct] which also modifies data in the reference column." I didn't see that action in the other document. (5) I assume that this document (and not -struct) should also update the COSE Elliptic Curves registry. From nobody Tue Jun 9 12:43:42 2020 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 C73643A0D3C; Tue, 9 Jun 2020 12:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 2pcXD8S2rwqq; Tue, 9 Jun 2020 12:43:38 -0700 (PDT) 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 A18043A0D3D; Tue, 9 Jun 2020 12:43:37 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 9 Jun 2020 12:43:31 -0700 From: Jim Schaad To: 'Roman Danyliw' , 'The IESG' CC: , , , 'Matthew Miller' References: <159172362923.2755.16291108469492738933@ietfa.amsl.com> In-Reply-To: <159172362923.2755.16291108469492738933@ietfa.amsl.com> Date: Tue, 9 Jun 2020 12:43:28 -0700 Message-ID: <00b301d63e96$424c6e10$c6e54a30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKLAkCkuXQIK2s7hNAL4uZNM+vW/qdnCbpA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Roman Danyliw's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 19:43:40 -0000 -----Original Message----- From: Roman Danyliw via Datatracker =20 Sent: Tuesday, June 9, 2020 10:27 AM To: The IESG Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; = cose@ietf.org; Matthew Miller ; = linuxwolf+ietf@outer-planes.net Subject: Roman Danyliw's No Objection on = draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) Roman Danyliw has entered the following ballot position for draft-ietf-cose-rfc8152bis-algs-09: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the easy to read diff on a bis document, and for addressing = the SecDir feedback. ** Section 8. Per =E2=80=9CFor an algorithm, the first element should = always be a key type value, but the items that are specific to a key = should not be included in the algorithm capabilities=E2=80=9D and later = =E2=80=9CFor a key, the first element should also be a key type = value=E2=80=9D is there a reason for not making these = =E2=80=9Cshould=E2=80=9D into normative MUSTs? [JLS] Yes, consider what the capabilities would be for a hash algorithm, = it has no key so that would make the first one not a MUST. This is = advisory, after it is set then it is going to be known and not changed. = This means that all one needs to know in the end is what the sequence = is. ** Section 8. I would have benefited from more text to understand how = to parse a capabilities field. IMO, it would have been helpful to say = that the first element of the array maps to the Value column of the COSE = Key Type registry.=20 The new Capabilities column of that corresponding entry describes the = semantics of the second array element. [JLS] Given the above do you still feel this way? ** Editorial Nits: -- The text in the header notes this document is standards track. = However, the datatracker and shepherd write-up note that it is = informational. I suspect it should be fixed in this document to be = informational. [JLS] The document is wrong and fixed. -- Abstract. Please remove the explicit references from abstract (as = they are not permitted to be there) [JLS] As I have noted elsewhere, for drafts I prefer this to make sure = that it is seen by the RFC Editor and corrected. -- Abstraction. Editorial. The sentence =E2=80=9CIn this specification = the conventions =E2=80=A6=E2=80=9D is incomplete. [JLS] Changed to "This specification defines the conventions for the use = of a number of cryptographic algorithms with COSE." -- Section 1. Editorial. =E2=80=9CAdditional algorithms beyond what = are in this document are defined elsewhere=E2=80=9D. IMO, this sentence = doesn=E2=80=99t appear to add anything. Recommend removal. [JLS] Done - I guess the word 'initial' makes the point that other can = be defined.=20 -- Section 8. Per =E2=80=9DThere is a presumption in the way that this = is laid out is that the algorithm identifier itself is not needed to be = a part of this as it is specified in a different location=E2=80=9D, I = had trouble following this sentence from the previous one =E2=80=93 what = is the double reference to =E2=80=9Cthis=E2=80=9D here? [JLS] How about "The algorithm identifier is not included in the = capabilities data as it should be encoded elsewhere in the message." -- Section 8.3. Typo. s/it is encodes/, they encode/ [JLS] Already rewritten -- Section 10.2. Typo. s/rquested/requested/ [JLS] Fixed. From nobody Tue Jun 9 16:13:32 2020 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 EE5BC3A0BE5; Tue, 9 Jun 2020 16:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Y6XcH0epcBaE; Tue, 9 Jun 2020 16:13:25 -0700 (PDT) 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 82CB63A09AF; Tue, 9 Jun 2020 16:13:24 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 9 Jun 2020 16:13:17 -0700 From: Jim Schaad To: 'Robert Wilton' , 'The IESG' CC: , , , 'Matthew Miller' References: <159172658835.26172.4590101163395195141@ietfa.amsl.com> In-Reply-To: <159172658835.26172.4590101163395195141@ietfa.amsl.com> Date: Tue, 9 Jun 2020 16:13:15 -0700 Message-ID: <00c301d63eb3$9039bf20$b0ad3d60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGt8PvhRubwAU5WHR14eMnKEkUjf6khTNng Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 23:13:27 -0000 -----Original Message----- From: Robert Wilton via Datatracker =20 Sent: Tuesday, June 9, 2020 11:16 AM To: The IESG Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; = cose@ietf.org; Matthew Miller ; = linuxwolf+ietf@outer-planes.net Subject: Robert Wilton's No Objection on = draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) Robert Wilton has entered the following ballot position for draft-ietf-cose-rfc8152bis-algs-09: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, I've only reviewed the diff against RFC8152. The vast majority of this document seemed to have only minimal changes and looked fine from what I = could see. A few minor comments that may help improve the document: Abstract Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. COSE additionally describes how to represent cryptographic keys using CBOR. In this specification the conventions for the use of a number of cryptographic algorithms with COSE. First sentence of the second paragraph doesn't quite scan, and I wasn't = convinced that the first paragraph is necessarily correct/accurate after = the document split (in particular the "This document" and "This = specification" bits). [JLS] Fixed in reply to Roman's comment. Section 7.2 x: This contains the public key. The byte string contains the public key as defined by the algorithm. (For X25591, internally it is a little-endian integer.) d: This contains the private key. One minor thing that I noted, is that you define that the public key is = defined by the algorithm, but don't say the same thing for the private = key. If you change this, then you might want to check other references = to "private key" as well. [JLS] Under normal circumstances I would have omitted the definition of = the public key from that text. The problem is that there has been a lot = of issues with this because it is the reverse of what is normally done. = Almost all integers are normally big-endian in cryptograph, and thus I = am highlighting a single case where it is not. I will also point to the = existence of = https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-09 = which uses the same curve under a different representation and done the = big-endian encoding. =20 8. COSE Capabilities The concept is being pulled forward and defined now for COSE. Perhaps rephrase this to: "This document defines the same concept for = COSE." [JLS] That is better than the wording from Roman - updated to use this. 8. COSE Capabilities The algorithm identifier is not part of the capabilities data as it should already be part of message structure. There is a presumption in the way that this is laid out is that the algorithm identifier itself is not needed to be a part of this as it is specified in a different location. I found the second sentence somewhat unclear and could probably be = wordsmithed, in particular does "this" refer to the capabilities data or = the message structure. [JLS] This has already been changed in response to Roman. 8. COSE Capabilities Two different types of capabilities are defined: capabilities for algorithms and capabilities for key structures. Once defined by registration with IANA, the list of capabilities is immutable. If it is later found that a new capability is needed for a key type or an algorithm, it will require that a new code point be assigned to deal with that. As a general rule, the capabilities are going to map to algorithm-specific header parameters or key parameters, but they do not need to do so. An example of this is the HSS-LMS key capabilities defined below where the hash algorithm used is included. Defining the capabilities list as immutable seemed like a misnomer to me = because a new IANA registration would mutate the list. Perhaps this = sentence, and the one following it, could be removed? [JLS] The whole object is that once registered with IANA, it will never = be changed even by IANA. Thus I believe that the word immutable seems = to be correct. If this is changed then existing signatures will fail = and key derivation functions will generate different results. The capability structure is an array of values, the order being dependent on the specific algorithm or key. For an algorithm, the first element should always be a key type value, but the items that are specific to a key should not be included in the algorithm capabilities. This means that if one wishes to enumerate all of the capabilities for a device which implements ECDH, it requires multiple pairs of capability structures (algorithm, key) to deal with the different key types and curves that are supported. For a key, the first element should also be a key type value. While this means that this value will be duplicated if both an algorithm and key capability are used, the key type is needed in order to understand the rest of the values. Should you be using RFC 2119 language here? And should " key should not = be included" be "MUST NOT"? [JLS] Responded to this point in Roman's comments. For the ECDH case, does that mean that the "algorithm" entry will be = duplicated with different "key" entries? If so, would it help clarify = to explicitly state this? [JLS] Would pointing to the second and third examples in section 8.3 = along with some explanatory text? Jim Thanks, Rob From nobody Tue Jun 9 22:23:04 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7693A0EED; Tue, 9 Jun 2020 22:22:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller , linuxwolf+ietf@outer-planes.net X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <159176657029.21875.10088343710386665224@ietfa.amsl.com> Date: Tue, 09 Jun 2020 22:22:50 -0700 Archived-At: Subject: [COSE] Martin Duke's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 05:22:51 -0000 Martin Duke has entered the following ballot position for draft-ietf-cose-rfc8152bis-algs-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As everyone else has pointed out, the header needs to be fixed to indicate this is Informational, not Standards Track. Section 1. s/messages transport/message transport s/of the Javascript/of Javascript Sec 1.3 In the definitions of “AE” and “AEAD”, I don’t understand the functional difference between authentication of “plaintext contents” (AE) and authentication of “non-encrypted data” (AEAD). AFAICT AE isn’t actually used in the document, so it might be easiest to simply delete it. Sec 1.5. Replace the URL with a reference. I actually read this whole document but got pretty lost by the end, not being an expert in this area. From nobody Wed Jun 10 00:34:06 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E87C03A0F7B; Wed, 10 Jun 2020 00:34:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, cose@ietf.org, cose-chairs@ietf.org, ivaylo@ackl.io X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159177444333.30369.600152988644484089@ietfa.amsl.com> Date: Wed, 10 Jun 2020 00:34:03 -0700 Archived-At: Subject: [COSE] cose - New Meeting Session Request for IETF 108 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 07:34:04 -0000 A new meeting session request has just been submitted by Ivaylo Petrov, a Chair of the cose working group. --------------------------------------------------------- Working Group Name: CBOR Object Signing and Encryption Area Name: Security Area Session Requester: Ivaylo Petrov Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: core dispatch lamps lpwan saag secdispatch Technology Overlap: cfrg rats teep Key Participant Conflict: ace cbor People who must be present: Matthew A. Miller Benjamin Kaduk Ivaylo Petrov Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jun 10 04:03:33 2020 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 E021B3A0933; Wed, 10 Jun 2020 04:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TYjLZUqK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=o6rnkpMK 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 QS_ZYXVqCWy0; Wed, 10 Jun 2020 04:03:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD673A091C; Wed, 10 Jun 2020 04:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12374; q=dns/txt; s=iport; t=1591787006; x=1592996606; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mWLNZ5nrMbUc9m7GKJIdLTxptdKtW4qKQiCzIvgGJco=; b=TYjLZUqKemm+wjQlDhJ+eF3uqwEOVfJouTlAEUNhqDLGoPUQrpjNbQWA hcDamPrKjw5c6rdSJKqaBD/JbZmxlnfl+VWJ8uFFfQxpEpT0ij4FumNIm XSJ1HPQmp8BnXFyNO2P9YsUL/c4h/sKlSfIoX0dN+kkXJKmvWlrvBQ24u M=; IronPort-PHdr: =?us-ascii?q?9a23=3Ac4XKZRQ28u9WqOj1CoyQqlQdvtpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBt+J4u9LlvHKuK3kXWUa+tCKt3VROJBPVh?= =?us-ascii?q?pQj8IQkkRgBcOeEkT0IbbsaDByB8VNUlJpvhTZeUhYEcrzfRve93u16zNBEw?= =?us-ascii?q?jwKBFpLenxHofIlIK80OXhs5HWah9D0Ty6Z746JR6qrALX488Rh4YHSO4xxx?= =?us-ascii?q?LFr2EOdf5RwDZjJEmYmFD34cLj8Q=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwBQCXveBe/4kNJK1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUlIHb1gvLAqEGoNGA41EmFKBQoEQA1ULAQEBDAEBIwo?= =?us-ascii?q?CBAEBhEQCF4IAAiQ4EwIDAQELAQEFAQEBAgEGBG2FLgglDIVyAQEBAQIBEhE?= =?us-ascii?q?RDAEBNwELBAIBCA4DBAEBAwImAgICMBUICAIEAQ0FCBqDBYJLAw4gAQMLpxw?= =?us-ascii?q?CgTmIYXaBMoMBAQEFgUZBg2IYgg4DBoEOKoJkiW8agUE/gRABQ4JNPoJnAQE?= =?us-ascii?q?BAgGBLAESAQccJIJuM4ItjwWDDqILCoJZiDmGHIVXhQGCbYkThRWNPZEMige?= =?us-ascii?q?OMIVmAgQCBAUCDgEBBYFqImZYEQdwFTuCaVAXAg2DNIpqCwEXFYM6hRSFQnQ?= =?us-ascii?q?CNQIGCAEBAwl8jgUBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.73,495,1583193600"; d="scan'208";a="770183149" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Jun 2020 11:03:18 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 05AB3I94025514 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Jun 2020 11:03:18 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 10 Jun 2020 06:03:18 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 10 Jun 2020 06:03:17 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 10 Jun 2020 07:03:17 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KrQyYWwKGNiSzivjr+YSWR2WAN8PzwpsmSY9c+JSlXusydu38Oj4M9ZNEM9Lw6GlHnAIm6lvZQfv/0/AP1nif/oR5bWWzFMJFa7EYtIVWg/ViN0rREr/ovYTSMpzoP76Yr/SnopA4w1Vzy5MDnu3e8er0mAp4U8XWAPHlP+2vQRYgPKbVQHFq/EKttnxdnoV0IdnS/g64Y37msqFClyD2AM80A39/2pgyqejrrjH6ofz45DY6UXGOMxyEDE8Em+DbXOyroq8W0TjBnnNsDvVLZXixY+Q3g8WhobRKeH7PCyyIw4/DEtXOoNQU3wP7ycaSlVJ45Itq7EmFwamqbTP+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mWLNZ5nrMbUc9m7GKJIdLTxptdKtW4qKQiCzIvgGJco=; b=BqwNzCAMim+9dhQFD87ypJdEP8dIn6NxeThjKpOd1fcCYoe6FtbE6fWwz37KQdUCKpoCEoxy05jHIgU6HlJ9IetoBL+a67K6DNxzn8ASc6thVa764kYcgjeQkj4h9klDhsdLAfz84CWtDRFjMBCIWV0JTxfC7uiU++JIaQLNDrcuCNQfrrNCzmsiAemZGrS6r67yoBVrJy1VDOodqODgnkhdb5h6YPqui7YJwQp+6KhmGBukKq6Z8JlrB71EyBDaTsmQI/BYY7MhsWwjdxZ+VdnnA+lMYqNAaAMTYdTqiw/nIBT+XFNht7YTO5KSO05r9JpluxxAfsbMoMqLAiCWwg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mWLNZ5nrMbUc9m7GKJIdLTxptdKtW4qKQiCzIvgGJco=; b=o6rnkpMKiemOE72WVWxQGFkawBzxKsOZPuIHWvbWhz5+/KwoWcTdoA5DejMiNazLQdja5joh7Jat4iJJSOSSCo7GRE5lquw/PEGM50/qAaP732MKKSLbVz0cR+OFhN/Voh1lQfwdzs955EHkYSwYzb3DG2obTFEcXDzF47lISWI= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB3549.namprd11.prod.outlook.com (2603:10b6:208:e9::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Wed, 10 Jun 2020 11:03:16 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18%5]) with mapi id 15.20.3066.023; Wed, 10 Jun 2020 11:03:16 +0000 From: "Rob Wilton (rwilton)" To: Jim Schaad , "'The IESG'" CC: "draft-ietf-cose-rfc8152bis-algs@ietf.org" , "cose-chairs@ietf.org" , "cose@ietf.org" , "'Matthew Miller'" Thread-Topic: Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) Thread-Index: AQHWPoog2C1ANtZ1AUyxZq1l8KMrnajQ6gaAgACcDMA= Date: Wed, 10 Jun 2020 11:03:15 +0000 Message-ID: References: <159172658835.26172.4590101163395195141@ietfa.amsl.com> <00c301d63eb3$9039bf20$b0ad3d60$@augustcellars.com> In-Reply-To: <00c301d63eb3$9039bf20$b0ad3d60$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.15.79.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 62ff3be2-68bc-4d58-5686-08d80d2de060 x-ms-traffictypediagnostic: MN2PR11MB3549: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0430FA5CB7 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fn0uZIkYQYSIR0+XpHOseLs5k58KBVEIru9uJP+2r093cSJJ5BQNfuFd/Z9msatGVCblzcSKyvrdj2J783m4gsUDficbVjo/4qhd3c8YKqzjCVYc+Hb5aD76ismHaHYfGSkW2+ofeVUhml1Nw1xD01uy9WabvBRqPmm6fW9bD01zpDBrlNkoF7PUWYkdkT4exCXtoa/GOJCDwuFSuV/a3YZZHAwJyhcshqFnEoHphMWsG+hgX7UutlffGquyhnNOK5qzgBUs+0WmQRGaiR7xox8X5iHsTZVw5oj0r2VkNjUCvlqPSCdr4qsQdfkfwylH2BPgBt1Tcnd00ugrfpGfOOgxZgthEI6SvjmkzHKYXndwcNNPRAE/Q1s6AHNb9MSLcY+hBLbo6TmasSYHxtKi8w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(39860400002)(346002)(396003)(136003)(66556008)(110136005)(26005)(33656002)(478600001)(66476007)(64756008)(71200400001)(7696005)(966005)(66446008)(186003)(53546011)(66946007)(86362001)(76116006)(6506007)(2906002)(9686003)(54906003)(83380400001)(52536014)(8676002)(55016002)(4326008)(5660300002)(316002)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: TkEONRtCXGk5KqDrYzdla3RkVvaBE+uMIf24CEEXFQS4nOwd8+5dr1OM9VvDKSvSbliMXLF4LcE1cmHTiHHj5Cbhk1GCydd9js60HrjcZy88igo8gtVzl3VS8P+95TgJJSvLHgcFP6bfd3nsl7bszaf7RT1tP4GVP3uMun0LN1wgTOL0SxY/gk/3HyRAwOyd110MAGGWUvy6CWNtxu4DxGDh4B5tdL5PEPJBe5DCNEo988Av24RqO1sDrsbSnbNSNs/bzWllNedT55Am5BDcjtOFvZqW6e6AssjRO49Qe2/sY5LZNuwkkPkMR6rWouuxUb3G51xW3FDMMWRHIBfEW3HAYe76dZRsISNPn1E+FqTDpNP6YVJTXP7xrzVW9Xui16PZ5vCD/8tWQz5spdzzdF5AR9WV0GErIzeaSeXfjO0vvyZLPxUTieAGqAioPRSVIFqmUXbbYtPKwDDafZcBwNj5+atQHApjobEgWjLeLzc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 62ff3be2-68bc-4d58-5686-08d80d2de060 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2020 11:03:15.5108 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bBzFAKavcswDDCo8bENVjC6Ou9zWbTYqy9UXbPcjl1IM1z3aEJ+TB7puOuKfNQ6xrPjq3E8UPioPNlrvFxSDjw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3549 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [COSE] Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 11:03:29 -0000 SGkgSmltLA0KDQpQbGVhc2Ugc2VlIGlubGluZSAuLi4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPg0KPiBT ZW50OiAxMCBKdW5lIDIwMjAgMDA6MTMNCj4gVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2ls dG9uQGNpc2NvLmNvbT47ICdUaGUgSUVTRycgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1p ZXRmLWNvc2UtcmZjODE1MmJpcy1hbGdzQGlldGYub3JnOyBjb3NlLWNoYWlyc0BpZXRmLm9yZzsN Cj4gY29zZUBpZXRmLm9yZzsgJ01hdHRoZXcgTWlsbGVyJyA8bGludXh3b2xmK2lldGZAb3V0ZXIt cGxhbmVzLm5ldD4NCj4gU3ViamVjdDogUkU6IFJvYmVydCBXaWx0b24ncyBObyBPYmplY3Rpb24g b24gZHJhZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtDQo+IGFsZ3MtMDk6ICh3aXRoIENPTU1FTlQp DQo+IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJvYmVy dCBXaWx0b24gdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPg0KPiBTZW50OiBUdWVz ZGF5LCBKdW5lIDksIDIwMjAgMTE6MTYgQU0NCj4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3Jn Pg0KPiBDYzogZHJhZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtYWxnc0BpZXRmLm9yZzsgY29zZS1j aGFpcnNAaWV0Zi5vcmc7DQo+IGNvc2VAaWV0Zi5vcmc7IE1hdHRoZXcgTWlsbGVyIDxsaW51eHdv bGYraWV0ZkBvdXRlci1wbGFuZXMubmV0PjsNCj4gbGludXh3b2xmK2lldGZAb3V0ZXItcGxhbmVz Lm5ldA0KPiBTdWJqZWN0OiBSb2JlcnQgV2lsdG9uJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWll dGYtY29zZS1yZmM4MTUyYmlzLWFsZ3MtDQo+IDA5OiAod2l0aCBDT01NRU5UKQ0KPiANCj4gUm9i ZXJ0IFdpbHRvbiBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3IN Cj4gZHJhZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtYWxncy0wOTogTm8gT2JqZWN0aW9uDQo+IA0K PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFu ZCByZXBseSB0byBhbGwNCj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg Q0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFw aCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYu b3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZv cm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4g DQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1jb3NlLXJmYzgxNTJiaXMtYWxncy8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBIaSwNCj4gDQo+IEkndmUgb25seSBy ZXZpZXdlZCB0aGUgZGlmZiBhZ2FpbnN0IFJGQzgxNTIuICAgVGhlIHZhc3QgbWFqb3JpdHkgb2Yg dGhpcw0KPiBkb2N1bWVudCBzZWVtZWQgdG8gaGF2ZSBvbmx5IG1pbmltYWwgY2hhbmdlcyBhbmQg bG9va2VkIGZpbmUgZnJvbSB3aGF0IEkNCj4gY291bGQgc2VlLg0KPiANCj4gQSBmZXcgbWlub3Ig Y29tbWVudHMgdGhhdCBtYXkgaGVscCBpbXByb3ZlIHRoZSBkb2N1bWVudDoNCj4gDQo+IEFic3Ry YWN0DQo+IA0KPiAgICBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENCT1Ip IGlzIGEgZGF0YSBmb3JtYXQgZGVzaWduZWQNCj4gICAgZm9yIHNtYWxsIGNvZGUgc2l6ZSBhbmQg c21hbGwgbWVzc2FnZSBzaXplLiAgVGhlcmUgaXMgYSBuZWVkIGZvciB0aGUNCj4gICAgYWJpbGl0 eSB0byBoYXZlIGJhc2ljIHNlY3VyaXR5IHNlcnZpY2VzIGRlZmluZWQgZm9yIHRoaXMgZGF0YSBm b3JtYXQuDQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgQ0JPUiBPYmplY3QgU2lnbmlu ZyBhbmQgRW5jcnlwdGlvbiAoQ09TRSkNCj4gICAgcHJvdG9jb2wuICBUaGlzIHNwZWNpZmljYXRp b24gZGVzY3JpYmVzIGhvdyB0byBjcmVhdGUgYW5kIHByb2Nlc3MNCj4gICAgc2lnbmF0dXJlcywg bWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlcywgYW5kIGVuY3J5cHRpb24gdXNpbmcgQ0JPUg0K PiAgICBmb3Igc2VyaWFsaXphdGlvbi4gIENPU0UgYWRkaXRpb25hbGx5IGRlc2NyaWJlcyBob3cg dG8gcmVwcmVzZW50DQo+ICAgIGNyeXB0b2dyYXBoaWMga2V5cyB1c2luZyBDQk9SLg0KPiANCj4g ICAgSW4gdGhpcyBzcGVjaWZpY2F0aW9uIHRoZSBjb252ZW50aW9ucyBmb3IgdGhlIHVzZSBvZiBh IG51bWJlciBvZg0KPiAgICBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMgd2l0aCBDT1NFLg0KPiAN Cj4gRmlyc3Qgc2VudGVuY2Ugb2YgdGhlIHNlY29uZCBwYXJhZ3JhcGggZG9lc24ndCBxdWl0ZSBz Y2FuLCBhbmQgSSB3YXNuJ3QNCj4gY29udmluY2VkIHRoYXQgdGhlIGZpcnN0IHBhcmFncmFwaCBp cyBuZWNlc3NhcmlseSBjb3JyZWN0L2FjY3VyYXRlIGFmdGVyDQo+IHRoZSBkb2N1bWVudCBzcGxp dCAoaW4gcGFydGljdWxhciB0aGUgIlRoaXMgZG9jdW1lbnQiIGFuZCAiVGhpcw0KPiBzcGVjaWZp Y2F0aW9uIg0KPiBiaXRzKS4NCj4gW0pMU10gRml4ZWQgaW4gcmVwbHkgdG8gUm9tYW4ncyBjb21t ZW50Lg0KPiANCj4gU2VjdGlvbiA3LjINCj4gDQo+ICAgIHg6ICAgVGhpcyBjb250YWlucyB0aGUg cHVibGljIGtleS4gIFRoZSBieXRlIHN0cmluZyBjb250YWlucyB0aGUNCj4gICAgICAgICBwdWJs aWMga2V5IGFzIGRlZmluZWQgYnkgdGhlIGFsZ29yaXRobS4gIChGb3IgWDI1NTkxLCBpbnRlcm5h bGx5DQo+ICAgICAgICAgaXQgaXMgYSBsaXR0bGUtZW5kaWFuIGludGVnZXIuKQ0KPiANCj4gICAg ZDogICBUaGlzIGNvbnRhaW5zIHRoZSBwcml2YXRlIGtleS4NCj4gDQo+IE9uZSBtaW5vciB0aGlu ZyB0aGF0IEkgbm90ZWQsIGlzIHRoYXQgeW91IGRlZmluZSB0aGF0IHRoZSBwdWJsaWMga2V5IGlz DQo+IGRlZmluZWQgYnkgdGhlIGFsZ29yaXRobSwgYnV0IGRvbid0IHNheSB0aGUgc2FtZSB0aGlu ZyBmb3IgdGhlIHByaXZhdGUNCj4ga2V5LiAgSWYgeW91IGNoYW5nZSB0aGlzLCB0aGVuIHlvdSBt aWdodCB3YW50IHRvIGNoZWNrIG90aGVyIHJlZmVyZW5jZXMgdG8NCj4gInByaXZhdGUga2V5IiBh cyB3ZWxsLg0KPiBbSkxTXSBVbmRlciBub3JtYWwgY2lyY3Vtc3RhbmNlcyBJIHdvdWxkIGhhdmUg b21pdHRlZCB0aGUgZGVmaW5pdGlvbiBvZg0KPiB0aGUgcHVibGljIGtleSBmcm9tIHRoYXQgdGV4 dC4gIFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlcmUgaGFzIGJlZW4gYSBsb3QNCj4gb2YgaXNzdWVz IHdpdGggdGhpcyBiZWNhdXNlIGl0IGlzIHRoZSByZXZlcnNlIG9mIHdoYXQgaXMgbm9ybWFsbHkg ZG9uZS4NCj4gQWxtb3N0IGFsbCBpbnRlZ2VycyBhcmUgbm9ybWFsbHkgYmlnLWVuZGlhbiBpbiBj cnlwdG9ncmFwaCwgYW5kIHRodXMgSSBhbQ0KPiBoaWdobGlnaHRpbmcgYSBzaW5nbGUgY2FzZSB3 aGVyZSBpdCBpcyBub3QuICBJIHdpbGwgYWxzbyBwb2ludCB0byB0aGUNCj4gZXhpc3RlbmNlIG9m IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWx3aWctY3VydmUtDQo+IHJl cHJlc2VudGF0aW9ucy0wOSB3aGljaCB1c2VzIHRoZSBzYW1lIGN1cnZlIHVuZGVyIGEgZGlmZmVy ZW50DQo+IHJlcHJlc2VudGF0aW9uIGFuZCBkb25lIHRoZSBiaWctZW5kaWFuIGVuY29kaW5nLg0K PiANCj4gOC4gIENPU0UgQ2FwYWJpbGl0aWVzDQo+IA0KPiAgICBUaGUgY29uY2VwdCBpcyBiZWlu ZyBwdWxsZWQgZm9yd2FyZCBhbmQgZGVmaW5lZCBub3cgZm9yDQo+ICAgIENPU0UuDQo+IA0KPiBQ ZXJoYXBzIHJlcGhyYXNlIHRoaXMgdG86ICJUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIHNhbWUg Y29uY2VwdCBmb3INCj4gQ09TRS4iDQo+IFtKTFNdIFRoYXQgaXMgYmV0dGVyIHRoYW4gdGhlIHdv cmRpbmcgZnJvbSBSb21hbiAtIHVwZGF0ZWQgdG8gdXNlIHRoaXMuDQo+IA0KPiA4LiAgQ09TRSBD YXBhYmlsaXRpZXMNCj4gDQo+ICAgIFRoZSBhbGdvcml0aG0gaWRlbnRpZmllciBpcyBub3QgcGFy dCBvZiB0aGUgY2FwYWJpbGl0aWVzIGRhdGEgYXMgaXQNCj4gICAgc2hvdWxkIGFscmVhZHkgYmUg cGFydCBvZiBtZXNzYWdlIHN0cnVjdHVyZS4gIFRoZXJlIGlzIGEgcHJlc3VtcHRpb24NCj4gICAg aW4gdGhlIHdheSB0aGF0IHRoaXMgaXMgbGFpZCBvdXQgaXMgdGhhdCB0aGUgYWxnb3JpdGhtIGlk ZW50aWZpZXINCj4gICAgaXRzZWxmIGlzIG5vdCBuZWVkZWQgdG8gYmUgYSBwYXJ0IG9mIHRoaXMg YXMgaXQgaXMgc3BlY2lmaWVkIGluIGENCj4gICAgZGlmZmVyZW50IGxvY2F0aW9uLg0KPiANCj4g SSBmb3VuZCB0aGUgc2Vjb25kIHNlbnRlbmNlIHNvbWV3aGF0IHVuY2xlYXIgYW5kIGNvdWxkIHBy b2JhYmx5IGJlDQo+IHdvcmRzbWl0aGVkLCBpbiBwYXJ0aWN1bGFyIGRvZXMgInRoaXMiIHJlZmVy IHRvIHRoZSBjYXBhYmlsaXRpZXMgZGF0YSBvcg0KPiB0aGUgbWVzc2FnZSBzdHJ1Y3R1cmUuDQo+ IFtKTFNdIFRoaXMgaGFzIGFscmVhZHkgYmVlbiBjaGFuZ2VkIGluIHJlc3BvbnNlIHRvIFJvbWFu Lg0KPiANCj4gOC4gIENPU0UgQ2FwYWJpbGl0aWVzDQo+IA0KPiAgICBUd28gZGlmZmVyZW50IHR5 cGVzIG9mIGNhcGFiaWxpdGllcyBhcmUgZGVmaW5lZDogY2FwYWJpbGl0aWVzIGZvcg0KPiAgICBh bGdvcml0aG1zIGFuZCBjYXBhYmlsaXRpZXMgZm9yIGtleSBzdHJ1Y3R1cmVzLiAgT25jZSBkZWZp bmVkIGJ5DQo+ICAgIHJlZ2lzdHJhdGlvbiB3aXRoIElBTkEsIHRoZSBsaXN0IG9mIGNhcGFiaWxp dGllcyBpcyBpbW11dGFibGUuICBJZiBpdA0KPiAgICBpcyBsYXRlciBmb3VuZCB0aGF0IGEgbmV3 IGNhcGFiaWxpdHkgaXMgbmVlZGVkIGZvciBhIGtleSB0eXBlIG9yIGFuDQo+ICAgIGFsZ29yaXRo bSwgaXQgd2lsbCByZXF1aXJlIHRoYXQgYSBuZXcgY29kZSBwb2ludCBiZSBhc3NpZ25lZCB0byBk ZWFsDQo+ICAgIHdpdGggdGhhdC4gIEFzIGEgZ2VuZXJhbCBydWxlLCB0aGUgY2FwYWJpbGl0aWVz IGFyZSBnb2luZyB0byBtYXAgdG8NCj4gICAgYWxnb3JpdGhtLXNwZWNpZmljIGhlYWRlciBwYXJh bWV0ZXJzIG9yIGtleSBwYXJhbWV0ZXJzLCBidXQgdGhleSBkbw0KPiAgICBub3QgbmVlZCB0byBk byBzby4gIEFuIGV4YW1wbGUgb2YgdGhpcyBpcyB0aGUgSFNTLUxNUyBrZXkNCj4gICAgY2FwYWJp bGl0aWVzIGRlZmluZWQgYmVsb3cgd2hlcmUgdGhlIGhhc2ggYWxnb3JpdGhtIHVzZWQgaXMgaW5j bHVkZWQuDQo+IA0KPiBEZWZpbmluZyB0aGUgY2FwYWJpbGl0aWVzIGxpc3QgYXMgaW1tdXRhYmxl IHNlZW1lZCBsaWtlIGEgbWlzbm9tZXIgdG8gbWUNCj4gYmVjYXVzZSBhIG5ldyBJQU5BIHJlZ2lz dHJhdGlvbiB3b3VsZCBtdXRhdGUgdGhlIGxpc3QuICBQZXJoYXBzIHRoaXMNCj4gc2VudGVuY2Us IGFuZCB0aGUgb25lIGZvbGxvd2luZyBpdCwgY291bGQgYmUgcmVtb3ZlZD8NCj4gW0pMU10gVGhl IHdob2xlIG9iamVjdCBpcyB0aGF0IG9uY2UgcmVnaXN0ZXJlZCB3aXRoIElBTkEsIGl0IHdpbGwg bmV2ZXIgYmUNCj4gY2hhbmdlZCBldmVuIGJ5IElBTkEuICBUaHVzIEkgYmVsaWV2ZSB0aGF0IHRo ZSB3b3JkIGltbXV0YWJsZSBzZWVtcyB0byBiZQ0KPiBjb3JyZWN0LiAgSWYgdGhpcyBpcyBjaGFu Z2VkIHRoZW4gZXhpc3Rpbmcgc2lnbmF0dXJlcyB3aWxsIGZhaWwgYW5kIGtleQ0KPiBkZXJpdmF0 aW9uIGZ1bmN0aW9ucyB3aWxsIGdlbmVyYXRlIGRpZmZlcmVudCByZXN1bHRzLg0KW1JXXQ0KDQpJ J20gc3RpbGwgc2xpZ2h0bHkgY29uZnVzZWQsIGFuZCBhbGFzIHRoZSBtb3JlIEkgcmVhZCB0aGUg dGV4dCB0aGUgbW9yZSBjb25mdXNlZCBJIGJlY29tZSA7LSkNCg0KSGVuY2UgYSBjbGFyaWZ5aW5n IHF1ZXN0aW9uOiBEb2VzICJ0aGUgbGlzdCBvZiBjYXBhYmlsaXRpZXMgaXMgaW1tdXRhYmxlIiwg ZG9lcyBpdCBtZWFuIHRoYXQgdGhlIGxpc3Qgb2YgY2FwYWJpbGl0aWVzIGFzc29jaWF0ZWQgd2l0 aCBhIGdpdmVuIGFsZ29yaXRobSBvciBrZXkgc3RydWN0dXJlIGlzIGltbXV0YWJsZT8gIE9yIGRv ZXMgaXQgbWVhbiB0aGF0IHRoZSBlbnRpcmUgbGlzdCBvZiBkZWZpbmVkIGNhcGFiaWxpdGllcyBh cyBhIHNldCBpcyBpbW11dGFibGU/DQoNCkFuZCBpbiB0aGUgZm9sbG93aW5nIHBhcmFncmFwaCwg d2hlcmUgaXMgc3RhdGVzICJUaGUgY2FwYWJpbGl0eSBzdHJ1Y3R1cmUgaXMgYW4gYXJyYXkgb2Yg dmFsdWVzIiBkb2VzIGl0IG1lYW4gdGhlIGNhcGFiaWxpdHkgc3RydWN0dXJlIGFzc29jaWF0ZWQg d2l0aCBhIHBhcnRpY3VsYXIgYWxnb3JpdGhtIG9yIGtleT8NCg0KQW5vdGhlciBxdWVzdGlvbiBy ZWxhdGVzIHRvICJUaGUgY2FwYWJpbGl0eSBzdHJ1Y3R1cmUgaXMgYW4gYXJyYXkgb2YgdmFsdWVz LCIsIGRvZXMgdGhpcyBtZWFuICJUaGUgY2FwYWJpbGl0eSBzdHJ1Y3R1cmUgZm9yIGEgZ2l2ZW4g YWxnb3JpdGhtIG9yIGtleSBpcyBhbiBvcmRlcmVkIGFycmF5IG9mIHZhbHVlcywgdGhlIG9yZGVy IC4uLiAiDQoNClRoZSBwYXJhZ3JhcGggYmVsb3cgYWxzbyBtZW50aW9ucyBtdWx0aXBsZSBwYWly cyBvZiBjYXBhYmlsaXR5IHN0cnVjdHVyZXMuICBEbyB0aGUgY2FwYWJpbGl0aWVzIGFsd2F5cyBj b21lIGFzIGEgcGFpciBvZiBhbiBhbGdvcml0aG0gYW5kIGEga2V5PyAgSWYgdGhlcmUgYXJlIG11 bHRpcGxlIHBhaXJzIHRoZW4gaG93IGFyZSB0aGV5IGVuY29kZWQsIHByZXN1bWFibHkgYXMgYW4g YXJyYXkgb2YgcGFpcnM/ICBJZiBjYXBhYmlsaXRpZXMgZG8gbm90IGFsd2F5cyBjb21lIGFzIGEg cGFpciB0aGVuIHlvdSBkbyB5b3UgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGEgY2FwYWJpbGl0eSBk ZWZpbmluZyBhbiBhbGdvcml0aG0gYW5kIG9uZSBkZWZpbmluZyBhIGtleT8NCg0KPiANCj4gICAg VGhlIGNhcGFiaWxpdHkgc3RydWN0dXJlIGlzIGFuIGFycmF5IG9mIHZhbHVlcywgdGhlIG9yZGVy IGJlaW5nDQo+ICAgIGRlcGVuZGVudCBvbiB0aGUgc3BlY2lmaWMgYWxnb3JpdGhtIG9yIGtleS4g IEZvciBhbiBhbGdvcml0aG0sIHRoZQ0KPiAgICBmaXJzdCBlbGVtZW50IHNob3VsZCBhbHdheXMg YmUgYSBrZXkgdHlwZSB2YWx1ZSwgYnV0IHRoZSBpdGVtcyB0aGF0DQo+ICAgIGFyZSBzcGVjaWZp YyB0byBhIGtleSBzaG91bGQgbm90IGJlIGluY2x1ZGVkIGluIHRoZSBhbGdvcml0aG0NCj4gICAg Y2FwYWJpbGl0aWVzLiAgVGhpcyBtZWFucyB0aGF0IGlmIG9uZSB3aXNoZXMgdG8gZW51bWVyYXRl IGFsbCBvZiB0aGUNCj4gICAgY2FwYWJpbGl0aWVzIGZvciBhIGRldmljZSB3aGljaCBpbXBsZW1l bnRzIEVDREgsIGl0IHJlcXVpcmVzIG11bHRpcGxlDQo+ICAgIHBhaXJzIG9mIGNhcGFiaWxpdHkg c3RydWN0dXJlcyAoYWxnb3JpdGhtLCBrZXkpIHRvIGRlYWwgd2l0aCB0aGUNCj4gICAgZGlmZmVy ZW50IGtleSB0eXBlcyBhbmQgY3VydmVzIHRoYXQgYXJlIHN1cHBvcnRlZC4gIEZvciBhIGtleSwg dGhlDQo+ICAgIGZpcnN0IGVsZW1lbnQgc2hvdWxkIGFsc28gYmUgYSBrZXkgdHlwZSB2YWx1ZS4g IFdoaWxlIHRoaXMgbWVhbnMgdGhhdA0KPiAgICB0aGlzIHZhbHVlIHdpbGwgYmUgZHVwbGljYXRl ZCBpZiBib3RoIGFuIGFsZ29yaXRobSBhbmQga2V5IGNhcGFiaWxpdHkNCj4gICAgYXJlIHVzZWQs IHRoZSBrZXkgdHlwZSBpcyBuZWVkZWQgaW4gb3JkZXIgdG8gdW5kZXJzdGFuZCB0aGUgcmVzdCBv Zg0KPiAgICB0aGUgdmFsdWVzLg0KPiANCj4gU2hvdWxkIHlvdSBiZSB1c2luZyBSRkMgMjExOSBs YW5ndWFnZSBoZXJlPyAgQW5kIHNob3VsZCAiIGtleSBzaG91bGQgbm90DQo+IGJlIGluY2x1ZGVk IiBiZSAiTVVTVCBOT1QiPw0KPiBbSkxTXSBSZXNwb25kZWQgdG8gdGhpcyBwb2ludCBpbiBSb21h bidzIGNvbW1lbnRzLg0KPiANCj4gRm9yIHRoZSBFQ0RIIGNhc2UsIGRvZXMgdGhhdCBtZWFuIHRo YXQgdGhlICJhbGdvcml0aG0iIGVudHJ5IHdpbGwgYmUNCj4gZHVwbGljYXRlZCB3aXRoIGRpZmZl cmVudCAia2V5IiBlbnRyaWVzPyAgSWYgc28sIHdvdWxkIGl0IGhlbHAgY2xhcmlmeSB0bw0KPiBl eHBsaWNpdGx5IHN0YXRlIHRoaXM/DQo+IFtKTFNdIFdvdWxkIHBvaW50aW5nIHRvIHRoZSBzZWNv bmQgYW5kIHRoaXJkIGV4YW1wbGVzIGluIHNlY3Rpb24gOC4zIGFsb25nDQo+IHdpdGggc29tZSBl eHBsYW5hdG9yeSB0ZXh0Pw0KW1JXXSANCg0KUGVyaGFwcywgYnV0IEkgdGhpbmsgdGhhdCBpdCB3 b3VsZCBhbHNvIGJlIHVzZWZ1bCB0byBoYXZlIGFuIGV4YW1wbGUgb2Ygc3VwcG9ydGluZyBFQ0RI LUVTIHdpdGggYm90aCBQLTI1NiBhbmQgWDI1NTE5IGN1cnZlcywgYW5kIGhvdyB0aGF0IHdvdWxk IGJlIGVuY29kZWQgKGlmIHRoYXQgbWFrZXMgc2Vuc2UpLg0KDQpJIGFsc28gY291bGRuJ3QgY29u dmluY2UgbXlzZWxmIHRoYXQgdGhlIG51bWVyaWNhbCB2YWx1ZXMgdGhhdCBhcmUgdXNlZCBpbiB0 aGUgZXhhbXBsZXMgYXJlIG5lY2Vzc2FyeSByaWdodCwgcGxlYXNlIGNhbiB5b3UgY2hlY2sgdGhh dCB0aGV5IGFyZS4gIEUuZy4sIHRoZSBmaXJzdCB0d28gZXhhbXBsZSBoYXZlIHRoZSBzYW1lIG51 bWVyaWMgZW5jb2RpbmcsIGFuZCB0aGUgdHdvIEVDREgtRVMgaGF2ZSBkaWZmZXJlbnQgZW5jb2Rp bmdzIG9mIHRoZSBhbGdvcml0aG0uICBCdXQgcGVyaGFwcyB0aGF0IGlzIGp1c3QgbXkgY29uZnVz aW9uIGFib3V0IGhvdyB0aGlzIHdvcmtzLg0KDQpSZWdhcmRzLA0KUm9iDQoNCg0KPiANCj4gSmlt DQo+IA0KPiBUaGFua3MsDQo+IFJvYg0KPiANCj4gDQoNCg== From nobody Wed Jun 10 07:43:17 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7445E3A08FA; Wed, 10 Jun 2020 07:43:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller , linuxwolf+ietf@outer-planes.net X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <159180019141.10859.11523670566269148728@ietfa.amsl.com> Date: Wed, 10 Jun 2020 07:43:11 -0700 Archived-At: Subject: [COSE] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-cose-rfc8152bis-algs-09=3A_=28with_COMMENT=29?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 14:43:12 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-cose-rfc8152bis-algs-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work on this document. To be honest, I had only time to quickly browse through: I am trusting the security AD for the security considerations. Not really important but I wonder why the security considerations are spread through all the document (sections 3.1.1, 3.2.1, ...). It obviously makes the text clearer and easier to read but may I suggest to rename those sections in something more specific (to avoid the comparaison with the well-know security considerations section of all I-D -- that is Section 11 in this document) : e.g., "Section 4.2.1 Security Considerations of AES CCM". I noted that this is used in "6.2.1. Security Considerations for AES-KW" already, just be consistent ;-) Hope this helps -éric From nobody Wed Jun 10 11:05:33 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D423A0872; Wed, 10 Jun 2020 11:05:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller , linuxwolf+ietf@outer-planes.net X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <159181232597.18622.11559246666786395335@ietfa.amsl.com> Date: Wed, 10 Jun 2020 11:05:25 -0700 Archived-At: Subject: [COSE] Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 18:05:26 -0000 Robert Wilton has entered the following ballot position for draft-ietf-cose-rfc8152bis-struct-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I've only reviewed the diffs, not the historical approved text. Everything looks okay to me. A few minor comments/nits: Comment: 1.4. CBOR Grammar The CDDL grammar is informational; the prose description is normative. I'm not familiar with the CDDL grammar, and specifically whether there is any tooling that can use the grammar to generate structures/etc. If there is, then I think that it would be helpful if the CDDL grammar was also normative, in the sense that readers of the spec should be able to assume that the CDDL is correct. I would still be okay with a statement that says that if there is any ambiguity between the two then the prose description should be taken as being definitive. Nits: 1.5. CBOR-Related Terminology The presence in a CBOR map of a label that is not a text string or an integer is an error. This sentence was changed from the original formulation, but I find it slightly clunky. Perhaps: The presence of a label, that is neither a text string nor an integer, in a CBOR map, is an error. 9. Taxonomy of Algorithms used by COSE In this section, a taxonomy of the different algorithm types that can be used in COSE is laid out. This taxonomy should not be considered to be exhaustive. New algorithms will be created which will not fit into this taxonomy. If this occurs, then new documents addressing this new algorithms are going to be needed. Nit, this -> these Regards, Rob From nobody Wed Jun 10 18:44:12 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0FD3A1624; Wed, 10 Jun 2020 18:44:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller , linuxwolf+ietf@outer-planes.net X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159183984940.7642.3215375794743353401@ietfa.amsl.com> Date: Wed, 10 Jun 2020 18:44:09 -0700 Archived-At: Subject: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 01:44:10 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-cose-rfc8152bis-struct-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (Arguably a "discuss discuss".) If we don't have any worked examples of signatures with message recovery, should we include that possibility in the Internet Standard version of the protocol? Some of the description around how the details of this would work remain unclear to me. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (I support Roman's Discuss.) It's a little weird that we're Obsoletes:ing 8152 yet expect the expert review procedures from it to remain in force. Perhaps we should copy the expert review instructions to this document so that IANA is not relying on an obsolete document? Do we need to check usage of "counter signature" with and without space? I'd also like to discuss the question raised by Martin D. (on -algs) relating to "AE" and "AEAD". Section 9.3 is quite clear that we restrict content-encryption algorithms to those that support AAD, i.e., AEAD mechanisms, so we only seem to use AE for the Key Wrap operations. Perhaps we should add a clarifying note in the terminology section about what AE and AEAD are used for. Section 1 Shouldn't we refer to RFC 8259 by its STD number (90)? structures. CBOR was designed specifically both to be small in terms of messages transported and implementation size and be a schema-free decoder. A need exists to provide message security services for IoT, nit: I think the second "be" should be "to be" as well. * The description of the structure for the CBOR objects which are transmitted over the wire. Two objects are defined for encryption, signing and message authentication. One object is That's two objects *each*, right? * A starting set of attributes that apply to the different security objects. nit: the "starting set" wording feels a little out of place given that the registry already exists and has stuff that we're not covering. providing security services. The use of COSE, like JOSE and CMS, is only in store and forward or offline protocols, different solutions would be appropriate for online protocols although one can use COSE in an online protocol after having done some type of online key establishment process. Any application which uses COSE for security nit: comma splice (and the sentence after the comma is a bit long, too). additional data fields as part of the structure. A common structure is going to include a URI or other pointer to where the data that is being hashed is kept, allowing this to be application-specific. This is "common" in the sense of "a design pattern expected to be frequently used", not "a common baseline", right? Section 1.3 * Define a single top message structure so that encrypted, signed, nit: "top-level"? * Signed messages distinguish between the protected and unprotected header parameters that relate to the content from those that relate to the signature. nit(?): shouldn't this be "distinguish between [x] and [y]", not "between [x] from [y]"? Section 1.6 Authenticated Encryption (AE) [RFC5116] algorithms are those encryption algorithms that provide an authentication check of the contents algorithm with the encryption service. nit: this last "algorithm" seems spurious? context can come from several different sources including: Protocol interactions, associated key structures and program configuration. nit: serial comma, please. The context to use can be implicit, identified using the 'kid context' header parameter defined in [RFC8613], or identified by a Wouldn't the "kid context" be an *explicit* context, not implicit? protocol-specific identifier. Context should generally be included in the cryptographic configuration; for more details see Section 4.3. nit: "configuration" is not the first word I would have picked here (and is not used in Section 4.3). Maybe "construction"? Section 2 1. The protected header parameters encoded and wrapped in a bstr. nit: I think this flows better with a comma after "parameters". 3. The content of the message. The content is either the plaintext or the ciphertext as appropriate. The content may be detached (i.e. transported separately from the COSE structure), but the location is still used. The content is wrapped in a bstr when This is "location" in the sense of "the third element of the array", or "the location in the array is still used"? layer. In the content layer, the plaintext is encrypted and information about the encrypted message is placed. In the recipient layer, the content encryption key (CEK) is encrypted and information about how it is encrypted for each recipient is placed. A single nit: ending the sentence with "is placed" feels rather Yoda-esque. 4. When a COSE object is carried as a CoAP payload, the CoAP Content-Format Option can be used to identify the message content. The CoAP Content-Format values can be found in Table 2. The CBOR tag for the message structure is not required as each security message is uniquely identified. Is it an error to include the tag? The following CDDL fragment identifies all of the top messages [hmm, maybe my earlier comment about "top-level message" was misguided] Section 3 or evaluation hints for the processing of the layer. These two buckets are available for use in all of the structures except for keys. While these buckets are present, they may not all be usable in all instances. For example, while the protected bucket is defined as nit: isn't "all buckets" just "both buckets"? h'a0'). The zero-length binary encoding is preferred because it is both shorter and the version used in the serialization structures for cryptographic computation. After encoding the map, nit: this doesn't look like a complete sentence. structures for cryptographic computation. After encoding the map, the value is wrapped in the binary object. Recipients MUST accept This seems a bit redundant with earlier text (and shouldn't it be a "byte string" anyway?). both a zero-length byte string and a zero-length map encoded in the binary value. ["binary value" vs. "binary string" vs. "byte string" again] decoded byte string.) This avoids the problem of all parties needing to be able to do a common canonical encoding. perhaps, "common canonical encoding for input to cryptographic operations"? reference to any other layer. With the exception of the COSE_Sign structure, the only data that needs to cross layers is the (I assume this includes COSE_Sign0 and the tagged versions, too?) Parameters" registry (Section 12.2). Some common header parameters are defined in the next section. [similar comment as above about "common"; maybe "The basic protocol header parameters"?] malformed. Applications SHOULD verify that the same label does not occur in both the protected and unprotected header parameters. If the message is not rejected as malformed, attributes MUST be obtained from the protected bucket before they are obtained from the unprotected bucket. I a little bit worry that "take from protected before unprotected", combined with "don't check for duplicates", means "last match wins" and the unprotected one gets used. Perhaps it's better to talk about taking precedence if both are present? Section 3.1 alg: This header parameter is used to indicate the algorithm used for the security processing. This header parameter MUST be authenticated where the ability to do so exists. This support is provided by AEAD algorithms or construction (COSE_Sign, COSE_Sign1, COSE_Mac, and COSE_Mac0). This authentication can be Can countersignatures authenticate 'alg'? Is there an easy listing of the class of message that does *not* allow for authenticating 'alg'? COSE_Sign1, COSE_Mac, and COSE_Mac0). This authentication can be done either by placing the header parameter in the protected header parameter bucket or as part of the externally supplied data. The value is taken from the "COSE Algorithms" registry (see I don't think we've introduced "externally supplied data" yet, so a forward reference might be in order. * Integer labels in the range of 0 to 7 SHOULD be omitted. side note: I see that RFC 8152 has this as 0 to 8, and 8 is listed as "unassigned" in the registry. Is there a story here? * Integer labels in the range -1 to -128 can be omitted as they are algorithm dependent. If an application can correctly process an algorithm, it can be assumed that it will correctly Where is this sub-partitioning of the -1 to -65536 range specified, that any given algorithm will only assign "critical" header parameters in the -1 to -128 range? If it's just convention I don't think the declarative language ("can be omitted") is appropriate. * Labels for header parameters required for an application MAY be omitted. Applications should have a statement if the label can be omitted. nit: applications or application protocols? The message IV is generated by the following steps: 1. Left-pad the Partial IV with zeros to the length of IV. 2. XOR the padded Partial IV with the context IV. nit: this procedure does not indicate how "the length of IV" is known (i.e., that it's a constant determined by the algorithm). Section 4.1 authenticated by the signature, or just present. An example of header a parameter about the content is the content type header nit: s/header a/a header/ A COSE Signed Message is defined in two parts. The CBOR object that carries the body and information about the body is called the COSE_Sign structure. The CBOR object that carries the signature and (COSE_Sign also carries the signature parts?) Note: When a signature with a message recovery algorithm is used (Section 9.1), the maximum number of bytes that can be recovered is the length of the payload. The size of the payload is reduced by the number of bytes that will be recovered. If all of the nit(?): it's the "size of the payload" *in the encoded COSE_Sign* object that is reduced, right? Section 4.3 proxy's cache. But the sender can cause a failure at the server if a proxy, or an attacker, changes the set of accept values by including the field in the application-supplied data. nit: "application-supplied data" reads pretty oddly to me, though given what section this is in I guess it is not limited to just being "additional authenticated data". Also, it seems like more a property of the protocol the sender is using than the sole choice of the sender, to include or not include the set of accept values in the externally supplied data. This document describes the process for using a byte array of externally supplied authenticated data; the method of constructing the byte array is a function of the application. Applications that Why is this a "byte array" and not a "byte string"? * If multiple items are included, applications need to ensure that the same byte string cannot be produced if there are different inputs. This would occur by appending the text strings 'AB' and 'CDE' or by appending the text strings 'ABC' and 'DE'. This is (I liked this better as "could occur" of RFC 8152. Also, is concatenating" better than "appending", since we are posing the two strings as peers, not subject and object?) Also, sometimes this property is referred to as being an "injective mapping". Section 4.4 (I also had Roman's comment about the "CounterSignature" attributes in field (1).) 3. The protected attributes from the signer structure encoded in a bstr type. If there are no protected attributes, a zero-length byte string is used. This field is omitted for the COSE_Sign1 signature structure and CounterSignature0 attributes. ("omitted" means "not present in the array at all", right?) 4. The protected attributes from the application encoded in a bstr type. If this field is not supplied, it defaults to a zero- Are these "protected attributes" the "externally supplied data" of Section 4.3? We should probably use the same terminology to talk about them... Section 5 counter signatures use the structure COSE_Countersign. This is same structure as COSE_Signature and thus it can have protected attributes, chained counter signatures and information about identifying the key. Abbreviated counter signatures use the nit: "information about identifying the key" seems redundant. specified. One result of this is that for COSE one can expand the concept of counter signatures beyond just the idea of signing a signature to being able to sign most of the structures without having to create a new signing layer. When creating a counter signature, nit: this seems somewhat redundant with the first paragraph of the section ("this document extends to the concept of a counter signature to allow [...]"). Section 5.1 The COSE_Countersignature structure allows for the same set of capabilities of a COSE_Signature. This means that all of the nit: "same set of capabilities as" archiving services. More information on how this is used can be found in the evidence record syntax described in [RFC4998]. nit: I'm binding "this" to "COSE_Countersignature", which causes this sentence to not make much sense. Perhaps "how this can be used" or "how countersignatures signing countersignatures can be used" or "long-term archiving services"? COSE_CounterSignature_Tagged = #6.98(COSE_CounterSignature) note that 6.98 is incorrect; this is going to be the TBD value. Section 6.1 I think we need some forward-references to 6.3/6.4, here, since (e.g.) 6.2 is referencing back here to fill in the ciphertext. The COSE_recipient structure is a CBOR array. The fields of the array in order are: [...] ciphertext: This field contains the encrypted key encoded as a bstr. All encoded keys are symmetric keys; the binary value of the key is the content. If there is not an encrypted key, then this field is encoded as a nil value. I guess it's impossible to have protected headers with no encrypted key (since you need a ciphertext for protected headers)? COSE_recipient = [ Headers, ciphertext : bstr / nil, ? recipients : [+COSE_recipient] ] side note(?): I'm not sure I really understand when the recursive COSE_recipient structure would be used at higher depths of recursion. passwords: The CEK is encrypted in a KEK that is derived from a password. As of when this document was published, no password algorithms have been defined. If there aren't any, do we need to include it in the taxonomy? Section 6.3 It's slightly amusing that the "Enc_structure" is actually the AAD, not anything encrypted :) Section 6.4 1. Verify that the 'protected' field is empty. 2. Verify that there was no external additional authenticated data supplied for this operation. Presumably we fail the operation if either verification fails? Section 7.3 3. The protected attributes from the application encoded as a bstr type. If this field is not supplied, it defaults to a zero- [as above, using consistent terminology for "externally supplied data" would be useful.] Section 8 A COSE Key structure is built on a CBOR map. The set of common parameters that can appear in a COSE Key can be found in the IANA "COSE Key Common Parameters" registry (Section 12.4). Additional parameters defined for specific key types can be found in the IANA "COSE Key Type Parameters" registry ([COSE.KeyParameters]). It's slightly jarring to have a section reference for one registry but an external reference for the other. Section 8.1 cryptographic operation. Note that the same key can be in a different key structure with a different or no algorithm specified; however, this is considered to be a poor security practice. Depending on the answer to my question on -algs about capabilities and their use, this statement might need to be updated. kid: This parameter is used to give an identifier for a key. The identifier is not structured and can be anything from a user- provided byte string to a value computed on the public portion of the key. This field is intended for matching against a 'kid' parameter in a message in order to filter down the set of keys that need to be checked. I suggest reiterating that it is not in any way a unique identifier. Base IV: This parameter is defined to carry the base portion of an IV. It is designed to be used with the Partial IV header parameter defined in Section 3.1. This field provides the ability to associate a Partial IV with a key that is then modified on a Er, isn't it the Base IV associated with the key and the Partial IV that's per-message? If different keys are derived for each sender, using the same Base IV with Partial IVs starting at zero is likely to ensure that the IV would not be used twice for a single key. If different keys are derived for each sender, starting at the same Base IV is likely to satisfy this condition. If the same key is used for The two sentences that start with "if different keys" seem to have some redundancy that could be eliminated. Section 9 to be exhaustive. New algorithms will be created which will not fit into this taxonomy. If this occurs, then new documents addressing this new algorithms are going to be needed. nit(?): this last sentence is written in a kind of colloquial style. Section 9.1 There are two signature algorithm schemes. The first is signature nit: mybe "two types of" (and "scheme" singular)? Section 9.2 Message Authentication Codes (MACs) provide data authentication and integrity protection. They provide either no or very limited data origination. A MAC, for example, cannot be used to prove the identity of the sender to a third party. Hmm, should the s/can/cannot/ be filed as an erratum against 8152? Section 9.4 General KDFs work well with the first type of secret, can do reasonably well with the second type of secret, and generally do poorly with the last type of secret. Functions like PBES2 [RFC8018] need to be used for non-random secrets. nit: To be analogous to the previous discussion of KDFs, shouldn't we refer to a PBKDF construction, not PBES (which provides an abstract API for password-based encryption that uses PBKDF1 under the covers)? (Also, my understanding is that PBKDF1 is not exactly considered state-of-the-art.) Section 9.5.1 * A header parameter identifying the shared secret SHOULD be present. What type of header parameter might do that? Section 9.5.2 * The 'recipients' field is normally absent, but can be used. Applications MUST deal with a recipient field being present that has an unsupported algorithm, not being able to decrypt that recipient is an acceptable way of dealing with it. Failing to nit: comma splice Section 9.5.3 When using a key transport algorithm, the COSE_Encrypt structure for the recipient is organized as follows: Does key transport use COSE_Encrypt or COSE_Recipient? Section 9.5.4 any dynamic key material. One side effect of this is that perfect forward secrecy (see [RFC4949]) is not achievable. A static key will Do we want to drop the "perfect"? The COSE_Encrypt structure for the recipient is organized as follows: Is COSE_Encrypt or COSE_Recipient used for direct key agreement? Section 9.5.5 The COSE_Encrypt structure for the recipient is organized as follows: Is COSE_Encrypt or COSE_Recipient used for key agreement with key wrap? * A header parameter identifying the recipient's key SHOULD be present. A header parameter identifying the sender's key SHOULD be present. Is there anything to say about what header parameters those might be? Section 10 The document limits the restrictions it imposes on the CBOR Encoder needs to work. nit: missing word or two? -algs seems to say "restrictions it imposes on how the CBOR Encoder needs to work". Section 11 * Applications need to determine the set of security algorithms that are to be used. When selecting the algorithms to be used as the mandatory-to-implement set, consideration should be given to choosing different types of algorithms when two are chosen for a specific purpose. An example of this would be choosing HMAC- Do we want to mention BCP 201 here? Section 12 Do we want to update the reference for the registries themselves (to point to both 8152 and this) in addition to the reference for the registered entries? Section 12.3 The COSE Header Algorithm Parameters Registry is https://www.iana.org/assignments/cose/cose.xhtml#header-algorithm-parameters , right? I don't see any of those being talked about in this document -- they're discussed in the KDF algorithms section in 8152. So shouldn't this registry (and its entries) point to the algorithms doc, not this one? Section 12.6 IANA added the following entries to the "CoAP Content-Formats" registry while processing [RFC8152]. IANA is requested to update the reference value from [RFC8152] to [[This Document]]. [no entries follow] Section 13 There are a number of security considerations that need to be taken into account by implementers of this specification. The security considerations that are specific to an individual algorithm are placed next to the description of the algorithm. While some [this stuff is in -algs, not -struct] There are a large number of algorithms presented in [I-D.ietf-cose-rfc8152bis-algs] that use nonce values. Nonces generally have some type of restriction on their values. Generally a nonce needs to be a unique value either for a key or for some other conditions. In all of these cases, there is no known requirement on the nonce being both unique and unpredictable; under these circumstances, it's reasonable to use a counter for creation of the nonce. In cases where one wants the pattern of the nonce to be nit: this looks like a bad edit from the splitting off of the algorithms: "all of these cases" cannot bind to "specified in this document" anymore, so we need to describe what we mean differently. One area that has been starting to get exposure is doing traffic analysis of encrypted messages based on the length of the message. I think this may have graduated from "starting" to be more of a mainstream thing :) Section 14.1 side note: OpenSSL 1.0 (no minor version information given?)?! That stuff's EOL! Section 14.4 side note: what's curve24459? Section 15.1 [DSS] has only one usage now in -struct, which doesn't seem normative. I'd expect it to only be normative in -algs. Likewise for RFC 8032. It's also interesting to make a normative reference to -algs, which will be an informational RFC when published (given the current intended status). Are we creating it directly onto the downrefs registry? Appendix A side note: it seems like any scheme for conveying information about what algorithm to use other than "implicit by key with each key limited to one algorithm" has some risk of allowing an attacker's input to cause the key holder to perform some operation using that key but with the "wrong" algorithm. I think that if the externally visible results of that operation are indistinguishable from "the input was ignored", that does not give the attacker a channel by which to attack the key, but I'm not 100% sure. Even an application-layer "rejected due to bad input" might be enough of a lever to enable some types of attack. Appendix B All of the currently defined recipient algorithm classes only use two layers of the COSE_Encrypt structure. The first layer is the message COSE_Recipient? Acknowledgments Göran could probably get his proper name, now. From nobody Wed Jun 10 18:45:10 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 681603A1627; Wed, 10 Jun 2020 18:45:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller , linuxwolf+ietf@outer-planes.net X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159183990940.7725.14952700358572148848@ietfa.amsl.com> Date: Wed, 10 Jun 2020 18:45:09 -0700 Archived-At: Subject: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-algs-09: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 01:45:09 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-cose-rfc8152bis-algs-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think we need to check the [MAC] reference; following links (and chasing redirects) seems to only find a 1985 publication that talks about DES, with no mention of AES-CBC-MAC. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It's interesting that both -struct and -algs make the claim in the Abstract that "this specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization". Shouldn't that only be true for one of them? I'd really like to see a reference for the analysis of and validity/safety of the deviations from RFC 5869 HKDF, in Section 5.1. Section 1 Should we refer to RFC 8259 by its STD number (90)? Section 1.3 We don't seem to use the "AE" term (just -struct does). Section 2.1.1 Note: Use of a deterministic signature technique is a good idea even when good random number generation exists. Doing so both reduces the Note the ongoing work in the CFRG on "deterministic signatures with additional randomness" (the name has been changing a bit recently), and fault attacks on deterministic signatures. Section 2.2.1 How public values are computed is not the same when looking at EdDSA and Elliptic Curve Diffie-Hellman (ECDH); for this reason, they should not be used with the other algorithm. Just to check: the claim is that EdDSA and ECDH compute public values differently (not EdDSA and ECDSA?), but that EdDSA keys should not be used with algorithms other than EdDSA? If batch signature verification is performed, a well-seeded cryptographic random number generator is REQUIRED. Signing and non- batch signature verification are deterministic operations and do not need random numbers of any kind. RFC 8032 doesn't talk about "batch" at all, so a reference is probably in order. Section 3.1 Some recipient algorithms transport the key, while others derive a key from secret data. For those algorithms that transport the key (such as AES Key Wrap), the size of the HMAC key SHOULD be the same size as the underlying hash function. For those algorithms that derive the key (such as ECDH), the derived key MUST be the same size as the underlying hash function. "same size as the output of the underlying hash function", please -- hash functions can also have an internal block size that is larger. Section 3.2.1 * A single key must only be used for messages of a fixed or known length. If this is not the case, an attacker will be able to What's an example of a known-but-not-fixed length message? Just something with internal framing? Section 4.1 The Galois/Counter Mode (GCM) mode is a generic authenticated encryption block cipher mode defined in [AES-GCM]. The GCM mode is combined with the AES block encryption algorithm to define an AEAD cipher. GCM on its own is merely AE but AES-GCM is AEAD? That doesn't seem to add up... Section 6.1.2 If the salt/nonce value is generated randomly, then it is suggested that the length of the random value be the same length as the hash function underlying HKDF. While there is no way to guarantee that it "output length of the hash function", please. Section 6.2, 6.3, 6.4 Why does Direct Key [encryption] get its own top-level subsection with reference to -struct, but we jump straight into AES Key Wrap without a wrapping "Key Wrap" subsection or -struct reference, and likewise for "Direct Key Agreement" and "Key Agreement with Key Wrap"? It feels like Section 6.1 is the outlier here. Section 6.3 be unique for the pair of keys being used. It is acceptable to use a global counter that is incremented for every static-static operation and use the resulting value. When using static keys, Perhaps say something strongly worded about storing the updated counter value to permanent storage before using the resulting key? Section 7.2 s/X25591/X25519/ Section 8 The algorithm identifier is not part of the capabilities data as it should already be part of message structure. There is a presumption in the way that this is laid out is that the algorithm identifier nit: strike the last "is". itself is not needed to be a part of this as it is specified in a different location. nit(?): "be a part of this" is a little vague/informal. capabilities. This means that if one wishes to enumerate all of the capabilities for a device which implements ECDH, it requires multiple pairs of capability structures (algorithm, key) to deal with the different key types and curves that are supported. For a key, the An example of this would be pretty helpful. Section 8.1 * OKP, EC2: The list of capabilities is: - The key type value. (1 for OKP or 2 for EC2.) - One curve for that key type from the "COSE Elliptic Curve" registry. Am I reading this right that the idea is to use capabilities to lock a key down to a single curve? * Symmetric: The list of capabilities is: - The key type value (4). but we're not using this opportunity to indicate whether a symmetric key is for encryption vs. HMAC? Section 8.2 (from the "COSE Key Types" Registry). It is expected future registered algorithms could have zero, one, or multiple elements. nit: missing "that". Section 10 Is [this document] going to be added as a reference on these registries? Should it replace or augment 8152 in that role? I think that the COSE Header Algorithm Parameters Registry updates need to be in this document, not -struct. Section 10.1, 10.2 Do we want to say anything about the encoded verson of the Capabilities array being an array of integers? Section 10.2 Why is the word "reserved" in the description for the IV-GENERATION algorithm? Section 11 I'm not 100% sure that we want the security considerations to be so close to identical between -struct and -algs. One area that has been starting to get exposure is doing traffic analysis of encrypted messages based on the length of the message. I think this may have graduated from "starting" to be more of a mainstream thing :) Section 12.1 Trying to chase [MAC] gives me a "reference has moved" notice. I guess there's a newer version? Section 12.2 I think RFC 8017 needs to be normative, since we use it for I2OSP Acknowledgments Göran could probably get his proper name, now. From nobody Wed Jun 10 21:20:47 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEC23A1656; Wed, 10 Jun 2020 21:20:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-cose-webauthn-algorithms@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov , ivaylo@ackl.io X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159184924026.22086.10470223464476609196@ietfa.amsl.com> Date: Wed, 10 Jun 2020 21:20:40 -0700 Archived-At: Subject: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-webauthn-algorithms-07: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 04:20:41 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-cose-webauthn-algorithms-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- As Roman notes, the conversion of secp256k1 to not-recommended in the -07 was incomplete: Table 2 and the prose below it still need to be adjusted. (Putting this in the discuss section so I remember to double-check it when the new revision arrives.) Also, I think we need to more strongly reiterate the cross-algorithm risk, specifically mentioned in Section 2.1.1 of draft-ietf-cose-rfc8152bis-algs-09, regarding an attacker changing headers from secp256r1 to secp256k1 (or vice versa), and that the only known way to deal with this attack is to limit any given protocol participant to using at most one of the two curves. (AFAIK neither 'alg' nor 'crv' are required to be protected elements, so while limiting this curve to the ES256K algorithm helps in many cases, is not a fail-safe.) Finally, my apologies for not catching this earlier, but the COSE charter says that the WG deliverable to "define the algorithms needed for W3C Web Authentication for COSE" is to be an Informational document. It looks like we didn't notice that when the WG -00 was submitted and it has just been carried through unchanged. (Note, however, that the requested values for ES256K and secp256k1 are in the "Standards Action" range and would not be available for an informational document.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Are we planning to update the section references from RFC 8152 to the bis documents also on this telechat? Section 2 I see that the IANA registry currently lists RS256 as Recommended:Deprecated, but this document lists it as Recommended:No. Which is correct? Section 3.1 preserved. If the uncompressed representation is used, the "y" value represented MUST likewise be exactly 256 bits, with any leading zeros preserved; if the compressed representation is used, the "y" value MUST be a boolean value, as specified in Section 13.1.1 of [RFC8152]. At least the "MUST be a boolean value" is fully redundant with RFC 8152, and might not need normative language. Section 3.3 This specification defines how to use the secp256k1 curve for ECDSA signatures for both JOSE and COSE implementations. While in theory, the curve could also be used for ECDH-ES key agreement, it is beyond the scope of this specification to state whether this is or is not advisable. Thus, whether to recommend its use with ECDH-ES is left for experts to decide in future specifications. This text doesn't really do a great job at reflecting the potential concerns/risks described at https://mailarchive.ietf.org/arch/msg/cose/kS25kvSH85dcyzZi1lcU2-6yDEE/ -- "there may be theoretical problems with the curve" seems worth noting! Section 5.2 If we're going to mention exponent restrictions from Section 8.3 of RFC 7518 in Section 5.3, we should probably mention them here as well. Section 5.3 New COSE applications MUST NOT use this algorithm. Is it new applications, or new protocols, or something else? From nobody Wed Jun 10 22:55:57 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C28C33A16FF; Wed, 10 Jun 2020 22:55:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-cose-hash-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov , ivaylo@ackl.io X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159185494077.19612.5376022702223451135@ietfa.amsl.com> Date: Wed, 10 Jun 2020 22:55:40 -0700 Archived-At: Subject: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-hash-algs-04: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 05:55:41 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-cose-hash-algs-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- In Section 3.3: The SHA-3 hash algorithms have a significantly different structure than the SHA-2 hash algorithms. One of the benefits of this differences is that when computing a shorter SHAKE hash value, the value is not a prefix of the result of computing the longer hash. I did not think this was the case -- the sponge construction seems to only use the 'd' parameter to truncate the output stream, but 'd' does not seem to otherwise cause the output stream to vary. Indeed, Section 4 of FIPS-202 concludes: % Note that the input d determines the number of bits that Algorithm 8 % returns, but it does not affect their values. Am I misunderstanding what the quoted statement is trying to convey? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 [CMS]. This omission was intentional as a structure consisting of just a digest identifier, the content, and a digest value does not by itself provide any strong security service. Additionally, an application is going to be better off defining this type of structure so that it can include any additional data that needs to be hashed, as well as methods of obtaining the data. (The "additionally" bits were also part of the original intentional omission's justification. I don't know that we need to make this clear specifically, though.) signature to be validated without first downloading all of the content associated with the signature. This capability can be of even greater importance in a constrained environment as not all of the content signed may be needed by the device. nit (I think this came up in Warren's comments, too?): we should clarify that this functionality is used when the content being signed is broken up into multiple chunks, each of which is represented as a hash value+hash algorithm -- for any individual signature output or hash value, the full plaintext must be processed, but the chunks that are not of interested do not need to be fetched+hashed -- only their contribution to the signature is processed. common. One of the primary things that has been identified by a hash function for secure message is a certificate. Two examples of this nit: the grammar doesn't look right; maybe "messages" plural? Section 2 signature or using the hash as part of the body to be signed. Other uses of hash functions do not require the same level of strength. This sounds like it's definitively saying that all other uses do not require this strength, which doesn't seem right. Maybe "may not require"? them. Applications should also make sure that the ability to change hash functions is part of the base design as cryptographic advances are sure to reduce the strength of a hash function. BCP 201 would be a great reference here :) A hash function is a map from one, normally large, bit string to a second, usually smaller, bit string. There are going to be collisions by a hash function. The trick is to make sure that it is difficult to find two values that are going to map to the same output side note: if I was writing this (but I'm not!), I'd say something like "because the output range has so many fewer possible configurations than the input domain, there will inherently be many collisions where different input strings produce the same output string". Section 2.1 * Additional data, this can be something as simple as a random value to make finding hash collisions slightly harder (as the value (Do we want to use the word "salt"?) handed to the application cannot have been selected to have a collision), or as complicated as a set of processing instructions I can't tell if this parenthetical is supposed to say "as long as the [salt] value handed to the application[...]" or "as the data handed to the application cannot have been selected to have a collision when combined with the unknown-at-the-time [salt] value". hashed be included. (Encoding as a CBOR array accomplished this requirement.) nit: s/accomplished/accomplishes/ COSE_Hash_V = ( 1 : int / tstr, # Algorithm identifier 2 : bstr, # Hash value 3 : tstr ?, # Location of object hashed 4 : any ? # object containing other details and things ) nit: the '?' goes before the optional element, not after. An alternative structure that could be used for situations where one is searching a group of objects for a match. In this case, the nit: sentence fragment. Section 3.1 Despite the above, there are still times where SHA-1 needs to be used and therefore it makes sense to assign a point for the use of this hash algorithm. Some of these situations are with historic HSMs nit: do you have a preference among "point", "code point", and "codepoint"? Because of the known issues for SHA-1 and the fact that is should no nit: s/is/it/ Section 3.2 * *SHA-256/64* provides a truncated hash. The length of the truncation is designed to allow for smaller transmission size. The trade-off is that the odds that a collision will occur increase proportionally. Locations that use this hash function Pedantically, "proportionally" would require some explanation (and possibly the word "exponentially". I don't insist on any changes here, though. need either to analysis the potential problems with having a nit: s/analysis/analyze/ collision occur, or where the only function of the hash is to narrow the possible choices. nit: the grammar of the "or where [...]" clause doesn't match up with the start of the sentence. The latter is the case for [I-D.ietf-cose-x509]. The hash value is used to select possible certificates and, if there are multiple choices then, each choice can be tested by using the public key. nit: maybe "multiple choices remaining"? Section 3.3 The family of SHA-3 hash algorithms [FIPS-202] was the result of a competition run by NIST. The pair of algorithms known as SHAKE-128 and SHAKE-256 are the instances of SHA-3 that are currently being standardized in the IETF. "But what about RFC 6931?" (Yes, I see RFC 8692 and RFC 8702 that only do the SHAKEs.) Unlike the SHA-2 hash functions, no algorithm identifier is created for shorter lengths. Applications can specify a minimum length for any hash function. A validator can infer the actual length from the hash value in these cases. In light of my disuss point, I think this claim needs some reconsiderations as well -- absent some other mechanism to detect modification (truncation), an attacker could truncate a longer output to a shorter one, undetected by the validator, since the one stream is a prefix of the other. |SHAKE128|TBD10|128-bit SHAKE| [] | [This | Yes | I'm not sure that we really want the description to just be "128-bit SHAKE" -- the 128 and 256 relate to the "capacity" of the sponge construction and are not tied to the output length. Also, I think we should consider having some "minimum output length" that has to be used in order to qualify for the "Recommended:Yes". Section 4.1 In addition, IANA is to add the value of 'Filter Only' to the set of legal values for the 'Recommended' column. This value is only to be used for hash functions and indicates that it is not to be used for purposes which require collision resistance. IANA is requested to add this document to the reference section for this table due to this addition. So the ordering is now "Yes, No, Filter Only, Deprecated"? Section 5 There are probably some considerations relating to the application's "additional data" used in a CBOR hash structure such as the (first) one in Section 2.1. Making sure that all the relevant attributes/parameters are bound into the computation/verification properly, etc. security all need to be included as part of this analysis. In many cases the value being hashed is a public value, as such pre-image resistance is not part of this analysis. nit: comma splice. Algorithm agility needs to be considered a requirement for any use of hash functions. As with any cryptographic function, hash functions (BCP 201 rears its head again) Section 6 It's not really going to work so great to have normative references to both RFC 8152 and the thing that obsoletes RFC 8152. Given the one place that we cite [COSE], moving it to informative seems reasonable. Section 7 RFC 3174, on the other hand, is needed to implement one of the hashes that we're allocating a codepoint for, so should probably be normative. (It's already on the downrefs registry, so that's not a concern.) Also, if we depend on the registry actions in 8152bis-algs, does that make it a normative dependency? (8152bis-struct will be taking care of any downref concerns already, I think, for what it's worth.) From nobody Wed Jun 10 23:12:44 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F8B3A1714; Wed, 10 Jun 2020 23:12:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <159185596258.26467.14069214515654867983@ietfa.amsl.com> Date: Wed, 10 Jun 2020 23:12:43 -0700 Archived-At: Subject: [COSE] Murray Kucherawy's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 06:12:43 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-cose-rfc8152bis-algs-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As others have pointed out, the Abstract needs fixing. I'm surprised none of my colleagues thought the document status and downrefs problem isn't worthy of a DISCUSS, because it's important to get right. But as one of the newbies of the group I'll go along with them and merely pile on by mentioning it again. And lo, a bunch of editorial nits: Section 1: * "... small in terms of messages transport and implementation size ..." -- s/messages/message/ Section 1.4: * Missing period at the end of the last sentence. Section 2: * "Part Section 9.1 of ..." -- remove "Part" Section 2.1: * "... collisions of this value leads to ..." -- s/leads/lead/ * "(2 coordinate elliptic curve)" -- suggest "two" instead of "2" OLD: Other documents can define it to work with other curves and points in the future. NEW: Future documents may extend support to include other curves and points. Section 2.1.1: * "... truncate a hash function down ..." -- "down" feels redundant here Section 2.2.1: * "... for this reason, they should not be used with the other algorithm." -- I don't understand what this is saying. Section 3: * "Part Section 9.2 of ..." -- remove "Part" * "... such as MD5 has decreased over time; the security ..." -- s/;/,/ Section 3.2: * Where is "IV" defined? Section 3.2.1: * "Cipher Block Chaining (CBC) mode, if the same key ..." -- maybe add "In" at the front? Section 4: * Errant "Part" at the front again. Section 5: * ... and again. Section 5.1: * I had to look up what a "bstr" is. Is that definition assumed to be imported from somewhere? Section 6: * "Part" again. Section 8: * I don't understand the second paragraph of this section. Section 10.2: * "... this registration, if this is ..." -- "If" should start a new sentence. * "... then the DE should be ..." -- s/DE/Designated Expert/ Section 11: * "One area that has been starting to get exposure is doing traffic ..." -- the word "doing" feels out of place here From nobody Wed Jun 10 23:33:29 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7300C3A172C; Wed, 10 Jun 2020 23:33:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Shwetha Bhandari via Datatracker To: Cc: draft-ietf-cose-rfc8152bis-struct.all@ietf.org, last-call@ietf.org, cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159185720736.18708.5241126402226037262@ietfa.amsl.com> Reply-To: Shwetha Bhandari Date: Wed, 10 Jun 2020 23:33:27 -0700 Archived-At: Subject: [COSE] Opsdir last call review of draft-ietf-cose-rfc8152bis-struct-10 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 06:33:27 -0000 Reviewer: Shwetha Bhandari Review result: Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts per guidelines in RFC5706 . Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This is a bis document for specifying data format for basic security services - signing, message authentication, encryption for data in Constrained Binary Object Representation(CBOR). This document describes data structures and processes in detail, with minor updates to RFC8152 along with separation of algorithms in a companion draft. In combination with a companion document on algorithms, it obsoletes RFC 8152. I found this draft well written and cleaned up for easy mapping from prose to CDDL. Appendix with consolidate CDDL for COSE would be additionally helpful instead of the CDDL that is spread out through the document. This draft does not introduce any operational or management concerns from RFC 8152. From nobody Thu Jun 11 06:47:05 2020 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 7C07E3A0860; Thu, 11 Jun 2020 06:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 fAHU_QsUdAf6; Thu, 11 Jun 2020 06:47:01 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650136.outbound.protection.outlook.com [40.107.65.136]) (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 43FA93A084B; Thu, 11 Jun 2020 06:47:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BS6wGliYeH/GA4uv89MD56XhZmiFVHop0E6/OfykXOZ/BflzIMrB/aHOyVs5ItqrMvFbNPzstkHQX+n86LMyI7L/++mXJWWwUblqDIKAgY5AhsSr6IHx4LhLEQcGPbRhMpdnQ/tNex0rwNTfmzUO1H+oBNPssXtzbD9pXJVizxo5yzWrqQPvX5TYwRVqKWnvjtbK7b6CuhdtDjiwQ+63/FtSEjiAb2GdsBDMA9naAuW80xhteIGAdwl841+LoJCd1CSIHuEKU52VCU83iscABOnO+2z2aCv96E3Cdb/P0DVJOUKcbN+7e3mT3CegeAjkZRwdDp4uSuxEFbuzjq/tEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0WI+M3gffXaf3fnWg0WBhPtTRDGMlGbJVvdjf5UDAzM=; b=HyyzJ0Z2p+QaTkbL9Yd77HSTUKxhBvDPXqGWuvVh5/g7td/MsFr5difskTbkeQ1Jd6WdKM/f2L/TXiSNdUl6cN1UU3zLtI/Zz3LbDGu9/lyUZzkS+zNppwBMb9WBfOX694BA5nHb5T0i5o2C60ZYxSEsz1Asb2yi6nMDSywiMkN5sjLxyW7uCCeBtLHXt9mdvT4d5n512bwEw+eGxM5mhuIMIHwHsae2SgMNuFbIFu19StL0IfafbKFxOjsQ8918zmo/0pGuotadWALH80Aw9mS7zzDgUXSBsxs7vufRXnlduzOpQ/65Pjb9JyCOACygkErfZQs/SskcRCz2PlvqSA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0WI+M3gffXaf3fnWg0WBhPtTRDGMlGbJVvdjf5UDAzM=; b=KjSuRJpFz6wHLOIvdSPpti9qaHqfA/PjxXiQfN8tqqA7x3rnZ/nUBpd641A4H+C50V7fG7tV8/OtAMmLsbH5xq33r9vsr4CG/yUT2uY/HS7Bf5YE5GqDy0VeT92CYMPLy6Mr0j4Zq/l1xbM7Pv/bNr9S3c0KsexGR/qCAG3+H9Y= Received: from DM6PR00MB0684.namprd00.prod.outlook.com (2603:10b6:5:21c::8) by DM6PR00MB0715.namprd00.prod.outlook.com (2603:10b6:5:21c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3126.0; Thu, 11 Jun 2020 13:46:59 +0000 Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::21bc:a480:7957:24c6]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::21bc:a480:7957:24c6%7]) with mapi id 15.20.3126.000; Thu, 11 Jun 2020 13:46:59 +0000 From: Mike Jones To: Benjamin Kaduk , The IESG CC: "draft-ietf-cose-webauthn-algorithms@ietf.org" , "cose-chairs@ietf.org" , "cose@ietf.org" , Ivaylo Petrov Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-cose-webauthn-algorithms-07: (with DISCUSS and COMMENT) Thread-Index: AdY/9sX256eDBIcnRX6tYZth4V/ozA== Date: Thu, 11 Jun 2020 13:46:59 +0000 Message-ID: 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_ActionId=4c2bfec5-a739-4e1e-8006-0000b351dbcb; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-11T13:34:06Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 69e9a653-4d94-4b87-acfd-08d80e0de9f1 x-ms-traffictypediagnostic: DM6PR00MB0715: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0431F981D8 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /LVW1oLcShLL4bKRE7zVizyrbFwATZKsrscK37ZhV7VcTCmwHlhmr5Nb+FUp0riJoGqUJSSP7w50Kqx5JHK24PDhtnd3N59uOg9n7uo/+n/k1qMiVGjbgUNE5IjQ175LC6iv0plKuqHKlnHw7APIOZpcCh54O2mhWY1m3KpKqOLmhpxU4qPXspUNcsy8/VKXmk+IQPZU1mHWyP0PCQ/2nL/RixKB75naXFxsYaBlMnOo4t1CIclC+bOvPliW6mHAilfaRrJTsQdG5F60RCCmMpPB0HQr7ICG4YTh8qfypqNdfcuXzrZ2jUmNcTWV/6P/6S4M8hy6qbveQqV2oES66OuAg+U/cfBN8+oXtJRniYi2QdFRcrpbDc6I245zys7H7sde1ORje3EYoZYwrBmZRg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(136003)(346002)(376002)(39860400002)(82960400001)(82950400001)(5660300002)(64756008)(66476007)(2906002)(66556008)(66446008)(52536014)(33656002)(86362001)(76116006)(66946007)(8990500004)(7696005)(71200400001)(478600001)(9686003)(316002)(55016002)(10290500003)(186003)(8936002)(8676002)(26005)(966005)(53546011)(6506007)(54906003)(83380400001)(4326008)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: lLF3gelLU5O7b9vByQQPHeyrYYRdCt4+otQ7a+r/wYBIGC1CyoLbs5TvUMD9d6gZBWJfUg8JK3Yh3i29UU8+jXK3Wj/zXkzZB5mojEa6OJL2of0cV8JFF+kPodJTMf3H+C89qqwvqashd3AcEKNRJVyHdtG2fJI4FY6ZQj580HuHh/wlOIQq1VdHqaD0aFupm0gZuauFwGXISKBzgH5+bp/XlkGLDf4r8ZqFCKO64Mkg2pDlytAdeyg8f26ZYoWIjr9nWudF1F3hRxXGzzxCrrpCi1zEOvpq8dz+Dyhn7Yedmai5aw1mgdMW/M1v4/wsav39SABSWllI5vQaeo4PY/xpEYFyH5/b+cqa599DyxpWucSGPjexovx/4/RuqRtLLZwmFmhuh72zLb0zAOxFo4GxfzUSqr9IfR5veOXZ/JeUQJtD4Ck8Fs5duinbeys2N6vVxC8m4Sm3NO1D2Uob+jVuyKfarafYK/vwagYQEpA= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69e9a653-4d94-4b87-acfd-08d80e0de9f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2020 13:46:59.4133 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: svzIO2n9bP2QIcdzr8yZ9OoInThrQ5fHUPLrX9/rOII1SapqfRKNxWP9nBf0roQSPf74fujWKlb/uMgZcYktAQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0715 Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-webauthn-algorithms-07: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 13:47:04 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgQmVuLiAgVGhlIG9uZSBwb2ludCB0aGF0IHlvdSBtYXkg d2FudCB0byBhY3R1YWxseSBkaXNjdXNzIGR1cmluZyB0aGUgdGVsZWNoYXQgaXMgd2hldGhlciB0 aGUgZG9jdW1lbnQgY2FuIHJlbWFpbiBzdGFuZGFyZHMgdHJhY2sgc28gdGhhdCBpdCBxdWFsaWZp ZXMgZm9yICJTdGFuZGFyZHMgQWN0aW9uIiByZWdpc3RyYXRpb25zLCBhcyBkZXNjcmliZWQgYmVs b3cuICBNeSByZXNwb25zZXMgYXJlIGlubGluZSBiZWxvdywgcHJlZml4ZWQgYnkgIk1pa2U+Ii4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJlbmphbWluIEthZHVrIHZpYSBE YXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4gDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMTAs IDIwMjAgOToyMSBQTQ0KVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWll dGYtY29zZS13ZWJhdXRobi1hbGdvcml0aG1zQGlldGYub3JnOyBjb3NlLWNoYWlyc0BpZXRmLm9y ZzsgY29zZUBpZXRmLm9yZzsgSXZheWxvIFBldHJvdiA8aXZheWxvQGFja2wuaW8+OyBpdmF5bG9A YWNrbC5pbw0KU3ViamVjdDogQmVuamFtaW4gS2FkdWsncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt Y29zZS13ZWJhdXRobi1hbGdvcml0aG1zLTA3OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0K DQpCZW5qYW1pbiBLYWR1ayBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlv biBmb3INCmRyYWZ0LWlldGYtY29zZS13ZWJhdXRobi1hbGdvcml0aG1zLTA3OiBEaXNjdXNzDQoN CldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k IHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBs aW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dl dmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0 ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJ RVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxv bmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29zZS13ZWJhdXRobi1hbGdv cml0aG1zLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRElTQ1VTUzoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K QXMgUm9tYW4gbm90ZXMsIHRoZSBjb252ZXJzaW9uIG9mIHNlY3AyNTZrMSB0byBub3QtcmVjb21t ZW5kZWQgaW4gdGhlDQotMDcgd2FzIGluY29tcGxldGU6IFRhYmxlIDIgYW5kIHRoZSBwcm9zZSBi ZWxvdyBpdCBzdGlsbCBuZWVkIHRvIGJlIGFkanVzdGVkLiAgKFB1dHRpbmcgdGhpcyBpbiB0aGUg ZGlzY3VzcyBzZWN0aW9uIHNvIEkgcmVtZW1iZXIgdG8gZG91YmxlLWNoZWNrIGl0IHdoZW4gdGhl IG5ldyByZXZpc2lvbiBhcnJpdmVzLikNCg0KTWlrZT4gU29ycnkgZm9yIG5vdCBjYXRjaGluZyB0 aGlzIGluIHRoZSBsYXN0IHJvdW5kIG9mIGVkaXRzLiAgSSdsbCBtYWtlIHRoZXNlIHVwZGF0ZXMu DQoNCkFsc28sIEkgdGhpbmsgd2UgbmVlZCB0byBtb3JlIHN0cm9uZ2x5IHJlaXRlcmF0ZSB0aGUg Y3Jvc3MtYWxnb3JpdGhtIHJpc2ssIHNwZWNpZmljYWxseSBtZW50aW9uZWQgaW4gU2VjdGlvbiAy LjEuMSBvZiBkcmFmdC1pZXRmLWNvc2UtcmZjODE1MmJpcy1hbGdzLTA5LCByZWdhcmRpbmcgYW4g YXR0YWNrZXIgY2hhbmdpbmcgaGVhZGVycyBmcm9tIHNlY3AyNTZyMSB0byBzZWNwMjU2azEgKG9y IHZpY2UgdmVyc2EpLCBhbmQgdGhhdCB0aGUgb25seSBrbm93biB3YXkgdG8gZGVhbCB3aXRoIHRo aXMgYXR0YWNrIGlzIHRvIGxpbWl0IGFueSBnaXZlbiBwcm90b2NvbCBwYXJ0aWNpcGFudCB0byB1 c2luZyBhdCBtb3N0IG9uZSBvZiB0aGUgdHdvIGN1cnZlcy4gIChBRkFJSyBuZWl0aGVyICdhbGcn IG5vciAnY3J2JyBhcmUgcmVxdWlyZWQgdG8gYmUgcHJvdGVjdGVkIGVsZW1lbnRzLCBzbyB3aGls ZSBsaW1pdGluZyB0aGlzIGN1cnZlIHRvIHRoZSBFUzI1NksgYWxnb3JpdGhtIGhlbHBzIGluIG1h bnkgY2FzZXMsIGlzIG5vdCBhDQpmYWlsLXNhZmUuKQ0KDQpNaWtlPiBPSyAtIEknbGwgZW5oYW5j ZSB0aGlzIGRpc2N1c3Npb24gYWxvbmcgdGhlc2UgbGluZXMuDQoNCkZpbmFsbHksIG15IGFwb2xv Z2llcyBmb3Igbm90IGNhdGNoaW5nIHRoaXMgZWFybGllciwgYnV0IHRoZSBDT1NFIGNoYXJ0ZXIg c2F5cyB0aGF0IHRoZSBXRyBkZWxpdmVyYWJsZSB0byAiZGVmaW5lIHRoZSBhbGdvcml0aG1zIG5l ZWRlZCBmb3IgVzNDIFdlYiBBdXRoZW50aWNhdGlvbiBmb3IgQ09TRSIgaXMgdG8gYmUgYW4gSW5m b3JtYXRpb25hbCBkb2N1bWVudC4NCkl0IGxvb2tzIGxpa2Ugd2UgZGlkbid0IG5vdGljZSB0aGF0 IHdoZW4gdGhlIFdHIC0wMCB3YXMgc3VibWl0dGVkIGFuZCBpdCBoYXMganVzdCBiZWVuIGNhcnJp ZWQgdGhyb3VnaCB1bmNoYW5nZWQuICAoTm90ZSwgaG93ZXZlciwgdGhhdCB0aGUgcmVxdWVzdGVk IHZhbHVlcyBmb3IgRVMyNTZLIGFuZCBzZWNwMjU2azEgYXJlIGluIHRoZSAiU3RhbmRhcmRzIEFj dGlvbiINCnJhbmdlIGFuZCB3b3VsZCBub3QgYmUgYXZhaWxhYmxlIGZvciBhbiBpbmZvcm1hdGlv bmFsIGRvY3VtZW50LikNCg0KTWlrZT4gSSdkIHByZWZlciB0byBrZWVwIHRoZSB2YWx1ZXMgaW4g dGhlICJTdGFuZGFyZHMgQWN0aW9uIiByYW5nZSwgaWYgd2UgY2FuIGRvIHRoYXQuICBJcyBpdCBw b3NzaWJsZSB0byBnZXQgdGhlIElFU0cgdG8gYWxsb3cgdGhpcyBkb2N1bWVudCB0byByZW1haW4g c3RhbmRhcmRzIHRyYWNrPyAgSSBkaWRuJ3QgcmVhbGl6ZSB0aGF0IEluZm9ybWF0aW9uYWwgUkZD cyBkaWRuJ3QgcXVhbGlmeSBmb3IgIlN0YW5kYXJkcyBBY3Rpb24iLg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpBcmUgd2UgcGxhbm5pbmcgdG8gdXBkYXRlIHRo ZSBzZWN0aW9uIHJlZmVyZW5jZXMgZnJvbSBSRkMgODE1MiB0byB0aGUgYmlzIGRvY3VtZW50cyBh bHNvIG9uIHRoaXMgdGVsZWNoYXQ/DQoNCk1pa2U+IEkgb25seSBwbGFuIHRvIHVwZGF0ZSB0aGUg cmVmZXJlbmNlcyBvZiB0aGUgYmlzIGRvY3VtZW50cyBmaW5pc2ggZmlyc3QuDQoNClNlY3Rpb24g Mg0KDQpJIHNlZSB0aGF0IHRoZSBJQU5BIHJlZ2lzdHJ5IGN1cnJlbnRseSBsaXN0cyBSUzI1NiBh cyBSZWNvbW1lbmRlZDpEZXByZWNhdGVkLCBidXQgdGhpcyBkb2N1bWVudCBsaXN0cyBpdCBhcyBS ZWNvbW1lbmRlZDpOby4NCldoaWNoIGlzIGNvcnJlY3Q/DQoNCk1pa2U+IEdvb2QgY2F0Y2guICBJ dCBzaG91bGQgYmUgIk5vIi4gIEknbGwgaW5mb3JtIElBTkEuDQoNClNlY3Rpb24gMy4xDQoNCiAg IHByZXNlcnZlZC4gIElmIHRoZSB1bmNvbXByZXNzZWQgcmVwcmVzZW50YXRpb24gaXMgdXNlZCwg dGhlICJ5IiB2YWx1ZQ0KICAgcmVwcmVzZW50ZWQgTVVTVCBsaWtld2lzZSBiZSBleGFjdGx5IDI1 NiBiaXRzLCB3aXRoIGFueSBsZWFkaW5nIHplcm9zDQogICBwcmVzZXJ2ZWQ7IGlmIHRoZSBjb21w cmVzc2VkIHJlcHJlc2VudGF0aW9uIGlzIHVzZWQsIHRoZSAieSIgdmFsdWUNCiAgIE1VU1QgYmUg YSBib29sZWFuIHZhbHVlLCBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiAxMy4xLjEgb2YgW1JGQzgx NTJdLg0KDQpBdCBsZWFzdCB0aGUgIk1VU1QgYmUgYSBib29sZWFuIHZhbHVlIiBpcyBmdWxseSBy ZWR1bmRhbnQgd2l0aCBSRkMgODE1MiwgYW5kIG1pZ2h0IG5vdCBuZWVkIG5vcm1hdGl2ZSBsYW5n dWFnZS4NCg0KTWlrZT4gT0sNCg0KU2VjdGlvbiAzLjMNCg0KICAgVGhpcyBzcGVjaWZpY2F0aW9u IGRlZmluZXMgaG93IHRvIHVzZSB0aGUgc2VjcDI1NmsxIGN1cnZlIGZvciBFQ0RTQQ0KICAgc2ln bmF0dXJlcyBmb3IgYm90aCBKT1NFIGFuZCBDT1NFIGltcGxlbWVudGF0aW9ucy4gIFdoaWxlIGlu IHRoZW9yeSwNCiAgIHRoZSBjdXJ2ZSBjb3VsZCBhbHNvIGJlIHVzZWQgZm9yIEVDREgtRVMga2V5 IGFncmVlbWVudCwgaXQgaXMgYmV5b25kDQogICB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0 aW9uIHRvIHN0YXRlIHdoZXRoZXIgdGhpcyBpcyBvciBpcyBub3QNCiAgIGFkdmlzYWJsZS4gIFRo dXMsIHdoZXRoZXIgdG8gcmVjb21tZW5kIGl0cyB1c2Ugd2l0aCBFQ0RILUVTIGlzIGxlZnQNCiAg IGZvciBleHBlcnRzIHRvIGRlY2lkZSBpbiBmdXR1cmUgc3BlY2lmaWNhdGlvbnMuDQoNClRoaXMg dGV4dCBkb2Vzbid0IHJlYWxseSBkbyBhIGdyZWF0IGpvYiBhdCByZWZsZWN0aW5nIHRoZSBwb3Rl bnRpYWwgY29uY2VybnMvcmlza3MgZGVzY3JpYmVkIGF0IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvY29zZS9rUzI1a3ZTSDg1ZGN5elppMWxjVTItNnlERUUvDQotLSAidGhl cmUgbWF5IGJlIHRoZW9yZXRpY2FsIHByb2JsZW1zIHdpdGggdGhlIGN1cnZlIiBzZWVtcyB3b3J0 aCBub3RpbmchDQoNCk1pa2U+IFRoYW5rcywgSSdsbCBhZGQgdGhpcy4NCg0KU2VjdGlvbiA1LjIN Cg0KSWYgd2UncmUgZ29pbmcgdG8gbWVudGlvbiBleHBvbmVudCByZXN0cmljdGlvbnMgZnJvbSBT ZWN0aW9uIDguMyBvZiBSRkMNCjc1MTggaW4gU2VjdGlvbiA1LjMsIHdlIHNob3VsZCBwcm9iYWJs eSBtZW50aW9uIHRoZW0gaGVyZSBhcyB3ZWxsLg0KDQpNaWtlPiBPSw0KDQpTZWN0aW9uIDUuMw0K DQogICBOZXcgQ09TRSBhcHBsaWNhdGlvbnMgTVVTVCBOT1QgdXNlIHRoaXMgYWxnb3JpdGhtLg0K DQpJcyBpdCBuZXcgYXBwbGljYXRpb25zLCBvciBuZXcgcHJvdG9jb2xzLCBvciBzb21ldGhpbmcg ZWxzZT8NCg0KTWlrZT4gSSBjYW4gc2F5ICJOZXcgQ09TRSBhcHBsaWNhdGlvbnMgYW5kIHByb3Rv Y29scyBNVVNUIE5PVCB1c2UgdGhpcyBhbGdvcml0aG0uIg0KDQpNaWtlPiBUaGFua3MgYWdhaW4g Zm9yIHRoZSB0aG9yb3VnaCByZXZpZXchDQoNCgkJCQktLSBNaWtlDQoNCg0K From nobody Thu Jun 11 12:31:10 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CA33A07C6; Thu, 11 Jun 2020 12:31:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <159190386841.13165.9636632461159555864@ietfa.amsl.com> Date: Thu, 11 Jun 2020 12:31:08 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-webauthn-algorithms-08.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 19:31:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption WG of the IETF. Title : COSE and JOSE Registrations for WebAuthn Algorithms Author : Michael B. Jones Filename : draft-ietf-cose-webauthn-algorithms-08.txt Pages : 14 Date : 2020-06-11 Abstract: The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms in the IANA "COSE Algorithms" registry, which are used by WebAuthn and CTAP implementations: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1, and ECDSA using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-08 https://datatracker.ietf.org/doc/html/draft-ietf-cose-webauthn-algorithms-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-webauthn-algorithms-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 11 12:36:04 2020 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 868DF3A07D8; Thu, 11 Jun 2020 12:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 rN5GwJ1KSIgD; Thu, 11 Jun 2020 12:35:51 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640106.outbound.protection.outlook.com [40.107.64.106]) (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 290E53A07D1; Thu, 11 Jun 2020 12:35:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VUpErNA165V420kDOkqVKISVAVdrv8eyXUlgUgn0sHEA+b0hq4c8KzGMWolGUD6fLr2nl68PRw4bZaYwAaXcOoM5lRc+Wi9IbI6fKb7feBDOOsidr45yKMtqMxEKm38wOpFr8JiFWiIvTsopHfB5jphSgsf2eYOKwYqoaPi+Q2cVlQOzKnU+W99dHjtv221Mb/NuKB3lv5lCMbfJ0piKiajj8eod6zH7vM+hbU67XxnctkjJTBmSMdlEubc3aLFMV/ugm5+EcfXDQnXrhnHaJQ0Bj41jRk+a9jfRqNXzdGrDFrpa6ZiZNw6mbKMnT4OTYGjKF4kKmFFAqPurvmSTQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JUjywUpbMGLmpDEJuyb70Zpa5Zg7a6NKyfWw2B1sRxM=; b=jo5lH76aCRuNV3EqSHVqaEXZnXlKPFHvCtzlG5F5bhf0M7etR+wBYs0AyYtMpiIhc4pBZDJnbuzQzxqB4931ByTary65ksbXzIIAaeCEnvNWHSiFk5OaEroskLloUry5/t2Ot+24F+tX5kj1NIHYjokmBWtV+GZAmsAwhxvpuDfZdlXaNuL8AtAOuloGkD+H81PrZkqhJm8U3j5UEX9g37Mp+uIpk7SDdwo4Y3OwJ2JdCbp+NVBTzfL15AVTQrfjrNqpUQfh0MCOzGmMC09kGPELbNu2whlzRgcPxi7CyxzXgREBl3raAs/zbvVcG+V6jjG28r09ZBOxtlZFCmvqCw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JUjywUpbMGLmpDEJuyb70Zpa5Zg7a6NKyfWw2B1sRxM=; b=KCOIl5l/AYQMpq6FTrEKp51bVuLqm5JDxOzf/QyM5H7BlZYCyZLGMa/marCOvkT1XUZxgJBSUdoxe0QyS7SdI7Tvs/485I07ZU2keO0tBoAgNsnxkjVzNW6+OZYciavbOt+Q4TJAaw2He+TqNmX0MBGVLXDTuo3t89ZfpOgzqsE= Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.0; Thu, 11 Jun 2020 19:35:49 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::290b:e959:b9c:6c0b]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::290b:e959:b9c:6c0b%4]) with mapi id 15.20.3131.000; Thu, 11 Jun 2020 19:35:49 +0000 From: Mike Jones To: Benjamin Kaduk , The IESG , Roman Danyliw CC: "draft-ietf-cose-webauthn-algorithms@ietf.org" , "cose-chairs@ietf.org" , "cose@ietf.org" , Ivaylo Petrov Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-cose-webauthn-algorithms-07: (with DISCUSS and COMMENT) Thread-Index: AdY/9sX256eDBIcnRX6tYZth4V/ozAAMERyw Date: Thu, 11 Jun 2020 19:35:49 +0000 Message-ID: References: In-Reply-To: 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_ActionId=4c2bfec5-a739-4e1e-8006-0000b351dbcb; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-11T13:34:06Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 531bce53-b679-42c3-f560-08d80e3ea508 x-ms-traffictypediagnostic: CH2PR00MB0678: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0431F981D8 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +ltM0Bafm/fCY3WHQRhykSRyE09HkRsgtZTkdOZXE1dREZPwPA4YZjDaHLwftcMfiIJwwR9Ie/bgYqnAhAbgenq1cBDXJfIvpi2vHbxqIwjblnJLBZAWmvy+coQzdhuWj2h3jyRaBCupQ18dakp5oMj9iyFCEij5VHBhOuxxV/3dtWw9M44EnnfgiI4L309ykmHARt2uGSM9T64mCWbztX/5lFXlxNXKEi2e8TJgAA2KWJpleS3dsjmkkaVbeBW2XLVKC8YA8n9bZNOpVnNQATx9AImqXIdkHCQzwzB1Dc9FdtJsBgJgPT0pNpGrVsz+vjdUulUQAxPe1xYPG4opS6a7zrs/Zugfk525T8KBjfRZOmbUottn9kWnR1/YBW0fhsyA2/wqJuEN1ZlLo2/I8w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(366004)(376002)(396003)(346002)(316002)(4326008)(5660300002)(52536014)(7696005)(10290500003)(478600001)(54906003)(110136005)(9686003)(76116006)(8676002)(66556008)(8936002)(66476007)(64756008)(2906002)(66946007)(82950400001)(82960400001)(55016002)(966005)(26005)(86362001)(33656002)(186003)(53546011)(6506007)(8990500004)(66446008)(83380400001)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: CB8r3DTImIIIWt4ILN9Hp9TnnDrDsx+J7fuL7r7D+fjfxNJfkJJgczYSm8j8VpfKeqfxqpnsoTmNoMjqeXhaz3XWzYZHtA53p2rzc5WJ31QT/4eFlRPytCz87B0poJJR7j7hyiR7JZoe6Y2/QeHfyNoN0v9kHi/OopVRAmPhU+5qvouz70oxo3xqx9hpE4SqFRIbuzlVeekWYprQ6k04xJ4Wy5UFDLowHGo+vwnjZC5uJzFUmRwnaBQ0vK4Axr9SZXrnTPUzeS++fG58qth0aaDxrsOvlp6lw86gupUYBpKcyuFUnJlY1e43MGBujMyf+NfK6sx/pX/GDzuQoh2BawWIQPFQpKyMv2A+NHfORgjgzBAWpcU7Rf1j+w+c3Lj6OeOeih04AH0+BumKRNAJ8GircV5w77MymW/efJnFBiWpCsb2NgW/OZypHzMxphrVdrjdf4PMuy2G2ppBxYSQ7MONcSdvHxmqGP2eTAcWG7U= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 531bce53-b679-42c3-f560-08d80e3ea508 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2020 19:35:49.1916 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rJREKy5VcKNN8Xn6nAXrCloM9VKEu9/L+f5MCBK91ozh9GkA3ZsqJ0Kc28/dX7/g5q/LS1nWJbqx/FcPuB0AFA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0678 Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-webauthn-algorithms-07: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 19:35:54 -0000 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29zZS13ZWJhdXRobi1hbGdv cml0aG1zLTA4IGhhcyBiZWVuIHB1Ymxpc2hlZCBhbmQgY29udGFpbnMgdGhlIGNoYW5nZXMgZGVz Y3JpYmVkIGJlbG93IHRvIGFkZHJlc3MgQmVuJ3MgY29tbWVudHMsIGFzIHdlbGwgYXMgZXhwbGFp bmluZyB0aGUgYmFzaXMgb2YgdGhlIOKAnG5vdCByZWNvbW1lbmRlZOKAnSByZWdpc3RyYXRpb24g aW4gU2VjdGlvbiA1LjQsIHBlciBSb21hbidzIGNvbW1lbnQuICBUaGFua3MgYm90aCBmb3IgeW91 ciB1c2VmdWwgcmV2aWV3cyENCg0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IE1pa2UgSm9uZXMgDQpTZW50OiBUaHVyc2RheSwgSnVuZSAxMSwgMjAyMCA2 OjQ3IEFNDQpUbzogJ0JlbmphbWluIEthZHVrJyA8a2FkdWtAbWl0LmVkdT47IFRoZSBJRVNHIDxp ZXNnQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtY29zZS13ZWJhdXRobi1hbGdvcml0aG1zQGll dGYub3JnOyBjb3NlLWNoYWlyc0BpZXRmLm9yZzsgY29zZUBpZXRmLm9yZzsgSXZheWxvIFBldHJv diA8aXZheWxvQGFja2wuaW8+DQpTdWJqZWN0OiBSRTogQmVuamFtaW4gS2FkdWsncyBEaXNjdXNz IG9uIGRyYWZ0LWlldGYtY29zZS13ZWJhdXRobi1hbGdvcml0aG1zLTA3OiAod2l0aCBESVNDVVNT IGFuZCBDT01NRU5UKQ0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3LCBCZW4uICBUaGUgb25lIHBv aW50IHRoYXQgeW91IG1heSB3YW50IHRvIGFjdHVhbGx5IGRpc2N1c3MgZHVyaW5nIHRoZSB0ZWxl Y2hhdCBpcyB3aGV0aGVyIHRoZSBkb2N1bWVudCBjYW4gcmVtYWluIHN0YW5kYXJkcyB0cmFjayBz byB0aGF0IGl0IHF1YWxpZmllcyBmb3IgIlN0YW5kYXJkcyBBY3Rpb24iIHJlZ2lzdHJhdGlvbnMs IGFzIGRlc2NyaWJlZCBiZWxvdy4gIE15IHJlc3BvbnNlcyBhcmUgaW5saW5lIGJlbG93LCBwcmVm aXhlZCBieSAiTWlrZT4iLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQmVu amFtaW4gS2FkdWsgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPiANClNlbnQ6IFdl ZG5lc2RheSwgSnVuZSAxMCwgMjAyMCA5OjIxIFBNDQpUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5v cmc+DQpDYzogZHJhZnQtaWV0Zi1jb3NlLXdlYmF1dGhuLWFsZ29yaXRobXNAaWV0Zi5vcmc7IGNv c2UtY2hhaXJzQGlldGYub3JnOyBjb3NlQGlldGYub3JnOyBJdmF5bG8gUGV0cm92IDxpdmF5bG9A YWNrbC5pbz47IGl2YXlsb0BhY2tsLmlvDQpTdWJqZWN0OiBCZW5qYW1pbiBLYWR1aydzIERpc2N1 c3Mgb24gZHJhZnQtaWV0Zi1jb3NlLXdlYmF1dGhuLWFsZ29yaXRobXMtMDc6ICh3aXRoIERJU0NV U1MgYW5kIENPTU1FTlQpDQoNCkJlbmphbWluIEthZHVrIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1jb3NlLXdlYmF1dGhuLWFsZ29yaXRo bXMtMDc6IERpc2N1c3MNCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVj dCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBp biB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9y eSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5p ZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZvciBtb3JlIGlu Zm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0K VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBm b3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1j b3NlLXdlYmF1dGhuLWFsZ29yaXRobXMvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpESVNDVVNTOg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQpBcyBSb21hbiBub3RlcywgdGhlIGNvbnZlcnNpb24gb2Ygc2VjcDI1 NmsxIHRvIG5vdC1yZWNvbW1lbmRlZCBpbiB0aGUNCi0wNyB3YXMgaW5jb21wbGV0ZTogVGFibGUg MiBhbmQgdGhlIHByb3NlIGJlbG93IGl0IHN0aWxsIG5lZWQgdG8gYmUgYWRqdXN0ZWQuICAoUHV0 dGluZyB0aGlzIGluIHRoZSBkaXNjdXNzIHNlY3Rpb24gc28gSSByZW1lbWJlciB0byBkb3VibGUt Y2hlY2sgaXQgd2hlbiB0aGUgbmV3IHJldmlzaW9uIGFycml2ZXMuKQ0KDQpNaWtlPiBTb3JyeSBm b3Igbm90IGNhdGNoaW5nIHRoaXMgaW4gdGhlIGxhc3Qgcm91bmQgb2YgZWRpdHMuICBJJ2xsIG1h a2UgdGhlc2UgdXBkYXRlcy4NCg0KQWxzbywgSSB0aGluayB3ZSBuZWVkIHRvIG1vcmUgc3Ryb25n bHkgcmVpdGVyYXRlIHRoZSBjcm9zcy1hbGdvcml0aG0gcmlzaywgc3BlY2lmaWNhbGx5IG1lbnRp b25lZCBpbiBTZWN0aW9uIDIuMS4xIG9mIGRyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlzLWFsZ3Mt MDksIHJlZ2FyZGluZyBhbiBhdHRhY2tlciBjaGFuZ2luZyBoZWFkZXJzIGZyb20gc2VjcDI1NnIx IHRvIHNlY3AyNTZrMSAob3IgdmljZSB2ZXJzYSksIGFuZCB0aGF0IHRoZSBvbmx5IGtub3duIHdh eSB0byBkZWFsIHdpdGggdGhpcyBhdHRhY2sgaXMgdG8gbGltaXQgYW55IGdpdmVuIHByb3RvY29s IHBhcnRpY2lwYW50IHRvIHVzaW5nIGF0IG1vc3Qgb25lIG9mIHRoZSB0d28gY3VydmVzLiAgKEFG QUlLIG5laXRoZXIgJ2FsZycgbm9yICdjcnYnIGFyZSByZXF1aXJlZCB0byBiZSBwcm90ZWN0ZWQg ZWxlbWVudHMsIHNvIHdoaWxlIGxpbWl0aW5nIHRoaXMgY3VydmUgdG8gdGhlIEVTMjU2SyBhbGdv cml0aG0gaGVscHMgaW4gbWFueSBjYXNlcywgaXMgbm90IGENCmZhaWwtc2FmZS4pDQoNCk1pa2U+ IE9LIC0gSSdsbCBlbmhhbmNlIHRoaXMgZGlzY3Vzc2lvbiBhbG9uZyB0aGVzZSBsaW5lcy4NCg0K RmluYWxseSwgbXkgYXBvbG9naWVzIGZvciBub3QgY2F0Y2hpbmcgdGhpcyBlYXJsaWVyLCBidXQg dGhlIENPU0UgY2hhcnRlciBzYXlzIHRoYXQgdGhlIFdHIGRlbGl2ZXJhYmxlIHRvICJkZWZpbmUg dGhlIGFsZ29yaXRobXMgbmVlZGVkIGZvciBXM0MgV2ViIEF1dGhlbnRpY2F0aW9uIGZvciBDT1NF IiBpcyB0byBiZSBhbiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50Lg0KSXQgbG9va3MgbGlrZSB3ZSBk aWRuJ3Qgbm90aWNlIHRoYXQgd2hlbiB0aGUgV0cgLTAwIHdhcyBzdWJtaXR0ZWQgYW5kIGl0IGhh cyBqdXN0IGJlZW4gY2FycmllZCB0aHJvdWdoIHVuY2hhbmdlZC4gIChOb3RlLCBob3dldmVyLCB0 aGF0IHRoZSByZXF1ZXN0ZWQgdmFsdWVzIGZvciBFUzI1NksgYW5kIHNlY3AyNTZrMSBhcmUgaW4g dGhlICJTdGFuZGFyZHMgQWN0aW9uIg0KcmFuZ2UgYW5kIHdvdWxkIG5vdCBiZSBhdmFpbGFibGUg Zm9yIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQuKQ0KDQpNaWtlPiBJJ2QgcHJlZmVyIHRvIGtl ZXAgdGhlIHZhbHVlcyBpbiB0aGUgIlN0YW5kYXJkcyBBY3Rpb24iIHJhbmdlLCBpZiB3ZSBjYW4g ZG8gdGhhdC4gIElzIGl0IHBvc3NpYmxlIHRvIGdldCB0aGUgSUVTRyB0byBhbGxvdyB0aGlzIGRv Y3VtZW50IHRvIHJlbWFpbiBzdGFuZGFyZHMgdHJhY2s/ICBJIGRpZG4ndCByZWFsaXplIHRoYXQg SW5mb3JtYXRpb25hbCBSRkNzIGRpZG4ndCBxdWFsaWZ5IGZvciAiU3RhbmRhcmRzIEFjdGlvbiIu DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkFyZSB3ZSBwbGFu bmluZyB0byB1cGRhdGUgdGhlIHNlY3Rpb24gcmVmZXJlbmNlcyBmcm9tIFJGQyA4MTUyIHRvIHRo ZSBiaXMgZG9jdW1lbnRzIGFsc28gb24gdGhpcyB0ZWxlY2hhdD8NCg0KTWlrZT4gSSBvbmx5IHBs YW4gdG8gdXBkYXRlIHRoZSByZWZlcmVuY2VzIG9mIHRoZSBiaXMgZG9jdW1lbnRzIGZpbmlzaCBm aXJzdC4NCg0KU2VjdGlvbiAyDQoNCkkgc2VlIHRoYXQgdGhlIElBTkEgcmVnaXN0cnkgY3VycmVu dGx5IGxpc3RzIFJTMjU2IGFzIFJlY29tbWVuZGVkOkRlcHJlY2F0ZWQsIGJ1dCB0aGlzIGRvY3Vt ZW50IGxpc3RzIGl0IGFzIFJlY29tbWVuZGVkOk5vLg0KV2hpY2ggaXMgY29ycmVjdD8NCg0KTWlr ZT4gR29vZCBjYXRjaC4gIEl0IHNob3VsZCBiZSAiTm8iLiAgSSdsbCBpbmZvcm0gSUFOQS4NCg0K U2VjdGlvbiAzLjENCg0KICAgcHJlc2VydmVkLiAgSWYgdGhlIHVuY29tcHJlc3NlZCByZXByZXNl bnRhdGlvbiBpcyB1c2VkLCB0aGUgInkiIHZhbHVlDQogICByZXByZXNlbnRlZCBNVVNUIGxpa2V3 aXNlIGJlIGV4YWN0bHkgMjU2IGJpdHMsIHdpdGggYW55IGxlYWRpbmcgemVyb3MNCiAgIHByZXNl cnZlZDsgaWYgdGhlIGNvbXByZXNzZWQgcmVwcmVzZW50YXRpb24gaXMgdXNlZCwgdGhlICJ5IiB2 YWx1ZQ0KICAgTVVTVCBiZSBhIGJvb2xlYW4gdmFsdWUsIGFzIHNwZWNpZmllZCBpbiBTZWN0aW9u IDEzLjEuMSBvZiBbUkZDODE1Ml0uDQoNCkF0IGxlYXN0IHRoZSAiTVVTVCBiZSBhIGJvb2xlYW4g dmFsdWUiIGlzIGZ1bGx5IHJlZHVuZGFudCB3aXRoIFJGQyA4MTUyLCBhbmQgbWlnaHQgbm90IG5l ZWQgbm9ybWF0aXZlIGxhbmd1YWdlLg0KDQpNaWtlPiBPSw0KDQpTZWN0aW9uIDMuMw0KDQogICBU aGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBob3cgdG8gdXNlIHRoZSBzZWNwMjU2azEgY3VydmUg Zm9yIEVDRFNBDQogICBzaWduYXR1cmVzIGZvciBib3RoIEpPU0UgYW5kIENPU0UgaW1wbGVtZW50 YXRpb25zLiAgV2hpbGUgaW4gdGhlb3J5LA0KICAgdGhlIGN1cnZlIGNvdWxkIGFsc28gYmUgdXNl ZCBmb3IgRUNESC1FUyBrZXkgYWdyZWVtZW50LCBpdCBpcyBiZXlvbmQNCiAgIHRoZSBzY29wZSBv ZiB0aGlzIHNwZWNpZmljYXRpb24gdG8gc3RhdGUgd2hldGhlciB0aGlzIGlzIG9yIGlzIG5vdA0K ICAgYWR2aXNhYmxlLiAgVGh1cywgd2hldGhlciB0byByZWNvbW1lbmQgaXRzIHVzZSB3aXRoIEVD REgtRVMgaXMgbGVmdA0KICAgZm9yIGV4cGVydHMgdG8gZGVjaWRlIGluIGZ1dHVyZSBzcGVjaWZp Y2F0aW9ucy4NCg0KVGhpcyB0ZXh0IGRvZXNuJ3QgcmVhbGx5IGRvIGEgZ3JlYXQgam9iIGF0IHJl ZmxlY3RpbmcgdGhlIHBvdGVudGlhbCBjb25jZXJucy9yaXNrcyBkZXNjcmliZWQgYXQgaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9jb3NlL2tTMjVrdlNIODVkY3l6WmkxbGNV Mi02eURFRS8NCi0tICJ0aGVyZSBtYXkgYmUgdGhlb3JldGljYWwgcHJvYmxlbXMgd2l0aCB0aGUg Y3VydmUiIHNlZW1zIHdvcnRoIG5vdGluZyENCg0KTWlrZT4gVGhhbmtzLCBJJ2xsIGFkZCB0aGlz Lg0KDQpTZWN0aW9uIDUuMg0KDQpJZiB3ZSdyZSBnb2luZyB0byBtZW50aW9uIGV4cG9uZW50IHJl c3RyaWN0aW9ucyBmcm9tIFNlY3Rpb24gOC4zIG9mIFJGQw0KNzUxOCBpbiBTZWN0aW9uIDUuMywg d2Ugc2hvdWxkIHByb2JhYmx5IG1lbnRpb24gdGhlbSBoZXJlIGFzIHdlbGwuDQoNCk1pa2U+IE9L DQoNClNlY3Rpb24gNS4zDQoNCiAgIE5ldyBDT1NFIGFwcGxpY2F0aW9ucyBNVVNUIE5PVCB1c2Ug dGhpcyBhbGdvcml0aG0uDQoNCklzIGl0IG5ldyBhcHBsaWNhdGlvbnMsIG9yIG5ldyBwcm90b2Nv bHMsIG9yIHNvbWV0aGluZyBlbHNlPw0KDQpNaWtlPiBJIGNhbiBzYXkgIk5ldyBDT1NFIGFwcGxp Y2F0aW9ucyBhbmQgcHJvdG9jb2xzIE1VU1QgTk9UIHVzZSB0aGlzIGFsZ29yaXRobS4iDQoNCk1p a2U+IFRoYW5rcyBhZ2FpbiBmb3IgdGhlIHRob3JvdWdoIHJldmlldyENCg0KCQkJCS0tIE1pa2UN Cg0KDQo= From nobody Fri Jun 12 20:12:16 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5585A3A077D; Fri, 12 Jun 2020 20:12:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-cose-webauthn-algorithms@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov , ivaylo@ackl.io X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159201792233.5234.6585379937681585593@ietfa.amsl.com> Date: Fri, 12 Jun 2020 20:12:02 -0700 Archived-At: Subject: [COSE] Benjamin Kaduk's No Objection on draft-ietf-cose-webauthn-algorithms-08: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 03:12:03 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-cose-webauthn-algorithms-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my review comments. I would prefer to go even further on the "more strongly reiterate the cross-algorithm risk" front, perhaps OLD: Care should be taken that a secp256k1 key is not mistaken for a P-256 [RFC7518] key, given that their representations are the same except for the "crv" value. As described in Section 8.1.1 of [RFC8152], we currently do not have any way to deal with this attack except to restrict the set of curves that can be used. NEW: Care should be taken that a secp256k1 key is not misinterpreted as a P-256 [RFC7518] key, given that their representations are the same except for the "crv" value. As described in Section 8.1.1 of [RFC8152], we currently do not have any way to deal with this attack except to restrict the set of curves that can be used. In general, any system that is willing to accept both "crv" values "secp256k1" and "P256" is vulnerable to this substitution attack, absent some external mechanism for integrity protecting the "crv" value used to interpret the key. From nobody Sun Jun 14 15:00:45 2020 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 0C7063A05DC; Sun, 14 Jun 2020 15:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 ckQCFsjjmyus; Sun, 14 Jun 2020 15:00:35 -0700 (PDT) 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 884B13A059F; Sun, 14 Jun 2020 15:00:34 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 14 Jun 2020 15:00:25 -0700 From: Jim Schaad To: 'Benjamin Kaduk' , 'The IESG' CC: , , , 'Matthew Miller' References: <159183984940.7642.3215375794743353401@ietfa.amsl.com> In-Reply-To: <159183984940.7642.3215375794743353401@ietfa.amsl.com> Date: Sun, 14 Jun 2020 15:00:23 -0700 Message-ID: <004c01d64297$360aa310$a21fe930$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLLhK51vaVhQCr2j2FaHM+f5QWv3qbsWB4Q Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2020 22:00:39 -0000 -----Original Message----- From: Benjamin Kaduk via Datatracker =20 Sent: Wednesday, June 10, 2020 6:44 PM To: The IESG Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org; cose-chairs@ietf.org; = cose@ietf.org; Matthew Miller ; = linuxwolf+ietf@outer-planes.net Subject: Benjamin Kaduk's Discuss on = draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-cose-rfc8152bis-struct-10: Discuss When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (Arguably a "discuss discuss".) If we don't have any worked examples of signatures with message = recovery, should we include that possibility in the Internet Standard = version of the protocol? Some of the description around how the details = of this would work remain unclear to me. [JLS] I tried a couple of times to get Kenny interested in seeing if = anybody in CFRG wanted to pursue this and never got anywhere. This text = is here as much to let people know that such an algorithm might be = defined in the future and it might cause some problems if it is. At one point I looked at looked at writing an experimental RFC which = would define a version of this with RSA. The padding algorithm would = look like that in PKCS #1.5 with the following change: PS =3D byte = count || stolen bytes || 0xff where byte count is the length of stolen = bytes and stolen bytes are the last n bytes of the signed message. = Where byte count is the minimum of the message length and (emLen - tLen = - 4). I ended up not doing this because I did not want it to escape = into the wild and I did not see any way of having people implement this = for testing and still making sure that it was contained. =20 One pointer is = https://crypto.stackexchange.com/questions/17802/description-of-signature= s-with-message-recovery-as-in-iso-iec-9796-2-and-emv-si ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (I support Roman's Discuss.) It's a little weird that we're Obsoletes:ing 8152 yet expect the expert = review procedures from it to remain in force. Perhaps we should copy = the expert review instructions to this document so that IANA is not = relying on an obsolete document? [JLS] There was some discussion about this in the WG that was pretty = inconclusive. Given that did not change I did not see this to be a big = issue but if the IESG wants to change this tell me. Do we need to check usage of "counter signature" with and without space? [JLS] I have a note in the XML to the RFC Editor about this point. I'd also like to discuss the question raised by Martin D. (on -algs) = relating to "AE" and "AEAD". Section 9.3 is quite clear that we = restrict content-encryption algorithms to those that support AAD, i.e., = AEAD mechanisms, so we only seem to use AE for the Key Wrap operations. Perhaps we should add a clarifying note in the terminology section about = what AE and AEAD are used for. [JLS] See response to Martin (still to be written) Section 1 Shouldn't we refer to RFC 8259 by its STD number (90)? [JLS] Makes sense structures. CBOR was designed specifically both to be small in terms of messages transported and implementation size and be a schema-free decoder. A need exists to provide message security services for IoT, nit: I think the second "be" should be "to be" as well. [JLS] Changed * The description of the structure for the CBOR objects which are transmitted over the wire. Two objects are defined for encryption, signing and message authentication. One object is That's two objects *each*, right? [JLS] Changed. * A starting set of attributes that apply to the different security objects. nit: the "starting set" wording feels a little out of place given that = the registry already exists and has stuff that we're not covering. [JLS] Removed starting providing security services. The use of COSE, like JOSE and CMS, is only in store and forward or offline protocols, different solutions would be appropriate for online protocols although one can use COSE in an online protocol after having done some type of online key establishment process. Any application which uses COSE for security be done before sending objects back and forth. [JLS] New text: The use of COSE, like JOSE and CMS, is only for use in store and = forward or offline protocols. The use of COSE in online protocols needing encryption, require = that an online key establishment process nit: comma splice (and the sentence after the comma is a bit long, too). additional data fields as part of the structure. A common structure is going to include a URI or other pointer to where the data that is being hashed is kept, allowing this to be application-specific. This is "common" in the sense of "a design pattern expected to be = frequently used", not "a common baseline", right? [JLS] Yes Section 1.3 * Define a single top message structure so that encrypted, signed, nit: "top-level"? [JLS] "overall"? * Signed messages distinguish between the protected and unprotected header parameters that relate to the content from those that relate to the signature. nit(?): shouldn't this be "distinguish between [x] and [y]", not = "between [x] from [y]"? [JLS] Changed, we will see what the copy editor says. Section 1.6 Authenticated Encryption (AE) [RFC5116] algorithms are those encryption algorithms that provide an authentication check of the contents algorithm with the encryption service. nit: this last "algorithm" seems spurious? [JLS] See message to Martin (to be written) context can come from several different sources including: Protocol interactions, associated key structures and program configuration. nit: serial comma, please. [JLS] Now Oxford comma style The context to use can be implicit, identified using the 'kid context' header parameter defined in [RFC8613], or identified by a Wouldn't the "kid context" be an *explicit* context, not implicit? [JLS] No it is still implicit. Consider the usage of a "kid context" in = OSCORE as a method of identifying what items should be placed into the = context structure. It changes over time and is not the kid itself. The = use of "kid context" as a name is not good, but I did not name it. protocol-specific identifier. Context should generally be included in the cryptographic configuration; for more details see Section 4.3. nit: "configuration" is not the first word I would have picked here (and = is not used in Section 4.3). Maybe "construction"? [JLS] Makes sense Section 2 1. The protected header parameters encoded and wrapped in a bstr. nit: I think this flows better with a comma after "parameters". [JLS] sure 3. The content of the message. The content is either the plaintext or the ciphertext as appropriate. The content may be detached (i.e. transported separately from the COSE structure), but the location is still used. The content is wrapped in a bstr when This is "location" in the sense of "the third element of the array", or = "the location in the array is still used"? [JLS] As in the third element of the array. layer. In the content layer, the plaintext is encrypted and information about the encrypted message is placed. In the recipient layer, the content encryption key (CEK) is encrypted and information about how it is encrypted for each recipient is placed. A single nit: ending the sentence with "is placed" feels rather Yoda-esque. [JLS] Your point being? Text is re-written to eliminate. 4. When a COSE object is carried as a CoAP payload, the CoAP Content-Format Option can be used to identify the message content. The CoAP Content-Format values can be found in Table 2. The CBOR tag for the message structure is not required as each security message is uniquely identified. Is it an error to include the tag? [JLS] No The following CDDL fragment identifies all of the top messages [hmm, maybe my earlier comment about "top-level message" was misguided] [JLS] see above comment. Section 3 or evaluation hints for the processing of the layer. These two buckets are available for use in all of the structures except for keys. While these buckets are present, they may not all be usable in all instances. For example, while the protected bucket is defined as nit: isn't "all buckets" just "both buckets"? [JLS] I probably meant to rite always though. h'a0'). The zero-length binary encoding is preferred because it is both shorter and the version used in the serialization structures for cryptographic computation. After encoding the map, nit: this doesn't look like a complete sentence. [JLS] The RFC editor did not object last time. Noun =3D encoding, verb = =3D preferred. structures for cryptographic computation. After encoding the map, the value is wrapped in the binary object. Recipients MUST accept This seems a bit redundant with earlier text (and shouldn't it be a = "byte string" anyway?). [JLS] Yes it is redundant - removed both a zero-length byte string and a zero-length map encoded in the binary value. ["binary value" vs. "binary string" vs. "byte string" again] [JLS] Yep - fixed decoded byte string.) This avoids the problem of all parties needing to be able to do a common canonical encoding. perhaps, "common canonical encoding for input to cryptographic = operations"? [JLS] A bit wordy - but ok reference to any other layer. With the exception of the COSE_Sign structure, the only data that needs to cross layers is the (I assume this includes COSE_Sign0 and the tagged versions, too?) [JLS] No it does not include COSE_Sign0 because it has only one layer, = but it does include the tagged version which is defined in terms of = COSE_Sign. Parameters" registry (Section 12.2). Some common header parameters are defined in the next section. [similar comment as above about "common"; maybe "The basic protocol = header parameters"?] [JLS] I don't like that wording, but have no problems eliminating = "common". malformed. Applications SHOULD verify that the same label does not occur in both the protected and unprotected header parameters. If the message is not rejected as malformed, attributes MUST be obtained from the protected bucket before they are obtained from the unprotected bucket. I a little bit worry that "take from protected before unprotected", = combined with "don't check for duplicates", means "last match wins" and = the unprotected one gets used. Perhaps it's better to talk about taking = precedence if both are present? [JLS] **** I don't understand your worry here. These are separate maps = and thus there is no "last match wins" between the two different = buckets. Section 3.1 alg: This header parameter is used to indicate the algorithm used for the security processing. This header parameter MUST be authenticated where the ability to do so exists. This support is provided by AEAD algorithms or construction (COSE_Sign, COSE_Sign1, COSE_Mac, and COSE_Mac0). This authentication can be Can countersignatures authenticate 'alg'? Is there an easy listing of the class of message that does *not* allow = for authenticating 'alg'? [JLS] Where to start, all of the constructions/algorithms have the = ability to do the authentication. The use of an AE algorithm does not = allow this. By construction, the encryption structures (Encrypt, = Encrypt0 and Recipient) do not do this, Changed to " (e.g. COSE_Sign = and COSE_Mac0)" COSE_Sign1, COSE_Mac, and COSE_Mac0). This authentication can be done either by placing the header parameter in the protected header parameter bucket or as part of the externally supplied data. The value is taken from the "COSE Algorithms" registry (see I don't think we've introduced "externally supplied data" yet, so a = forward reference might be in order. [JLS] Done * Integer labels in the range of 0 to 7 SHOULD be omitted. side note: I see that RFC 8152 has this as 0 to 8, and 8 is listed as = "unassigned" in the registry. Is there a story here? [JLS] Yes, I had originally assigned countersign0 to 8 and then messed = up. * Integer labels in the range -1 to -128 can be omitted as they are algorithm dependent. If an application can correctly process an algorithm, it can be assumed that it will correctly Where is this sub-partitioning of the -1 to -65536 range specified, that = any given algorithm will only assign "critical" header parameters in the -1 to -128 range? If it's just convention I don't think the declarative = language ("can be omitted") is appropriate. [JLS] There is no requirement that an algorithm is restricted to that = range. The assumption is that purely optional items might be placed = farther out in the range and thus need to be placed in the "crit" = attribute. This is just a restriction, similar to the 0-7 range of = things that can be omitted. * Labels for header parameters required for an application MAY be omitted. Applications should have a statement if the label can be omitted. nit: applications or application protocols? [JLS] I am pretty sure I meant applications. The message IV is generated by the following steps: 1. Left-pad the Partial IV with zeros to the length of IV. 2. XOR the padded Partial IV with the context IV. nit: this procedure does not indicate how "the length of IV" is known = (i.e., that it's a constant determined by the algorithm). [JLS] I don't think this is really necessary but "IV (determined by the = algorithm)" Section 4.1 authenticated by the signature, or just present. An example of header a parameter about the content is the content type header nit: s/header a/a header/ [JLS] Yep A COSE Signed Message is defined in two parts. The CBOR object that carries the body and information about the body is called the COSE_Sign structure. The CBOR object that carries the signature and (COSE_Sign also carries the signature parts?) [JLS] No - they are carried in COSE_Signature Note: When a signature with a message recovery algorithm is used (Section 9.1), the maximum number of bytes that can be recovered is the length of the payload. The size of the payload is reduced by the number of bytes that will be recovered. If all of the nit(?): it's the "size of the payload" *in the encoded COSE_Sign* object = that is reduced, right? [JLS] No it is the "size of the payload" as in the payload you signed. Section 4.3 proxy's cache. But the sender can cause a failure at the server if a proxy, or an attacker, changes the set of accept values by including the field in the application-supplied data. nit: "application-supplied data" reads pretty oddly to me, though given = what section this is in I guess it is not limited to just being = "additional authenticated data". Also, it seems like more a property of the protocol the sender is using = than the sole choice of the sender, to include or not include the set of = accept values in the externally supplied data. [JLS] No, it really is just externally supplied data - so changed to = that This document describes the process for using a byte array of externally supplied authenticated data; the method of constructing the byte array is a function of the application. Applications that Why is this a "byte array" and not a "byte string"? [JLS] This is dealing with a value passed in from the application and = does not refer to a CBOR encoded value. * If multiple items are included, applications need to ensure that the same byte string cannot be produced if there are different inputs. This would occur by appending the text strings 'AB' and 'CDE' or by appending the text strings 'ABC' and 'DE'. This is (I liked this better as "could occur" of RFC 8152. Also, is = concatenating" better than "appending", since we are posing the two = strings as peers, not subject and object?) Also, sometimes this property = is referred to as being an "injective mapping". [JLS] somebody asked for the change from could to would. I debated it = with them and then made the change. Going to concatenation makes sense. = I don't think that giving the property a name would really help Section 4.4 (I also had Roman's comment about the "CounterSignature" attributes in = field (1).) 3. The protected attributes from the signer structure encoded in a bstr type. If there are no protected attributes, a zero-length byte string is used. This field is omitted for the COSE_Sign1 signature structure and CounterSignature0 attributes. ("omitted" means "not present in the array at all", right?) [JLS] Yes 4. The protected attributes from the application encoded in a bstr type. If this field is not supplied, it defaults to a zero- Are these "protected attributes" the "externally supplied data" of = Section 4.3? We should probably use the same terminology to talk about = them... [JLS] Yes - fixed in all three spots Section 5 counter signatures use the structure COSE_Countersign. This is same structure as COSE_Signature and thus it can have protected attributes, chained counter signatures and information about identifying the key. Abbreviated counter signatures use the nit: "information about identifying the key" seems redundant. [JLS] Changed to " This is same structure as COSE_Signature and = thus it can have protected and unprotected attributes, including chained = counter signatures." specified. One result of this is that for COSE one can expand the concept of counter signatures beyond just the idea of signing a signature to being able to sign most of the structures without having to create a new signing layer. When creating a counter signature, nit: this seems somewhat redundant with the first paragraph of the = section ("this document extends to the concept of a counter signature to = allow [...]"). [JLS] Doesn't bother me - it falls out from the previous sentence Section 5.1 The COSE_Countersignature structure allows for the same set of capabilities of a COSE_Signature. This means that all of the nit: "same set of capabilities as" [JLS] Changed archiving services. More information on how this is used can be found in the evidence record syntax described in [RFC4998]. nit: I'm binding "this" to "COSE_Countersignature", which causes this = sentence to not make much sense. Perhaps "how this can be used" or "how = countersignatures signing countersignatures can be used" or "long-term = archiving services"? [JLS] This is a really weird reading on your part, but changed. COSE_CounterSignature_Tagged =3D #6.98(COSE_CounterSignature) note that 6.98 is incorrect; this is going to be the TBD value. [JLS] Cut and paste error - yes this is a TBD. Section 6.1 I think we need some forward-references to 6.3/6.4, here, since (e.g.) 6.2 is referencing back here to fill in the ciphertext. The COSE_recipient structure is a CBOR array. The fields of the array in order are: [...] ciphertext: This field contains the encrypted key encoded as a bstr. All encoded keys are symmetric keys; the binary value of the key is the content. If there is not an encrypted key, then this field is encoded as a nil value. I guess it's impossible to have protected headers with no encrypted key = (since you need a ciphertext for protected headers)? [JLS] Yes that is true COSE_recipient =3D [ Headers, ciphertext : bstr / nil, ? recipients : [+COSE_recipient] ] side note(?): I'm not sure I really understand when the recursive = COSE_recipient structure would be used at higher depths of recursion. [JLS] Did you take a look at Appendix B passwords: The CEK is encrypted in a KEK that is derived from a password. As of when this document was published, no password algorithms have been defined. If there aren't any, do we need to include it in the taxonomy? [JLS] It is only a matter of time. Personally I was waiting for Argon2 = get someplace before even trying to define one.=20 Section 6.3 It's slightly amusing that the "Enc_structure" is actually the AAD, not = anything encrypted :) [JLS] You are easily amused then. Section 6.4 1. Verify that the 'protected' field is empty. 2. Verify that there was no external additional authenticated data supplied for this operation. Presumably we fail the operation if either verification fails? [JLS] Yes that would be my expectation. Section 7.3 3. The protected attributes from the application encoded as a bstr type. If this field is not supplied, it defaults to a zero- [as above, using consistent terminology for "externally supplied data" would be useful.] [JLS] see above Section 8 A COSE Key structure is built on a CBOR map. The set of common parameters that can appear in a COSE Key can be found in the IANA "COSE Key Common Parameters" registry (Section 12.4). Additional parameters defined for specific key types can be found in the IANA "COSE Key Type Parameters" registry ([COSE.KeyParameters]). It's slightly jarring to have a section reference for one registry but = an external reference for the other. [JLS] It doesn't really bother me Section 8.1 cryptographic operation. Note that the same key can be in a different key structure with a different or no algorithm specified; however, this is considered to be a poor security practice. Depending on the answer to my question on -algs about capabilities and = their use, this statement might need to be updated. [JLS] Not clear which comment you are referring to kid: This parameter is used to give an identifier for a key. The identifier is not structured and can be anything from a user- provided byte string to a value computed on the public portion of the key. This field is intended for matching against a 'kid' parameter in a message in order to filter down the set of keys that need to be checked. I suggest reiterating that it is not in any way a unique identifier. [JLS] sure. Base IV: This parameter is defined to carry the base portion of an IV. It is designed to be used with the Partial IV header parameter defined in Section 3.1. This field provides the ability to associate a Partial IV with a key that is then modified on a Er, isn't it the Base IV associated with the key and the Partial IV = that's per-message? [JLS] Yup. If different keys are derived for each sender, using the same Base IV with Partial IVs starting at zero is likely to ensure that the IV would not be used twice for a single key. If different keys are derived for each sender, starting at the same Base IV is likely to satisfy this condition. If the same key is used for The two sentences that start with "if different keys" seem to have some = redundancy that could be eliminated. [JLS] Looks like I tried two different ways to same the same thing and = did not delete one of them. Section 9 to be exhaustive. New algorithms will be created which will not fit into this taxonomy. If this occurs, then new documents addressing this new algorithms are going to be needed. nit(?): this last sentence is written in a kind of colloquial style. [JLS] Doesn't really add anything - delete Section 9.1 There are two signature algorithm schemes. The first is signature nit: mybe "two types of" (and "scheme" singular)? [JLS] No, I think this is a correct usage. Section 9.2 Message Authentication Codes (MACs) provide data authentication and integrity protection. They provide either no or very limited data origination. A MAC, for example, cannot be used to prove the identity of the sender to a third party. Hmm, should the s/can/cannot/ be filed as an erratum against 8152? [JLS] Yes if we don't think we are going to have a fast publish. What = is the current RFC Editor queue processing time? Section 9.4 General KDFs work well with the first type of secret, can do reasonably well with the second type of secret, and generally do poorly with the last type of secret. Functions like PBES2 [RFC8018] need to be used for non-random secrets. nit: To be analogous to the previous discussion of KDFs, shouldn't we = refer to a PBKDF construction, not PBES (which provides an abstract API = for password-based encryption that uses PBKDF1 under the covers)? (Also, my understanding is that PBKDF1 is not exactly considered state-of-the-art.) [JLS] Given what I said above, if you really want to change this we = could point to Argon2 Section 9.5.1 * A header parameter identifying the shared secret SHOULD be present. What type of header parameter might do that? [JLS] Will KID would be one that could do this. Section 9.5.2 * The 'recipients' field is normally absent, but can be used. Applications MUST deal with a recipient field being present that has an unsupported algorithm, not being able to decrypt that recipient is an acceptable way of dealing with it. Failing to nit: comma splice [JLS] ok Section 9.5.3 When using a key transport algorithm, the COSE_Encrypt structure for the recipient is organized as follows: Does key transport use COSE_Encrypt or COSE_Recipient? [JLS] No, it uses COSE_Recipient. It used to use COSE_Encrypt until I = change the syntax slightly. Section 9.5.4 any dynamic key material. One side effect of this is that perfect forward secrecy (see [RFC4949]) is not achievable. A static key will Do we want to drop the "perfect"? [JLS] Yes. The COSE_Encrypt structure for the recipient is organized as follows: Is COSE_Encrypt or COSE_Recipient used for direct key agreement? [JLS] see above and others. Section 9.5.5 The COSE_Encrypt structure for the recipient is organized as follows: Is COSE_Encrypt or COSE_Recipient used for key agreement with key wrap? * A header parameter identifying the recipient's key SHOULD be present. A header parameter identifying the sender's key SHOULD be present. Is there anything to say about what header parameters those might be? [JLS] No, that would be more algorithm specific esp for the latter. Section 10 The document limits the restrictions it imposes on the CBOR Encoder needs to work. nit: missing word or two? -algs seems to say "restrictions it imposes = on how the CBOR Encoder needs to work". [JLS]=20 Section 11 * Applications need to determine the set of security algorithms that are to be used. When selecting the algorithms to be used as the mandatory-to-implement set, consideration should be given to choosing different types of algorithms when two are chosen for a specific purpose. An example of this would be choosing HMAC- Do we want to mention BCP 201 here? [JLS] I don't have an issue with this, I forgot such a beast had been = created. Section 12 Do we want to update the reference for the registries themselves (to = point to both 8152 and this) in addition to the reference for the = registered entries? [JLS] Unless we move the DE guidance, I don't see any reason to. Section 12.3 The COSE Header Algorithm Parameters Registry is = https://www.iana.org/assignments/cose/cose.xhtml#header-algorithm-paramet= ers , right? I don't see any of those being talked about in this document -- they're discussed in the KDF algorithms section in 8152. So = shouldn't this registry (and its entries) point to the algorithms doc, = not this one? [JLS] Yes they should Section 12.6 IANA added the following entries to the "CoAP Content-Formats" registry while processing [RFC8152]. IANA is requested to update the reference value from [RFC8152] to [[This Document]]. [no entries follow] [JLS] s/the following// Section 13 There are a number of security considerations that need to be taken into account by implementers of this specification. The security considerations that are specific to an individual algorithm are placed next to the description of the algorithm. While some [this stuff is in -algs, not -struct] [JLS] Deleted There are a large number of algorithms presented in [I-D.ietf-cose-rfc8152bis-algs] that use nonce values. Nonces generally have some type of restriction on their values. Generally a nonce needs to be a unique value either for a key or for some other conditions. In all of these cases, there is no known requirement on the nonce being both unique and unpredictable; under these circumstances, it's reasonable to use a counter for creation of the nonce. In cases where one wants the pattern of the nonce to be nit: this looks like a bad edit from the splitting off of the algorithms: "all of these cases" cannot bind to "specified in this = document" anymore, so we need to describe what we mean differently. [JLS] Might just as well delete the duplicated paragraph. gone One area that has been starting to get exposure is doing traffic analysis of encrypted messages based on the length of the message. I think this may have graduated from "starting" to be more of a = mainstream thing :) [JLS] Given that I had to explain this initially, it is nice to know it = has gone far more main stream. No longer starting. Section 14.1 side note: OpenSSL 1.0 (no minor version information given?)?! That = stuff's EOL! [JLS] I actually just updated the library in the last month to require = 1.1 in order to get support for EdDSA, however yes it did not really = what the minor version was because it was totally generic to that = version. I changed that to 1.1, but given that this goes away before = publishing I don't suppose it matters andy. Section 14.4 side note: what's curve24459? [JLS] You mean you don't recognize the really twisted curve of 25519 Section 15.1 [DSS] has only one usage now in -struct, which doesn't seem normative. I'd expect it to only be normative in -algs. Likewise for RFC 8032. [JLS] Done It's also interesting to make a normative reference to -algs, which will = be an informational RFC when published (given the current intended = status). Are we creating it directly onto the downrefs registry? [JLS] I could move the reference without any problems. However, putting = it directly in to the downref registry is probably a good idea so that = protocol documents can make algorithms MUST. Appendix A side note: it seems like any scheme for conveying information about what = algorithm to use other than "implicit by key with each key limited to = one algorithm" has some risk of allowing an attacker's input to cause = the key holder to perform some operation using that key but with the = "wrong" algorithm. I think that if the externally visible results of = that operation are indistinguishable from "the input was ignored", that = does not give the attacker a channel by which to attack the key, but I'm = not 100% sure. Even an application-layer "rejected due to bad input" might be enough of a lever to enable some types of attack. [JLS] The current CoRE group communication document is breaking the "one = key one algorithm" rule although in an offline way. At least for = OSCORE, there would not be a way to distinguish between any of the "it = did not decrypt" cases. =20 Appendix B All of the currently defined recipient algorithm classes only use two layers of the COSE_Encrypt structure. The first layer is the message COSE_Recipient? [JLS] That=E2=80=99s what I get for renaming things. Acknowledgments G=C3=B6ran could probably get his proper name, now. [JLS] I think he probably would as well. From nobody Sun Jun 14 15:10:01 2020 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 C5DAA3A060D; Sun, 14 Jun 2020 15:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 vDSjuNEsLws1; Sun, 14 Jun 2020 15:09:57 -0700 (PDT) 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 39AEE3A060A; Sun, 14 Jun 2020 15:09:57 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 14 Jun 2020 15:09:51 -0700 From: Jim Schaad To: 'Robert Wilton' , 'The IESG' CC: , , , 'Matthew Miller' References: <159181232597.18622.11559246666786395335@ietfa.amsl.com> In-Reply-To: <159181232597.18622.11559246666786395335@ietfa.amsl.com> Date: Sun, 14 Jun 2020 15:09:49 -0700 Message-ID: <004d01d64298$8733f600$959be200$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJKmNK03SJMtITmdfiBYva8mZ6HOqfv/aNg Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2020 22:09:59 -0000 -----Original Message----- From: Robert Wilton via Datatracker =20 Sent: Wednesday, June 10, 2020 11:05 AM To: The IESG Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org; cose-chairs@ietf.org; = cose@ietf.org; Matthew Miller ; = linuxwolf+ietf@outer-planes.net Subject: Robert Wilton's No Objection on = draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT) Robert Wilton has entered the following ballot position for draft-ietf-cose-rfc8152bis-struct-10: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I've only reviewed the diffs, not the historical approved text. = Everything looks okay to me. A few minor comments/nits: Comment: 1.4. CBOR Grammar The CDDL grammar is informational; the prose description is normative. I'm not familiar with the CDDL grammar, and specifically whether there = is any tooling that can use the grammar to generate structures/etc. If = there is, then I think that it would be helpful if the CDDL grammar was = also normative, in the sense that readers of the spec should be able to = assume that the CDDL is correct. I would still be okay with a statement = that says that if there is any ambiguity between the two then the prose = description should be taken as being definitive. [JLS] I am not aware of any tools today that can be used to generate = code form CDDL although I believe it is only a matter of time until they = exist. The current tools allow one to validate that a CBOR encoded = object does or does not match the CDDL. I have used these tools to do = validation, but since I have not used tools for generation I am not sure = what to do. It is my firm belief that the text and the CDDL are both = the same. The reason that the CDDL is not normative is not because of = this, but because I am not willing yet to have a normative dependency on = the CDDL document. Nits: 1.5. CBOR-Related Terminology The presence in a CBOR map of a label that is not a text string or an = integer is an error. This sentence was changed from the original formulation, but I find it = slightly clunky. Perhaps: The presence of a label, that is neither a text string nor an integer, = in a CBOR map, is an error. [JLS] done 9. Taxonomy of Algorithms used by COSE In this section, a taxonomy of the different algorithm types that can be used in COSE is laid out. This taxonomy should not be considered to be exhaustive. New algorithms will be created which will not fit into this taxonomy. If this occurs, then new documents addressing this new algorithms are going to be needed. Nit, this -> these [JLS] I just deleted the sentence for Ben so this is moot. Regards, Rob From nobody Mon Jun 15 02:11:12 2020 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 CC6653A0B01; Mon, 15 Jun 2020 02:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=byrqXVAN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TYRqVlGT 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 nE9AaYwTl-hn; Mon, 15 Jun 2020 02:11:08 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C111E3A0AFF; Mon, 15 Jun 2020 02:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5272; q=dns/txt; s=iport; t=1592212267; x=1593421867; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aUn7QrC5KMebNgOba6MzVhfYUvpOGnXtYaUUc276La4=; b=byrqXVANwbjrLk3/WG6krPDnpn0IWf731UyW63p/Bol/x9/e6lcj551v BxLNFLI9ipmntoWM/GJx/yvIFh3sI7ZFd4LFm0ZWwZtTILquCIpzczWj5 khHgoPpo20Zq385iJIlfM/4P64rjes7drkX1iej/QW5vRYqMZYE4TEkLY I=; X-IPAS-Result: =?us-ascii?q?A0C2BQAXOude/5pdJa1mHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?UqBUlEHb1gvLAqEGoNGA409mFKBQoEQA1ULAQEBDAEBIwoCBAEBhEQCF4IYA?= =?us-ascii?q?iQ4EwIDAQEBAwIDAQEBAQUBAQECAQYEbYVbDIVyAQEBAQMSEREMAQE3AQsEA?= =?us-ascii?q?gEIDgMEAQEDAiYCAgIwFQgIAgQBDQUIGoMFgksDLgEDC6hrAoE5iGF2gTKDA?= =?us-ascii?q?QEBBYFGQYMrGIIOAwaBDiqCZIlmGoFBP4ERQ4JNPoJcAgECAYEmARIBIxWCf?= =?us-ascii?q?TOCLY8TMIJgoh4KglmIPIt8hQOCcIkakl2RF4oKlCMCBAIEBQIOAQEFgWoiZ?= =?us-ascii?q?lgRB3AVgyRQFwINjh43gzqFFIVCdAI1AgYIAQEDCXyOBS2BBgGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3Am0lRghfmIDDQ7m3Dp6yDWFZTlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaSB9fS9v1ZkPbdvqTkUHYbp52GtSNKfJ9NUk?= =?us-ascii?q?oDjsMb10wlDdWeAEL2ZPjtc2QhHctEWVMkmhPzMUVcFMvkIVGHpHq04G0bBx?= =?us-ascii?q?riLhZ+K+DxE5TJyc+w0rP695jaeQ4dgj27bPt7Jwm3qgOEsM4QjO4AYqY8wx?= =?us-ascii?q?fEuD1GYeNTkGhpPlmU2R3745S9?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.73,514,1583193600"; d="scan'208";a="485953397" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jun 2020 09:11:06 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 05F9B2af023305 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Jun 2020 09:11:05 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Jun 2020 04:11:02 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Jun 2020 04:11:01 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 15 Jun 2020 04:11:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dlqZInbyOOkD44t8VvypZevebC/lv0d5PqM2WWfSXtZuiEjuJsxFnjRn+7e5SrgF1WTCrsj2lgdmLjvXfc1HPIwc3mhVdKw4tOhT4AAv1siZXCRfP7+tBo0Uc5G8HMh/fPBLtAi7JlX4zrRtrd44tT+h1b9AeN+cZXd65M3vrqJ7YWbweGl74MktbG/m0S7SGnGJd321snRdbjLsBCCrlVMsbJ9J/9wp/M7YfZmt8Q/Q/BqtpF7cf8vgTqYmsNDF96nlmNo0FXLrG2pgn6lfzJRe1hgGbCVUGAiPzrH67/bcyeUgXrA9d6l3yxPqU3cCyO4He05U7jiVKclf0yfJew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aUn7QrC5KMebNgOba6MzVhfYUvpOGnXtYaUUc276La4=; b=EOJlyaCnUJM5gm0jNMOsTZZSju7gY8oBwbLSQABw8rDvDz66YSHyrEWtmdlHra/gfZDSruhHOyYasvElLYx4y337XTT8FsQsEHmOtCx9Ak0bE9lFABoms2aMknuOBn5DyYvhcHQJDqGVSGrhbKtzFWBuN+eQLAPDbR3G5fT0H5tk56oljid+lgaXNJflQjaWzQNGBKTVQTP6HRYtXPpYxikzuTNSmXx0nscnpeC25lrMQGHHBE4BThJ5aVPQ1QwgYkl0JH+wBqfYIryS1RJY/9g5BisU34EMCGrUQLwCr+vijPzrOyaX4VCqgEtMEKhVGn34KwkTyHkhDrjVsrrh4w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aUn7QrC5KMebNgOba6MzVhfYUvpOGnXtYaUUc276La4=; b=TYRqVlGThvtgsx6ocdStxcm0XhvL1RlkbAY27IpEUWNrZRMKDKsJklRyUqf3gEZPPxNuOq/uND92zbom2W7K0rJgImGJryb2k7j20LELdYG9GKQ8gNnD6tSP/XqoNTaoqtwOcgsJ5zKajsZ1oyEDXILT3F6MMKgwMPTvQ7SyNjY= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4567.namprd11.prod.outlook.com (2603:10b6:208:26d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.24; Mon, 15 Jun 2020 09:11:00 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18%5]) with mapi id 15.20.3088.028; Mon, 15 Jun 2020 09:11:00 +0000 From: "Rob Wilton (rwilton)" To: Jim Schaad , "'The IESG'" CC: "draft-ietf-cose-rfc8152bis-struct@ietf.org" , "cose-chairs@ietf.org" , "cose@ietf.org" , "'Matthew Miller'" , Benjamin Kaduk Thread-Topic: Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT) Thread-Index: AQHWP1HE5u+CqgjwV0aTTCudvijR6ajYsmaAgAC0DvA= Date: Mon, 15 Jun 2020 09:11:00 +0000 Message-ID: References: <159181232597.18622.11559246666786395335@ietfa.amsl.com> <004d01d64298$8733f600$959be200$@augustcellars.com> In-Reply-To: <004d01d64298$8733f600$959be200$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.15.79.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5663a6e6-b72b-45ed-3fb1-08d8110c05bf x-ms-traffictypediagnostic: MN2PR11MB4567: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: R9pThXoybiifG4xir+/48T48VSV0H6hWCwf3uaA0Dg/HwiKT0869qLciRtiwBG5o3xXZG6XkNg3CRp3+xU9lQG6sOf+Pgqv4fztecvjpM9H3sDipYAOKjskYH51leOBbtWz2UQYyeV+A2QU/yIual1UG8fCPqHv5BZkdltquwbPTpmF2RYm9ox4L9Dxu4Ai8DwIpJ5A6mCU0R9OnrdOBUVV2cKfyORDGtdQDmLQRZNyWk+dQMbvfH2kuh3bgycoZHHNu3M8YJuTxpJVjRYX5lz5GVVM0c4m3e10GNAmf7oKLVmRxFh8GnZ5SbwKXTJoakqTydESaPB867sBCd7j+5MBIREYnGqH66/KRlivlsrXgAANJ/3ew0TUyaH9ZXF06m7MgiB7QxLUYoXBQK6EjVA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(136003)(376002)(346002)(396003)(186003)(26005)(4326008)(6506007)(8676002)(8936002)(53546011)(7696005)(2906002)(71200400001)(55016002)(5660300002)(478600001)(9686003)(66446008)(52536014)(83380400001)(316002)(33656002)(76116006)(66476007)(86362001)(110136005)(54906003)(66946007)(64756008)(66556008)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: VHmPJZeDjiETd4unsdRC+XemgXIAitG96Zpv/QkgtVGkeNcGYF9ZJ8uej5rtCMrqoqes4H4I1ow1dIdQ35BBaLf2lJmHi+D1mAwZhfj7BcheC2e/rGxQuKLMJicXWHPK7WoZrEYmBqNTYElQ0gdoeL2H6S1wd038i4+VRD2fy3GmZSe9oEWgfl5Sxu2j7TnPe240ZTAz9kKqNWBEh9urWG6gQhW4/SfDe1B0rlK/s4GUZiOUvlEUVHB0Bcwjupj5VUCgwgurrDZ3LnRfmYvM2VxIv2lCT4GV6qmsEUUK9qpAaAZ6OSmCW0B/Vt4kf23Mfuh1d8gYynuUmFVtCDtggep7e0PtzblUEsyNKNJ1j++LwRLATjUMaP5WYn3EZ6VhKOHZxqxdhS9OBpojb2co8QayIThK7/QZGTH7ptNoRkpKEoZxS0xuBGRu+w73PIHtuZXtm19zbJRLf/bVnyTmC2+F8JFPjIwo6J6MPuO/YCU= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5663a6e6-b72b-45ed-3fb1-08d8110c05bf X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 09:11:00.3876 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WK/OZ/fWRksZc3zxS8vNJfduxN4cvtlmPXBCCCcHWNiwTGXCW9dYJGNjAA1DBtfwR18iKKFJKW9Z84gnVGjgjQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4567 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [COSE] Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 09:11:10 -0000 SGkgSmltLA0KDQpQbGVhc2Ugc2VlIGlubGluZSAuLi4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPg0KPiBT ZW50OiAxNCBKdW5lIDIwMjAgMjM6MTANCj4gVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2ls dG9uQGNpc2NvLmNvbT47ICdUaGUgSUVTRycgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1p ZXRmLWNvc2UtcmZjODE1MmJpcy1zdHJ1Y3RAaWV0Zi5vcmc7IGNvc2UtY2hhaXJzQGlldGYub3Jn Ow0KPiBjb3NlQGlldGYub3JnOyAnTWF0dGhldyBNaWxsZXInIDxsaW51eHdvbGYraWV0ZkBvdXRl ci1wbGFuZXMubmV0Pg0KPiBTdWJqZWN0OiBSRTogUm9iZXJ0IFdpbHRvbidzIE5vIE9iamVjdGlv biBvbiBkcmFmdC1pZXRmLWNvc2UtcmZjODE1MmJpcy0NCj4gc3RydWN0LTEwOiAod2l0aCBDT01N RU5UKQ0KPiANCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBS b2JlcnQgV2lsdG9uIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4NCj4gU2VudDog V2VkbmVzZGF5LCBKdW5lIDEwLCAyMDIwIDExOjA1IEFNDQo+IFRvOiBUaGUgSUVTRyA8aWVzZ0Bp ZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlzLXN0cnVjdEBpZXRmLm9y ZzsgY29zZS1jaGFpcnNAaWV0Zi5vcmc7DQo+IGNvc2VAaWV0Zi5vcmc7IE1hdHRoZXcgTWlsbGVy IDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0PjsNCj4gbGludXh3b2xmK2lldGZAb3V0 ZXItcGxhbmVzLm5ldA0KPiBTdWJqZWN0OiBSb2JlcnQgV2lsdG9uJ3MgTm8gT2JqZWN0aW9uIG9u IGRyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlzLQ0KPiBzdHJ1Y3QtMTA6ICh3aXRoIENPTU1FTlQp DQo+IA0KPiBSb2JlcnQgV2lsdG9uIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv c2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWNvc2UtcmZjODE1MmJpcy1zdHJ1Y3QtMTA6IE5vIE9i amVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBs aW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBp biB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+IGludHJvZHVj dG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRw czovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4g Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0 aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBv c2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlzLXN0cnVjdC8NCj4gDQo+IA0KPiANCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBJJ3ZlIG9u bHkgcmV2aWV3ZWQgdGhlIGRpZmZzLCBub3QgdGhlIGhpc3RvcmljYWwgYXBwcm92ZWQgdGV4dC4N Cj4gRXZlcnl0aGluZyBsb29rcyBva2F5IHRvIG1lLiAgQSBmZXcgbWlub3IgY29tbWVudHMvbml0 czoNCj4gDQo+IENvbW1lbnQ6DQo+IA0KPiAxLjQuICBDQk9SIEdyYW1tYXINCj4gDQo+ICAgVGhl IENEREwgZ3JhbW1hciBpcyBpbmZvcm1hdGlvbmFsOyB0aGUgcHJvc2UgZGVzY3JpcHRpb24gaXMg bm9ybWF0aXZlLg0KPiANCj4gSSdtIG5vdCBmYW1pbGlhciB3aXRoIHRoZSBDRERMIGdyYW1tYXIs IGFuZCBzcGVjaWZpY2FsbHkgd2hldGhlciB0aGVyZSBpcw0KPiBhbnkgdG9vbGluZyB0aGF0IGNh biB1c2UgdGhlIGdyYW1tYXIgdG8gZ2VuZXJhdGUgc3RydWN0dXJlcy9ldGMuICBJZiB0aGVyZQ0K PiBpcywgdGhlbiBJIHRoaW5rIHRoYXQgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB0aGUgQ0RETCBn cmFtbWFyIHdhcyBhbHNvDQo+IG5vcm1hdGl2ZSwgaW4gdGhlIHNlbnNlIHRoYXQgcmVhZGVycyBv ZiB0aGUgc3BlYyBzaG91bGQgYmUgYWJsZSB0byBhc3N1bWUNCj4gdGhhdCB0aGUgQ0RETCBpcyBj b3JyZWN0LiAgSSB3b3VsZCBzdGlsbCBiZSBva2F5IHdpdGggYSBzdGF0ZW1lbnQgdGhhdA0KPiBz YXlzIHRoYXQgaWYgdGhlcmUgaXMgYW55IGFtYmlndWl0eSBiZXR3ZWVuIHRoZSB0d28gdGhlbiB0 aGUgcHJvc2UNCj4gZGVzY3JpcHRpb24gc2hvdWxkIGJlIHRha2VuIGFzIGJlaW5nIGRlZmluaXRp dmUuDQo+IFtKTFNdIEkgYW0gbm90IGF3YXJlIG9mIGFueSB0b29scyB0b2RheSB0aGF0IGNhbiBi ZSB1c2VkIHRvIGdlbmVyYXRlIGNvZGUNCj4gZm9ybSBDRERMIGFsdGhvdWdoIEkgYmVsaWV2ZSBp dCBpcyBvbmx5IGEgbWF0dGVyIG9mIHRpbWUgdW50aWwgdGhleSBleGlzdC4NCj4gVGhlIGN1cnJl bnQgdG9vbHMgYWxsb3cgb25lIHRvIHZhbGlkYXRlIHRoYXQgYSBDQk9SIGVuY29kZWQgb2JqZWN0 IGRvZXMgb3INCj4gZG9lcyBub3QgbWF0Y2ggdGhlIENEREwuICBJIGhhdmUgdXNlZCB0aGVzZSB0 b29scyB0byBkbyB2YWxpZGF0aW9uLCBidXQNCj4gc2luY2UgSSBoYXZlIG5vdCB1c2VkIHRvb2xz IGZvciBnZW5lcmF0aW9uIEkgYW0gbm90IHN1cmUgd2hhdCB0byBkby4gIEl0DQo+IGlzIG15IGZp cm0gYmVsaWVmIHRoYXQgdGhlIHRleHQgYW5kIHRoZSBDRERMIGFyZSBib3RoIHRoZSBzYW1lLiAg VGhlDQo+IHJlYXNvbiB0aGF0IHRoZSBDRERMIGlzIG5vdCBub3JtYXRpdmUgaXMgbm90IGJlY2F1 c2Ugb2YgdGhpcywgYnV0IGJlY2F1c2UNCj4gSSBhbSBub3Qgd2lsbGluZyB5ZXQgdG8gaGF2ZSBh IG5vcm1hdGl2ZSBkZXBlbmRlbmN5IG9uIHRoZSBDRERMIGRvY3VtZW50Lg0KW1JXXSANCg0KWW91 IG5lZWQgYSBub3JtYXRpdmUgcmVmZXJlbmNlIG9uIHRoZSBDRERMIGRvY3VtZW50IHJlZ2FyZGxl c3MsIGdpdmVuIHRoYXQgaXQgaXMgbm90IHBvc3NpYmxlIHRvIHVuZGVyc3RhbmQgdGhlIGVudGly ZXR5IG9mIGRyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlzLXN0cnVjdCB3aXRob3V0IHJlYWRpbmcg dGhlIENEREwgZHJhZnQsIGhlbmNlIGl0IGlzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZS4gIFRoZSBv bmx5IGFsdGVybmF0aXZlIHdvdWxkIGJlIHRvIHN0cmlwIGFsbCB0aGUgQ0RETCB0ZXh0IG91dCBv ZiB0aGUgZG9jdW1lbnQsIGFuZCBJIHJlYWxseSBkb3VidCB0aGF0IHlvdSB3b3VsZCB3YW50IHRv IGRvIHRoYXQuDQoNCkV2ZW4gaWYgdG9vbHMgYXJlIGp1c3QgYmVpbmcgdXNlZCBmb3IgdmFsaWRh dGlvbiB0aGVuIHlvdSBzdGlsbCByZXF1aXJlIHRoZSBDRERMIHRvIGJlIHJpZ2h0IG9yIG90aGVy d2lzZSB0aGUgdmFsaWRhdGlvbiBjb3VsZCBnaXZlIGFuIGluY29ycmVjdCByZXNwb25zZS4NCg0K SGVuY2UsIEkgd291bGQgcmVjb21tZW5kIHRoYXQgeW91IGJpdGUgdGhlIGJ1bGxldCwgYWRkIHRo ZSBub3JtYXRpdmUgcmVmZXJlbmNlLCBhbmQgbWFrZSB0aGUgQ0RETCB0ZXh0IG5vcm1hdGl2ZS4g IEdpdmVuIHRoYXQgQ0RETCBoYXMgYWxyZWFkeSBiZWVuIHB1Ymxpc2hlZCBhcyBhbiBSRkMsIEkn bSB1bnN1cmUgd2h5IGhhdmluZyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gaXQgd291bGQgYmUg YSBwcm9ibGVtLg0KDQpSZWdhcmRzLA0KUm9iDQoNCg== From nobody Mon Jun 15 09:47:39 2020 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 55EA43A0E9B; Mon, 15 Jun 2020 09:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 7YeLlMJ7shcn; Mon, 15 Jun 2020 09:47:31 -0700 (PDT) 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 0F7A63A0E8F; Mon, 15 Jun 2020 09:47:30 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Jun 2020 09:47:05 -0700 From: Jim Schaad To: "'Rob Wilton (rwilton)'" , 'The IESG' CC: , , , 'Matthew Miller' , 'Benjamin Kaduk' References: <159181232597.18622.11559246666786395335@ietfa.amsl.com> <004d01d64298$8733f600$959be200$@augustcellars.com> In-Reply-To: Date: Mon, 15 Jun 2020 09:47:02 -0700 Message-ID: <008401d64334$9ad6ff30$d084fd90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJKmNK03SJMtITmdfiBYva8mZ6HOgHP3IyjAcy9U+2n1FInYA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 16:47:33 -0000 -----Original Message----- From: Rob Wilton (rwilton) =20 Sent: Monday, June 15, 2020 2:11 AM To: Jim Schaad ; 'The IESG' Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org; cose-chairs@ietf.org; = cose@ietf.org; 'Matthew Miller' ; = Benjamin Kaduk Subject: RE: Robert Wilton's No Objection on = draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT) Hi Jim, Please see inline ... > -----Original Message----- > From: Jim Schaad > Sent: 14 June 2020 23:10 > To: Rob Wilton (rwilton) ; 'The IESG'=20 > > Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org; cose-chairs@ietf.org;=20 > cose@ietf.org; 'Matthew Miller' > Subject: RE: Robert Wilton's No Objection on=20 > draft-ietf-cose-rfc8152bis- > struct-10: (with COMMENT) >=20 >=20 >=20 > -----Original Message----- > From: Robert Wilton via Datatracker > Sent: Wednesday, June 10, 2020 11:05 AM > To: The IESG > Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org; cose-chairs@ietf.org;=20 > cose@ietf.org; Matthew Miller ; > linuxwolf+ietf@outer-planes.net > Subject: Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis- > struct-10: (with COMMENT) >=20 > Robert Wilton has entered the following ballot position for > draft-ietf-cose-rfc8152bis-struct-10: No Objection >=20 > When responding, please keep the subject line intact and reply to all=20 > email addresses included in the To and CC lines. (Feel free to cut=20 > this introductory paragraph, however.) >=20 >=20 > Please refer to=20 > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I've only reviewed the diffs, not the historical approved text. > Everything looks okay to me. A few minor comments/nits: >=20 > Comment: >=20 > 1.4. CBOR Grammar >=20 > The CDDL grammar is informational; the prose description is = normative. >=20 > I'm not familiar with the CDDL grammar, and specifically whether there = > is any tooling that can use the grammar to generate structures/etc. =20 > If there is, then I think that it would be helpful if the CDDL grammar = > was also normative, in the sense that readers of the spec should be=20 > able to assume that the CDDL is correct. I would still be okay with a = > statement that says that if there is any ambiguity between the two=20 > then the prose description should be taken as being definitive. > [JLS] I am not aware of any tools today that can be used to generate=20 > code form CDDL although I believe it is only a matter of time until = they exist. > The current tools allow one to validate that a CBOR encoded object=20 > does or does not match the CDDL. I have used these tools to do=20 > validation, but since I have not used tools for generation I am not=20 > sure what to do. It is my firm belief that the text and the CDDL are=20 > both the same. The reason that the CDDL is not normative is not=20 > because of this, but because I am not willing yet to have a normative = dependency on the CDDL document. [RW]=20 You need a normative reference on the CDDL document regardless, given = that it is not possible to understand the entirety of = draft-ietf-cose-rfc8152bis-struct without reading the CDDL draft, hence = it is a normative reference. The only alternative would be to strip all = the CDDL text out of the document, and I really doubt that you would = want to do that. Even if tools are just being used for validation then you still require = the CDDL to be right or otherwise the validation could give an incorrect = response. Hence, I would recommend that you bite the bullet, add the normative = reference, and make the CDDL text normative. Given that CDDL has = already been published as an RFC, I'm unsure why having a normative = reference to it would be a problem. [JLS] Section 1.4 is designed to avoid the need for CDDL to be = normative. Also since the CDDL is explicitly normative I do not believe = that it needs to be normative. I am still under the impression that one needs to look very closely at = STD downrefs as well as Standards Track downrefs is that not true? Jim Regards, Rob From nobody Mon Jun 15 10:11:25 2020 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 A37623A02C1; Mon, 15 Jun 2020 10:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 HRtoSoqF9lnn; Mon, 15 Jun 2020 10:11:22 -0700 (PDT) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) (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 8DD4F3A00E0; Mon, 15 Jun 2020 10:11:22 -0700 (PDT) Received: by mail-io1-f66.google.com with SMTP id x189so9646997iof.9; Mon, 15 Jun 2020 10:11:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AwHDa/NxGR2VoOmOfG+TusPMrERJ1H0UfX0AoxXTIas=; b=dMBWZYm92H7TJEeT4ITAqNrnHr+nuZf5AMOGphbM+Mks+Nw2K5f2KIDKpfQYPx3Zo9 +nl8EnlUHXPFKbu0MOAOlyACvBavJYVqjebpWRSNWHTX9Zbvr24YGS7H5sYGCpvSfqAJ Iv31cQUl20d/10RuC4FOJQvGXIHTB4s/NL6JS8vWJAPwMrVsPv0X4rAxiC1y8KzNSjNV ujO3lN3gbkoZxFkKkl8Qy67Vj+UShcULxA/ynjdytO0BwVl7mbZ4fELo3ElaI/r78kHt raxy9TEyc7zvC0b7TcganNkn8UVyNa+ARn+f9xrXvZfGpFdVEAVZrzrw7TWdPJgHyWcR nCig== X-Gm-Message-State: AOAM530KUGztmVFWBbAZrkGvP+gZkFAKKk3pSgph6s8+S0CAMQM6dfFh xhXAKgXmrfleW9LwcfOpbiOW/gtKIP9Jb6JVRBg= X-Google-Smtp-Source: ABdhPJwbK8VzFlVvoeG0xSjGkUkbde7p2QRqRTHzOFbGyGaixCY/nldhEQxIRxlpaQB4mO98OBut8mbO7q4nA5CWQ94= X-Received: by 2002:a02:ca18:: with SMTP id i24mr22437897jak.70.1592241081708; Mon, 15 Jun 2020 10:11:21 -0700 (PDT) MIME-Version: 1.0 References: <159181232597.18622.11559246666786395335@ietfa.amsl.com> <004d01d64298$8733f600$959be200$@augustcellars.com> <008401d64334$9ad6ff30$d084fd90$@augustcellars.com> In-Reply-To: <008401d64334$9ad6ff30$d084fd90$@augustcellars.com> From: Barry Leiba Date: Mon, 15 Jun 2020 13:11:08 -0400 Message-ID: To: Jim Schaad Cc: "Rob Wilton (rwilton)" , The IESG , draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, Matthew Miller , Benjamin Kaduk , cose@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [COSE] Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 17:11:24 -0000 >> You need a normative reference on the CDDL document regardless, given >> that it is not possible to understand the entirety of >> draft-ietf-cose-rfc8152bis-struct without reading the CDDL draft, >> hence it is a normative reference. The only alternative would be to >> strip all the CDDL text out of the document, and I really doubt that >> you would want to do that. >> >> Even if tools are just being used for validation then you still >> require the CDDL to be right or otherwise the validation could give an >> incorrect response. >> >> Hence, I would recommend that you bite the bullet, add the normative >> reference, and make the CDDL text normative. Given that CDDL has >> already been published as an RFC, I'm unsure why having a normative >> reference to it would be a problem. > > [JLS] Section 1.4 is designed to avoid the need for CDDL to be > normative. Also since the CDDL is explicitly normative I do not > believe that it needs to be normative. I can't figure this out, Jim. Is there a "not" missing, or some such? In any case, I agree that the CDDL reference can be informative. 8152 predated the CDDL spec and was understandable with only an informative reference to it, and I don't think 8152bis has changed in that regard. > I am still under the impression that one needs to look very closely at > STD downrefs as well as Standards Track downrefs is that not true? An Internet Standard that cites a Proposed Standard normatively is making a downref, if that's what you're asking. That said, it's not a big problem to accept that -- we would just have to run another two-week last call to approve the downref. But, as I said above, I don't think that's necessary. Rob, can you give specific examples of things in 8152bis that can't be properly understood without normative reference to RFC 8610? Barry From nobody Mon Jun 15 10:22:45 2020 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 835D33A0490; Mon, 15 Jun 2020 10:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 B6U-nTiyVVrE; Mon, 15 Jun 2020 10:22:37 -0700 (PDT) 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 A46923A0484; Mon, 15 Jun 2020 10:22:36 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Jun 2020 10:22:29 -0700 From: Jim Schaad To: 'Alvaro Retana' , 'The IESG' CC: , , , 'Matthew Miller' References: <159172966432.25988.15915230396771082634@ietfa.amsl.com> In-Reply-To: <159172966432.25988.15915230396771082634@ietfa.amsl.com> Date: Mon, 15 Jun 2020 10:22:27 -0700 Message-ID: <008701d64339$8d039f30$a70add90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIQ98zNwj+Uvsjtt7p1G4xurVNxKKhbeKgA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Alvaro Retana's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 17:22:40 -0000 -----Original Message----- From: Alvaro Retana via Datatracker =20 Sent: Tuesday, June 9, 2020 12:08 PM To: The IESG Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; = cose@ietf.org; Matthew Miller Subject: Alvaro Retana's No Objection on = draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) Alvaro Retana has entered the following ballot position for draft-ietf-cose-rfc8152bis-algs-09: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) I am concerned -- confused may be a better word -- about the status = of this document for several reasons: (a) The header on this document still says that it is intended to remain = in the Standards Track -- but the datatracker says that is should be Informational. This is simply a nit. [JLS] This was an error in the file and has been fixed. (b) Except for a note when the publication was requested [1], I didn't = find any other discussion in the mail archive. Was the status discussed = in the WG? The Shepherd writeup [2] does say that the status "marks the state = of consensus at the time of publication, and allows for the flexibility = to deprecate and obsolete in the future." Except for potentially a = higher bar when updating an Internet Standard, the process is the same... (c) The fact that this document resulted from the split of rfc8152 = confuses me even more: the "other half" (rfc8152bis-struct) is moving on as = an Internet Standard and it includes a Normative reference to this = document. Note that the Normative reference makes sense, but the Informational status of this document doesn't...at least to me. Even though we = can use DownRefs, it seems unnecessary to "downgrade" this part of the document and end up with a downref to an Informational document... This is a non-blocking comment...I simply don't understand. [JLS] This comes from a number of different sources: * Pure personal opinion, I do not believe that one should be creating = proposed standards if there is absolutely no intention to try and keep = the document on track to some day make it a full standard. This is = something that I generally do with my own documents and do not ever = attempt to push it on others. * Historically when deal with the CMS algorithm documents, these have = normally been information rather than standard track documents. While = there is a difference between the algorithms which describe how to = implement the algorithm and how to use the algorithm with the first = always being informational and the second frequently being = informational, this is a trend that I have normally tried to follow. * I have an expectation that over time cryptographic algorithms will be = broken. My personal hope is that all standards track documents do not = live in the world of this might become obsolete. I would note that we = have not do any type of pass over documents such as RFC 3058 or RFC 3657 = which at this time would no longer be considered to be state of the art = and thus not be used but have never been marked as obsolete or some = similar tagging. [1] = https://mailarchive.ietf.org/arch/msg/cose/tVDVZtfBhfYsKiqT0kCtkGoL_2U/ [2] https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/shepherd= writeup/ (2) =C2=A710.1/=C2=A710.2: The references should be changed from rfc8152 = to this document. [JLS] Done (3) =C2=A710.2 (Changes to "COSE Algorithms" registry) IANA is requested to create a new column in the "COSE Algorithms" registry. The new column is to be labeled "Capabilities". The new column is populated with "[kty]" for all current, non-provisional, registrations. It is expected that the documents which define those algorithms will be expanded to include this registration, if this is not done then the DE should be consulted before final registration for this document is done. I am not sure what is the expectation here; a new column is added and = all the entries are populated with "[kty]" -- so far so good. What I = don't understand is the part about other "documents...will be expanded = to include this registration". Does that mean that the other documents = need to be updated?=20 What should the DE do if the work is not completed? I am even more = confused because this document doesn't seem to take an action related to = that new column for the algorithms defined here, and the new row (in = this same section) doesn't include the Capabilities column. [JLS] There is a race condition that is going on at the moment and this = is weasel language to make sure that I can solve any problems that crop = up. There are algorithms drafts such as the WebAuthn algorithm document = and another one that I know of that is coming out of the lwig WG and one = that was in the RFC Editor queue which as sense been cleaned up that did = not define this field and would need to get it defined somehow. (4) =C2=A710.2: "Note to IANA: There is an action in = [I-D.ietf-cose-rfc8152bis-struct] which also modifies data in the = reference column." I didn't see that action in the other document. [JLS] Originally I did all of the updates from RFC8152 to one of these = two documents over in the struct document. I later broke that up and = did not catch this point. That is deleted and the update from RFC 8152 = to [[This Document]] is added. (5) I assume that this document (and not -struct) should also update the = COSE Elliptic Curves registry. [JLS] Yes - Done. From nobody Mon Jun 15 10:31:34 2020 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 1E9E13A07CE; Mon, 15 Jun 2020 10:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 vhwYKdVH4Rnv; Mon, 15 Jun 2020 10:31:22 -0700 (PDT) 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 046393A07B9; Mon, 15 Jun 2020 10:31:21 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Jun 2020 10:31:16 -0700 From: Jim Schaad To: 'Martin Duke' , 'The IESG' CC: , , , 'Matthew Miller' References: <159176657029.21875.10088343710386665224@ietfa.amsl.com> In-Reply-To: <159176657029.21875.10088343710386665224@ietfa.amsl.com> Date: Mon, 15 Jun 2020 10:31:14 -0700 Message-ID: <008801d6433a$c6e244d0$54a6ce70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHVtGfUFBi+5CIiLSIQJo/8vmDql6jbCpug Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Martin Duke's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 17:31:28 -0000 -----Original Message----- From: Martin Duke via Datatracker =20 Sent: Tuesday, June 9, 2020 10:23 PM To: The IESG Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; = cose@ietf.org; Matthew Miller ; = linuxwolf+ietf@outer-planes.net Subject: Martin Duke's No Objection on = draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) Martin Duke has entered the following ballot position for draft-ietf-cose-rfc8152bis-algs-09: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As everyone else has pointed out, the header needs to be fixed to = indicate this is Informational, not Standards Track. Section 1. s/messages transport/message transport s/of the Javascript/of Javascript [JLS] Done. Sec 1.3 In the definitions of =E2=80=9CAE=E2=80=9D and =E2=80=9CAEAD=E2=80=9D, I = don=E2=80=99t understand the functional difference between = authentication of =E2=80=9Cplaintext contents=E2=80=9D (AE) and = authentication of =E2=80=9Cnon-encrypted data=E2=80=9D (AEAD). AFAICT AE = isn=E2=80=99t actually used in the document, so it might be easiest to = simply delete it. [JLS] I have updated the text to read as follows, does that make it = clearer? Authenticated Encryption (AE) algorithms are = encryption algorithms that provide an authentication check of the = contents algorithm with the encryption service. An example of an AE = algorithm used in COSE is AES Key Wrap . = These algorithms are used for key encryption algorithms, but AEAD = algorithms would be preferred. Authenticated Encryption with Associated Data (AEAD) algorithms provide the same authentication service = of the content as AE algorithms do. They also allow for associated = data to be included in the authentication service, but which is not part = of the encrypted body. An example of an AEAD algorithm used in COSE = is AES-GCM . These algorithms are used for = content encryption and can be used for key encryption as well. Sec 1.5. Replace the URL with a reference. [JLS] Fixed. I actually read this whole document but got pretty lost by the end, not = being an expert in this area. From nobody Mon Jun 15 10:48:16 2020 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 4F7E53A0924; Mon, 15 Jun 2020 10:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnyUONDnfkjh; Mon, 15 Jun 2020 10:48:04 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 D7EE73A08AD; Mon, 15 Jun 2020 10:48:02 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id c8so18869360iob.6; Mon, 15 Jun 2020 10:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3veooenWAZtZvF2xKtkVTCT7ynycOPO1RNBUrQb7AYY=; b=pWqf1oyWFo53pSsfXlrdkdJRFOutbipaZGw7656enkR+GfCAsAABfHKtYXOuba0DAy y3oYPwKTaPSs3G6oqYmmAb6fQuQb30AqMX8oW76aRneU6BGsYbLYrhsGjLupfvgBUffS faCbD+clpXw/1CUkY5H9Ia1njUsPBISzKkB72VeX2UbJ8CLV6PJyI2e3ptwUG0f/zgzv +luhU6H/gUxpWJ7B8lrR9QXjyNytgRd0AfL5h28pAbhjvp72ByuDORyJifziFA9PsMud 4OkPGvvZTkYykwe9PSlSaFEbllw7zdr8zy4Qxlv4VVWsPOuoKm561BY2i5plzmtc0Lj0 pmtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3veooenWAZtZvF2xKtkVTCT7ynycOPO1RNBUrQb7AYY=; b=pMYD4ybP2/57YHuYlELRulNWAYPzaEgUkV3g5u/0AXwmEO17wTP9BlzCONbKJvSd68 cKcfGuRZuE1bbs5yclWH/IVuvH17QsV6VF2qp6vV5IdMJ07pgHPqtSaOMR3Vls2Jkg6W P/Z4Gg5GlPaKFT6BYcj6h+NwMJjrAniGiXoIYCH4xyanpQ8Zn4bmveHOVoaA5Rok6s8Z QTDSGGRAKBUUS3QzZJwinq6wyES+R4o8fI/1fbLFsUW8PN+anHfh0791euU62MHX862u 8A8q+M4K1oMZDzr8SeY/VgpW3Nbv2sYWpidRIvQwpfu23kBNZdhQTW2kOp2u6YXSajCW r91g== X-Gm-Message-State: AOAM531zWp7DGawa836aNrE6xjQ/gLIRHPfo17IKpxnoIb6UdITqjJ7x IHCRbLqO2g6S5vp5PMSw9nwuq+kgzq2C81fW1EmE5Vvi X-Google-Smtp-Source: ABdhPJzF7KGg1x+zIW5if69L4ZVdNTmz+Dic2zPNpqoQQc3UxnumPTOg++gqzutMN1f+tQVyNAMAQG7MCH1xyar0cxQ= X-Received: by 2002:a5d:9a13:: with SMTP id s19mr28839354iol.20.1592243282072; Mon, 15 Jun 2020 10:48:02 -0700 (PDT) MIME-Version: 1.0 References: <159176657029.21875.10088343710386665224@ietfa.amsl.com> <008801d6433a$c6e244d0$54a6ce70$@augustcellars.com> In-Reply-To: <008801d6433a$c6e244d0$54a6ce70$@augustcellars.com> From: Martin Duke Date: Mon, 15 Jun 2020 10:47:51 -0700 Message-ID: To: Jim Schaad Cc: The IESG , draft-ietf-cose-rfc8152bis-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller Content-Type: multipart/alternative; boundary="0000000000003956da05a823071c" Archived-At: Subject: Re: [COSE] Martin Duke's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 17:48:14 -0000 --0000000000003956da05a823071c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable s/contents algorithm/contents, I think, but otherwise LGTM. this is non-blocking, but I don't see a reason to include the AE definition in this document at all, but I"m happy to consider these issues addressed. On Mon, Jun 15, 2020 at 10:31 AM Jim Schaad wrote: > > > -----Original Message----- > From: Martin Duke via Datatracker > Sent: Tuesday, June 9, 2020 10:23 PM > To: The IESG > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; > cose@ietf.org; Matthew Miller ; > linuxwolf+ietf@outer-planes.net > Subject: Martin Duke's No Objection on draft-ietf-cose-rfc8152bis-algs-09= : > (with COMMENT) > > Martin Duke has entered the following ballot position for > draft-ietf-cose-rfc8152bis-algs-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > As everyone else has pointed out, the header needs to be fixed to indicat= e > this is Informational, not Standards Track. > > Section 1. > s/messages transport/message transport > s/of the Javascript/of Javascript > [JLS] Done. > > Sec 1.3 > In the definitions of =E2=80=9CAE=E2=80=9D and =E2=80=9CAEAD=E2=80=9D, I = don=E2=80=99t understand the functional > difference between authentication of =E2=80=9Cplaintext contents=E2=80=9D= (AE) and > authentication of =E2=80=9Cnon-encrypted data=E2=80=9D (AEAD). AFAICT AE = isn=E2=80=99t actually > used in the document, so it might be easiest to simply delete it. > [JLS] I have updated the text to read as follows, does that make it > clearer? > > Authenticated Encryption (AE) algorithms are > encryption algorithms that provide an authentication check of the content= s > algorithm with the encryption service. An example of an AE algorithm use= d > in COSE is AES Key Wrap . These algorithms are > used for key encryption algorithms, but AEAD algorithms would be preferre= d. > > Authenticated Encryption with Associated Data (AEAD) target=3D"RFC5116"/> algorithms provide the same authentication service o= f > the content as AE algorithms do. They also allow for associated data to > be included in the authentication service, but which is not part of the > encrypted body. An example of an AEAD algorithm used in COSE is AES-GC= M > . These algorithms are used for content > encryption and can be used for key encryption as well. > > > Sec 1.5. Replace the URL with a reference. > [JLS] Fixed. > > I actually read this whole document but got pretty lost by the end, not > being an expert in this area. > > > > > --0000000000003956da05a823071c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
s/contents algorithm/contents, I think, but otherwise LGTM= .

this is non-blocking, but I don't see a reason to = include the AE definition in this document at all, but I"m happy to co= nsider these issues addressed.

On Mon, Jun 15, 2020 at 10:31 AM Jim Sc= haad <ietf@augustcellars.com> wrote:

-----Original Message-----
From: Martin Duke via Datatracker <noreply@ietf.org>
Sent: Tuesday, June 9, 2020 10:23 PM
To: The IESG <iesg@ie= tf.org>
Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; cose@ietf.org; Matthew Miller <= ;lin= uxwolf+ietf@outer-planes.net>; linuxwolf+ietf@outer-planes.net
Subject: Martin Duke's No Objection on draft-ietf-cose-rfc8152bis-algs-= 09: (with COMMENT)

Martin Duke has entered the following ballot position for
draft-ietf-cose-rfc8152bis-algs-09: No Objection

When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dr= aft-ietf-cose-rfc8152bis-algs/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

As everyone else has pointed out, the header needs to be fixed to indicate = this is Informational, not Standards Track.

Section 1.
s/messages transport/message transport
s/of the Javascript/of Javascript
[JLS] Done.

Sec 1.3
In the definitions of =E2=80=9CAE=E2=80=9D and =E2=80=9CAEAD=E2=80=9D, I do= n=E2=80=99t understand the functional difference between authentication of = =E2=80=9Cplaintext contents=E2=80=9D (AE) and authentication of =E2=80=9Cno= n-encrypted data=E2=80=9D (AEAD). AFAICT AE isn=E2=80=99t actually used in = the document, so it might be easiest to simply delete it.
[JLS]=C2=A0 I have updated the text to read as follows, does that make it c= learer?

Authenticated Encryption (AE) <xref target=3D"RFC5116"/> al= gorithms are encryption algorithms that provide an authentication check of = the contents algorithm with the encryption service.=C2=A0 An example of an = AE algorithm used in COSE is AES Key Wrap <xref target=3D"RFC3394&q= uot;/>.=C2=A0 These algorithms are used for key encryption algorithms, b= ut AEAD algorithms would be preferred.

Authenticated Encryption with Associated Data (AEAD) <xref target=3D&quo= t;RFC5116"/> algorithms provide the same authentication service of = the content as AE algorithms do.=C2=A0 =C2=A0They also allow for associated= data to be included in the authentication service, but which is not part o= f the encrypted body.=C2=A0 =C2=A0 An example of an AEAD algorithm used in = COSE is AES-GCM <xref target=3D"RFC5116"/>.=C2=A0 =C2=A0 Th= ese algorithms are used for content encryption and can be used for key encr= yption as well.


Sec 1.5. Replace the URL with a reference.
[JLS] Fixed.

I actually read this whole document but got pretty lost by the end, not bei= ng an expert in this area.




--0000000000003956da05a823071c-- From nobody Mon Jun 15 12:22:45 2020 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 EB4003A0CE5; Mon, 15 Jun 2020 12:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YRHCoacj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=bHkBGjEm 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 os5zuSElfQDf; Mon, 15 Jun 2020 12:22:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32E9A3A0CE4; Mon, 15 Jun 2020 12:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4218; q=dns/txt; s=iport; t=1592248961; x=1593458561; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fl0mV4bmnC++KzTkJhZtf/wMcNWFPgB7K6P7BAWMLnI=; b=YRHCoacjpzuQFWMfyy0jZfhzVUYUs2HqHS28cj5AJl0QK+K25VbvUExI MEahwJvcDFiUKkFZZZsqwf4C1Z6CJx+jdw1QGWus2kFgfQQh0tCF9bppa OkxezrYU6Rad7yh5YgMbeh6H93+0Lls59Ekiuxg5dynaCHgUuxl3Xzkgl 8=; IronPort-PHdr: =?us-ascii?q?9a23=3Atm+AgBG/3EvVLqym+Ay+KJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401gebVoLe8+9YhvCQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFbVp2Wv8TMIXB?= =?us-ascii?q?LlOlk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXAQD1yede/4MNJK1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTkEAQELAYFRUQeBRy8sCoQag0YDjT2YUoJSA1ULAQEBDAE?= =?us-ascii?q?BLQIEAQGERAIXghgCJDcGDgIDAQELAQEFAQEBAgEGBG2FWwyFcgEBAQECARI?= =?us-ascii?q?REQwBATcBCwQCAQgRBAEBAwImAgICMBUICAIEAQ0FCBqFUAMOIAGqVAKBOYh?= =?us-ascii?q?hdoEygwEBAQWFIhiCDgmBDioBgmOJZhqBQT+BEUOCTT6EP4MSM4ItjnCDM6I?= =?us-ascii?q?eCoJZmTueZ5EXni0CBAIEBQIOAQEFgWkjgVZwFYMkUBcCDY4eDBcUgzqKVnQ?= =?us-ascii?q?3AgYBBwEBAwl8jVQtgQYBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.73,515,1583193600"; d="scan'208";a="523874290" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jun 2020 19:22:15 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 05FJMFZW008911 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Jun 2020 19:22:15 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Jun 2020 14:22:15 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Jun 2020 15:22:14 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 15 Jun 2020 14:22:14 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jI3o7lm3P+sOoTNyi2vg1bQecq/JUpf8HpQ+mPawJ2MjKsYDKaIHIW2cNzfwRqHtwusMGjwCiN7H2Lv1gWRTuyCV77VES3m13e83QLhv4VuqkTpkhmEYXvOXQ+iPNIjaSTuH00UzCFE9XER96w+xJ8QpQdC1VfgaXOBCMNtOr+Ft4a8ttPcUonbCnoARB7upmg4Fbo+kAZJYzssbB7DrDz4XhIeWfN2xoKOHLWg+Z96VdRf5DmrnZRqz2hrVU2eNTsZfxflCHDoOLVWomQ3yKCxkfurxdnPQG1RR9wou6pWKQQ6VxAasRiyRzrnp5Wzzq/1uasXwMD02bfIMOOFv2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fl0mV4bmnC++KzTkJhZtf/wMcNWFPgB7K6P7BAWMLnI=; b=nQU15fsLxk47Wq6Apj6qbJ9ISvBwdoys7g6keo6ExMVTBkndWmDgFAJAu0zfWspddsU3OtxB6jrPHD9WM2atLq+8vt1qlPwF49S/WP+wWxu7MOtRPWgq7E9GY5Sa0c14+7Z+HR7GC1CqhiHjxwB6FfYNYPqbKeXW2rG4oMYyxy6wzh/4L6dzUZTUygQQ19mii+3LbvUR9qcVUIyk6Uvp/jgjb89yTMo4SqIc7mHWn12sHGK+ogpTPQKe77tTgfWEJgOMwGflWnIbNlEofYL60Nww5IA0qbCLpcCzHHWxp5G897SaGVdX65+Bz9e24f2w3V6/zv2z1kpzrD97+fAzow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fl0mV4bmnC++KzTkJhZtf/wMcNWFPgB7K6P7BAWMLnI=; b=bHkBGjEmQx3cB9iZbiUtIA7ScI5aMKnn/oBA40IMK9CGg3E1PfdwU77CnHPPqNHoqspFI3cfbMiYUpTVe1W5vHtwL07e4YWYO1LNlPA9dWG/eBpr/rhkd3Y8TZFPeRT7u8HcGdW3JzEKXAt1yD2RM8N8TeGwhAdDW1X7TDh4x5k= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4743.namprd11.prod.outlook.com (2603:10b6:208:260::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Mon, 15 Jun 2020 19:22:13 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18%5]) with mapi id 15.20.3088.028; Mon, 15 Jun 2020 19:22:13 +0000 From: "Rob Wilton (rwilton)" To: Barry Leiba , Jim Schaad CC: The IESG , "draft-ietf-cose-rfc8152bis-struct@ietf.org" , "cose-chairs@ietf.org" , Matthew Miller , Benjamin Kaduk , "cose@ietf.org" Thread-Topic: Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT) Thread-Index: AQHWP1HE5u+CqgjwV0aTTCudvijR6ajYsmaAgAC0DvCAAIQYAIAABrwAgAAhd5A= Date: Mon, 15 Jun 2020 19:22:13 +0000 Message-ID: References: <159181232597.18622.11559246666786395335@ietfa.amsl.com> <004d01d64298$8733f600$959be200$@augustcellars.com> <008401d64334$9ad6ff30$d084fd90$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [64.103.40.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 447a16f0-9ce4-481c-6975-08d8116168ac x-ms-traffictypediagnostic: MN2PR11MB4743: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0cbPaox3+sl/0p1bZ7kolm4hNq8kB4nZaaBo7VCvkgIsdummrNAW8B8z8bZQw9Wjtxnx2k/OT5tnGM9NJl+PkJwaJYDEQcmBqKc0lOxV7GywO618P95jqiushkdvHcst2AdcL4FlY5Ke8vDjUUlPsnrDgFcOr/u7WFyvTzzs6BerkkhZoe/skSojWZrme4IdSCBoe5zxziXCQ6cBVAf39gmzJs/HDnqb1kE0ichCW2SnGxcsmlByU2uIQk+edMuS59snlNWdpxLG49LjX5OJd/PVGHpfBM2fyeTWTUsA+6Z2JNhgvnCI/3AYWWC4m8Fkpnno5KrXGvPA3a4Eo2A+Hw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(366004)(376002)(396003)(346002)(66946007)(66476007)(66556008)(64756008)(66446008)(478600001)(2906002)(54906003)(316002)(8936002)(76116006)(53546011)(186003)(7696005)(6506007)(9686003)(55016002)(4326008)(26005)(86362001)(33656002)(71200400001)(52536014)(8676002)(5660300002)(110136005)(83380400001)(66574014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: nXwMWaYRxF86sRAcKj3OmAYycPgj+2+tHJcf1ATRjqTV+1Uwxn2gFba7MZCp4A0O3A2RXu9uRq20vT3ZLNLcBZyOfjauBmuxr+Laq5OOgEwWDFOrOk1zL5eW9d1wh/tv4jJeyAAKu4qphQKOfE1JLeyGEItuhQprlB7XkCO8e3zaTf0ExJFL6dEQ9iUpVfDjhefT/9CmOGx6jgpgNr9sgI2thwpAjBIqUN1VVeB3MsoFI3wtaiE5Dkgoa+58jkRDqBulVQzgmwkkWwy9T0+rPM1OdEtHNikfHhGnfxO0QWEJGZvz+tqUXMqj3xZBKrtqi8Yzo43eR9bXA7LBHVbRauj5BC2eX6/hnIGpNn6r432ZcO0ueq7dJe3PjbCBYUP9Oz+edPK+s/QKRvKR6wzF5DOTWHcIoFX1hVFYhUnMPKB+/RuH1s6ppk9wrQ6cD7ccfE2S+3rGc9kZ9JHOLNRSlcAZe56JBm0ENfSzc76NQjM= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 447a16f0-9ce4-481c-6975-08d8116168ac X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 19:22:13.7765 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QElTeM5zjpKZZFgT1aKuH37nrfP7OsQuL8cByJ5aR/3s7TtdOZZx+aPtLq+oIMm2DFvZC9t7YYh4UoRH3vjDtQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4743 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [COSE] Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 19:22:43 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmFycnkgTGVpYmEgPGJh cnJ5bGVpYmFAY29tcHV0ZXIub3JnPg0KPiBTZW50OiAxNSBKdW5lIDIwMjAgMTg6MTENCj4gVG86 IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+DQo+IENjOiBSb2IgV2lsdG9uIChy d2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47DQo+ IGRyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlzLXN0cnVjdEBpZXRmLm9yZzsgY29zZS1jaGFpcnNA aWV0Zi5vcmc7IE1hdHRoZXcNCj4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMu bmV0PjsgQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+Ow0KPiBjb3NlQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBSb2JlcnQgV2lsdG9uJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYt Y29zZS1yZmM4MTUyYmlzLQ0KPiBzdHJ1Y3QtMTA6ICh3aXRoIENPTU1FTlQpDQo+IA0KPiA+PiBZ b3UgbmVlZCBhIG5vcm1hdGl2ZSByZWZlcmVuY2Ugb24gdGhlIENEREwgZG9jdW1lbnQgcmVnYXJk bGVzcywgZ2l2ZW4NCj4gPj4gdGhhdCBpdCBpcyBub3QgcG9zc2libGUgdG8gdW5kZXJzdGFuZCB0 aGUgZW50aXJldHkgb2YNCj4gPj4gZHJhZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtc3RydWN0IHdp dGhvdXQgcmVhZGluZyB0aGUgQ0RETCBkcmFmdCwNCj4gPj4gaGVuY2UgaXQgaXMgYSBub3JtYXRp dmUgcmVmZXJlbmNlLiAgVGhlIG9ubHkgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8NCj4gPj4gc3Ry aXAgYWxsIHRoZSBDRERMIHRleHQgb3V0IG9mIHRoZSBkb2N1bWVudCwgYW5kIEkgcmVhbGx5IGRv dWJ0IHRoYXQNCj4gPj4geW91IHdvdWxkIHdhbnQgdG8gZG8gdGhhdC4NCj4gPj4NCj4gPj4gRXZl biBpZiB0b29scyBhcmUganVzdCBiZWluZyB1c2VkIGZvciB2YWxpZGF0aW9uIHRoZW4geW91IHN0 aWxsDQo+ID4+IHJlcXVpcmUgdGhlIENEREwgdG8gYmUgcmlnaHQgb3Igb3RoZXJ3aXNlIHRoZSB2 YWxpZGF0aW9uIGNvdWxkIGdpdmUgYW4NCj4gPj4gaW5jb3JyZWN0IHJlc3BvbnNlLg0KPiA+Pg0K PiA+PiBIZW5jZSwgSSB3b3VsZCByZWNvbW1lbmQgdGhhdCB5b3UgYml0ZSB0aGUgYnVsbGV0LCBh ZGQgdGhlIG5vcm1hdGl2ZQ0KPiA+PiByZWZlcmVuY2UsIGFuZCBtYWtlIHRoZSBDRERMIHRleHQg bm9ybWF0aXZlLiAgR2l2ZW4gdGhhdCBDRERMIGhhcw0KPiA+PiBhbHJlYWR5IGJlZW4gcHVibGlz aGVkIGFzIGFuIFJGQywgSSdtIHVuc3VyZSB3aHkgaGF2aW5nIGEgbm9ybWF0aXZlDQo+ID4+IHJl ZmVyZW5jZSB0byBpdCB3b3VsZCBiZSBhIHByb2JsZW0uDQo+ID4NCj4gPiBbSkxTXSBTZWN0aW9u IDEuNCBpcyBkZXNpZ25lZCB0byBhdm9pZCB0aGUgbmVlZCBmb3IgQ0RETCB0byBiZQ0KPiA+IG5v cm1hdGl2ZS4gIEFsc28gc2luY2UgdGhlIENEREwgaXMgZXhwbGljaXRseSBub3JtYXRpdmUgSSBk byBub3QNCj4gPiBiZWxpZXZlIHRoYXQgaXQgbmVlZHMgdG8gYmUgbm9ybWF0aXZlLg0KPiANCj4g SSBjYW4ndCBmaWd1cmUgdGhpcyBvdXQsIEppbS4gIElzIHRoZXJlIGEgIm5vdCIgbWlzc2luZywg b3Igc29tZSBzdWNoPw0KW1JXXSANCg0KSSBzdXNwZWN0IHRoYXQgSmltIHByb2JhYmx5IG1lYW50 ICJDRERMIGlzIGV4cGxpY2l0bHkgaW5mb3JtYXRpdmUgLi4uIiwgYnV0IHRoYXQgZG9lc27igJl0 IG1hdHRlci4gIEkuZS4ganVzdCBiZWNhdXNlIHRoZSB0ZXh0IGlzIGluZm9ybWF0aXZlIGRvZXNu 4oCZdCBtYWtlIHJlZmVyZW5jZXMgdG8gZXhwbGFpbiBpdCBpbmZvcm1hdGl2ZSAoaWYgcmVxdWly ZWQpLg0KDQpCYXJyeSwgd2Ugc2hvdWxkIHRyeSBhbmQgY29tcGxldGUgdGhlIHVwZGF0ZWQgdGV4 dCBmb3IgZXhwbGFpbmluZyBub3JtYXRpdmUgdnMgaW5mb3JtYXRpdmUgcmVmZXJlbmNlcyAuLi4N Cg0KDQo+IA0KPiBJbiBhbnkgY2FzZSwgSSBhZ3JlZSB0aGF0IHRoZSBDRERMIHJlZmVyZW5jZSBj YW4gYmUgaW5mb3JtYXRpdmUuICA4MTUyDQo+IHByZWRhdGVkIHRoZSBDRERMIHNwZWMgYW5kIHdh cyB1bmRlcnN0YW5kYWJsZSB3aXRoIG9ubHkgYW4gaW5mb3JtYXRpdmUNCj4gcmVmZXJlbmNlIHRv IGl0LCBhbmQgSSBkb24ndCB0aGluayA4MTUyYmlzIGhhcyBjaGFuZ2VkIGluIHRoYXQgcmVnYXJk Lg0KW1JXXSANCg0KQWN0dWFsbHksIGhhdmluZyBsb29rZWQgYXQgdGhlIGRyYWZ0IGFnYWluLCBJ IGFncmVlLiAgSSBoYWRuJ3QgcmVhbGl6ZWQgdGhhdCB0aGlzIGRvY3VtZW50IGFpbXMgdG8gZGVz Y3JpYmUvZG9jdW1lbnQgZW5vdWdoIG9mIHRoZSBDRERMIHN5bnRheCB0aGF0IGl0IGRvZXNuJ3Qg cmVxdWlyZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UuDQoNCj4gDQo+ID4gSSBhbSBzdGlsbCB1bmRl ciB0aGUgaW1wcmVzc2lvbiB0aGF0IG9uZSBuZWVkcyB0byBsb29rIHZlcnkgY2xvc2VseSBhdA0K PiA+IFNURCBkb3ducmVmcyBhcyB3ZWxsIGFzIFN0YW5kYXJkcyBUcmFjayBkb3ducmVmcyBpcyB0 aGF0IG5vdCB0cnVlPw0KPiANCj4gQW4gSW50ZXJuZXQgU3RhbmRhcmQgdGhhdCBjaXRlcyBhIFBy b3Bvc2VkIFN0YW5kYXJkIG5vcm1hdGl2ZWx5IGlzDQo+IG1ha2luZyBhIGRvd25yZWYsIGlmIHRo YXQncyB3aGF0IHlvdSdyZSBhc2tpbmcuICBUaGF0IHNhaWQsIGl0J3Mgbm90IGENCj4gYmlnIHBy b2JsZW0gdG8gYWNjZXB0IHRoYXQgLS0gd2Ugd291bGQganVzdCBoYXZlIHRvIHJ1biBhbm90aGVy DQo+IHR3by13ZWVrIGxhc3QgY2FsbCB0byBhcHByb3ZlIHRoZSBkb3ducmVmLiAgQnV0LCBhcyBJ IHNhaWQgYWJvdmUsIEkNCj4gZG9uJ3QgdGhpbmsgdGhhdCdzIG5lY2Vzc2FyeS4NCj4gDQo+IFJv YiwgY2FuIHlvdSBnaXZlIHNwZWNpZmljIGV4YW1wbGVzIG9mIHRoaW5ncyBpbiA4MTUyYmlzIHRo YXQgY2FuJ3QgYmUNCj4gcHJvcGVybHkgdW5kZXJzdG9vZCB3aXRob3V0IG5vcm1hdGl2ZSByZWZl cmVuY2UgdG8gUkZDIDg2MTA/DQpbUlddIA0KDQpJJ3ZlIGNoZWNrZWQgYWdhaW4sIG5vIEkgY2Fu J3QuICBJbmZvcm1hdGl2ZSBpcyBmaW5lLg0KDQpSZWdhcmRzLA0KUm9iDQoNCj4gDQo+IEJhcnJ5 DQo= From nobody Mon Jun 15 16:05:04 2020 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 2323B3A0CCD; Mon, 15 Jun 2020 16:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 5pfjL47Xsdnk; Mon, 15 Jun 2020 16:04:53 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450123A0ED2; Mon, 15 Jun 2020 16:04:52 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05FN4hsI010682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Jun 2020 19:04:46 -0400 Date: Mon, 15 Jun 2020 16:04:43 -0700 From: Benjamin Kaduk To: Jim Schaad Cc: "'The IESG'" , draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, "'Matthew Miller'" , cose@ietf.org Message-ID: <20200615230443.GO11992@kduck.mit.edu> References: <159183984940.7642.3215375794743353401@ietfa.amsl.com> <004c01d64297$360aa310$a21fe930$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <004c01d64297$360aa310$a21fe930$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 23:04:57 -0000 Hi Jim, On Sun, Jun 14, 2020 at 03:00:23PM -0700, Jim Schaad wrote: > > > -----Original Message----- > From: Benjamin Kaduk via Datatracker > Sent: Wednesday, June 10, 2020 6:44 PM > To: The IESG > Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org; cose-chairs@ietf.org; cose@ietf.org; Matthew Miller ; linuxwolf+ietf@outer-planes.net > Subject: Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-cose-rfc8152bis-struct-10: Discuss > > When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (Arguably a "discuss discuss".) > > If we don't have any worked examples of signatures with message recovery, should we include that possibility in the Internet Standard version of the protocol? Some of the description around how the details of this would work remain unclear to me. > > [JLS] I tried a couple of times to get Kenny interested in seeing if anybody in CFRG wanted to pursue this and never got anywhere. This text is here as much to let people know that such an algorithm might be defined in the future and it might cause some problems if it is. > > At one point I looked at looked at writing an experimental RFC which would define a version of this with RSA. The padding algorithm would look like that in PKCS #1.5 with the following change: PS = byte count || stolen bytes || 0xff where byte count is the length of stolen bytes and stolen bytes are the last n bytes of the signed message. Where byte count is the minimum of the message length and (emLen - tLen - 4). I ended up not doing this because I did not want it to escape into the wild and I did not see any way of having people implement this for testing and still making sure that it was contained. > > One pointer is https://crypto.stackexchange.com/questions/17802/description-of-signatures-with-message-recovery-as-in-iso-iec-9796-2-and-emv-si I was thinking specifically of worked examples for COSE usage. E.g., verifying that the "payload" element of SOSE_Sign interoperates, especially when the signature provides full message recovery and how the "message sent" and recovered content are reconstituted into the "message content" during the Verification() process. We don't give many details of how that would work or what an algorithm specification would need to provide in order to give a complete specification. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (I support Roman's Discuss.) > > It's a little weird that we're Obsoletes:ing 8152 yet expect the expert review procedures from it to remain in force. Perhaps we should copy the expert review instructions to this document so that IANA is not relying on an obsolete document? > [JLS] There was some discussion about this in the WG that was pretty inconclusive. Given that did not change I did not see this to be a big issue but if the IESG wants to change this tell me. My preference would be to bring the text into this document, but I'd like to hear from others. > Do we need to check usage of "counter signature" with and without space? > [JLS] I have a note in the XML to the RFC Editor about this point. Ah, excellent. > I'd also like to discuss the question raised by Martin D. (on -algs) relating to "AE" and "AEAD". Section 9.3 is quite clear that we restrict content-encryption algorithms to those that support AAD, i.e., AEAD mechanisms, so we only seem to use AE for the Key Wrap operations. > Perhaps we should add a clarifying note in the terminology section about what AE and AEAD are used for. > [JLS] See response to Martin (still to be written) > > Section 1 > > Shouldn't we refer to RFC 8259 by its STD number (90)? > [JLS] Makes sense > > structures. CBOR was designed specifically both to be small in terms > of messages transported and implementation size and be a schema-free > decoder. A need exists to provide message security services for IoT, > > nit: I think the second "be" should be "to be" as well. > [JLS] Changed > > * The description of the structure for the CBOR objects which are > transmitted over the wire. Two objects are defined for > encryption, signing and message authentication. One object is > > That's two objects *each*, right? > [JLS] Changed. > > * A starting set of attributes that apply to the different security > objects. > > nit: the "starting set" wording feels a little out of place given that the registry already exists and has stuff that we're not covering. > [JLS] Removed starting > > > providing security services. The use of COSE, like JOSE and CMS, is > only in store and forward or offline protocols, different solutions > would be appropriate for online protocols although one can use COSE > in an online protocol after having done some type of online key > establishment process. Any application which uses COSE for security > > > be done before sending objects back and forth. > [JLS] New text: > The use of COSE, like JOSE and CMS, is only for use in store and forward or offline protocols. > The use of COSE in online protocols needing encryption, require that an online key establishment process > nit: comma splice (and the sentence after the comma is a bit long, too). [something doesn't seem to be showing up well in the text/plain component here; I'll try to take a look at the updated I-D when it lands] > additional data fields as part of the structure. A common structure > is going to include a URI or other pointer to where the data that is > being hashed is kept, allowing this to be application-specific. > > This is "common" in the sense of "a design pattern expected to be frequently used", not "a common baseline", right? > [JLS] Yes "popular" is not quite right, though maybe "oft-used"? > Section 1.3 > > * Define a single top message structure so that encrypted, signed, > > nit: "top-level"? > [JLS] "overall"? > > * Signed messages distinguish between the protected and unprotected > header parameters that relate to the content from those that > relate to the signature. > > nit(?): shouldn't this be "distinguish between [x] and [y]", not "between [x] from [y]"? > [JLS] Changed, we will see what the copy editor says. > > Section 1.6 > > Authenticated Encryption (AE) [RFC5116] algorithms are those > encryption algorithms that provide an authentication check of the > contents algorithm with the encryption service. > > nit: this last "algorithm" seems spurious? > [JLS] See message to Martin (to be written) > > context can come from several different sources including: Protocol > interactions, associated key structures and program configuration. > > nit: serial comma, please. > [JLS] Now Oxford comma style > > The context to use can be implicit, identified using the 'kid > context' header parameter defined in [RFC8613], or identified by a > > Wouldn't the "kid context" be an *explicit* context, not implicit? > [JLS] No it is still implicit. Consider the usage of a "kid context" in OSCORE as a method of identifying what items should be placed into the context structure. It changes over time and is not the kid itself. The use of "kid context" as a name is not good, but I did not name it. Okay. > protocol-specific identifier. Context should generally be included > in the cryptographic configuration; for more details see Section 4.3. > > nit: "configuration" is not the first word I would have picked here (and is not used in Section 4.3). Maybe "construction"? > [JLS] Makes sense > > Section 2 > > 1. The protected header parameters encoded and wrapped in a bstr. > > nit: I think this flows better with a comma after "parameters". > [JLS] sure > > 3. The content of the message. The content is either the plaintext > or the ciphertext as appropriate. The content may be detached > (i.e. transported separately from the COSE structure), but the > location is still used. The content is wrapped in a bstr when > > This is "location" in the sense of "the third element of the array", or "the location in the array is still used"? > [JLS] As in the third element of the array. > > layer. In the content layer, the plaintext is encrypted and > information about the encrypted message is placed. In the recipient > layer, the content encryption key (CEK) is encrypted and information > about how it is encrypted for each recipient is placed. A single > > nit: ending the sentence with "is placed" feels rather Yoda-esque. > [JLS] Your point being? Text is re-written to eliminate. > > 4. When a COSE object is carried as a CoAP payload, the CoAP > Content-Format Option can be used to identify the message > content. The CoAP Content-Format values can be found in Table 2. > The CBOR tag for the message structure is not required as each > security message is uniquely identified. > > Is it an error to include the tag? > [JLS] No Okay. > The following CDDL fragment identifies all of the top messages > > [hmm, maybe my earlier comment about "top-level message" was misguided] > [JLS] see above comment. > > Section 3 > > or evaluation hints for the processing of the layer. These two > buckets are available for use in all of the structures except for > keys. While these buckets are present, they may not all be usable in > all instances. For example, while the protected bucket is defined as > > nit: isn't "all buckets" just "both buckets"? > [JLS] I probably meant to rite always though. > > > h'a0'). The zero-length binary encoding is preferred because it > is both shorter and the version used in the serialization > structures for cryptographic computation. After encoding the map, > > nit: this doesn't look like a complete sentence. > [JLS] The RFC editor did not object last time. Noun = encoding, verb = preferred. I was thinking more the parallelism in "is both and ", or perhaps that "shorter" invites a comparison with something unnamed ... I couldn't really pin my finger on it at the time. > structures for cryptographic computation. After encoding the map, > the value is wrapped in the binary object. Recipients MUST accept > > This seems a bit redundant with earlier text (and shouldn't it be a "byte string" anyway?). > [JLS] Yes it is redundant - removed > > both a zero-length byte string and a zero-length map encoded in > the binary value. > > ["binary value" vs. "binary string" vs. "byte string" again] > [JLS] Yep - fixed > > decoded byte string.) This avoids the problem of all parties > needing to be able to do a common canonical encoding. > > perhaps, "common canonical encoding for input to cryptographic operations"? > [JLS] A bit wordy - but ok > > reference to any other layer. With the exception of the COSE_Sign > structure, the only data that needs to cross layers is the > > (I assume this includes COSE_Sign0 and the tagged versions, too?) > [JLS] No it does not include COSE_Sign0 because it has only one layer, but it does include the tagged version which is defined in terms of COSE_Sign. > > Parameters" registry (Section 12.2). Some common header parameters > are defined in the next section. > > [similar comment as above about "common"; maybe "The basic protocol header parameters"?] > [JLS] I don't like that wording, but have no problems eliminating "common". > > malformed. Applications SHOULD verify that the same label does not > occur in both the protected and unprotected header parameters. If > the message is not rejected as malformed, attributes MUST be obtained > from the protected bucket before they are obtained from the > unprotected bucket. > > I a little bit worry that "take from protected before unprotected", combined with "don't check for duplicates", means "last match wins" and the unprotected one gets used. Perhaps it's better to talk about taking precedence if both are present? > [JLS] **** I don't understand your worry here. These are separate maps and thus there is no "last match wins" between the two different buckets. I think this can depend on whether you see the application as doing "I am going to obtain all the attributes" or "I am going to get a value of attribute ". In the latter, you presumably stop once you get a value, here, from the protected bucket. In the former case, though, if you do "get all labels from the protected bucket, put into local cache, then get all labels from the unprotected bucket, put into the same cache", then a "last store wins" for the cache will do the wrong thing. If that's not a relevant "worry", sorry for the noise. > Section 3.1 > > alg: This header parameter is used to indicate the algorithm used > for the security processing. This header parameter MUST be > authenticated where the ability to do so exists. This support is > provided by AEAD algorithms or construction (COSE_Sign, > COSE_Sign1, COSE_Mac, and COSE_Mac0). This authentication can be > > Can countersignatures authenticate 'alg'? > Is there an easy listing of the class of message that does *not* allow for authenticating 'alg'? > [JLS] Where to start, all of the constructions/algorithms have the ability to do the authentication. The use of an AE algorithm does not allow this. By construction, the encryption structures (Encrypt, Encrypt0 and Recipient) do not do this, Changed to " (e.g. COSE_Sign and COSE_Mac0)" We have a MUST-level requirement to do something "where the ability to do so exists". If we leave it to the reader to determine when the ability to do so exists, I don't expect 100% accuracy in practice, so I'm looking for a way that we can give clear guidance on when this protection needs to be present. > COSE_Sign1, COSE_Mac, and COSE_Mac0). This authentication can be > done either by placing the header parameter in the protected > header parameter bucket or as part of the externally supplied > data. The value is taken from the "COSE Algorithms" registry (see > > I don't think we've introduced "externally supplied data" yet, so a forward reference might be in order. > [JLS] Done > > * Integer labels in the range of 0 to 7 SHOULD be omitted. > > side note: I see that RFC 8152 has this as 0 to 8, and 8 is listed as "unassigned" in the registry. Is there a story here? > [JLS] Yes, I had originally assigned countersign0 to 8 and then messed up. Ah, okay. > * Integer labels in the range -1 to -128 can be omitted as they > are algorithm dependent. If an application can correctly > process an algorithm, it can be assumed that it will correctly > > Where is this sub-partitioning of the -1 to -65536 range specified, that any given algorithm will only assign "critical" header parameters in the > -1 to -128 range? If it's just convention I don't think the declarative language ("can be omitted") is appropriate. > [JLS] There is no requirement that an algorithm is restricted to that range. The assumption is that purely optional items might be placed farther out in the range and thus need to be placed in the "crit" attribute. This is just a restriction, similar to the 0-7 range of things that can be omitted. I agree that it's just a restriction, but the way it's written right now it feels like the core spec is making statements about what you should assume to be the case for algorithm-dependent values, without actually placing a requirement on the algorithm specifications to provide that property. If we said that algorithm specs can impose a similar requirement on which values are required to implement and thus safe to omit, and suggested the range of -1 to -128 for those values, I wouldn't have a problem, since that makes it clear that it's a property of the algorithm in question. > * Labels for header parameters required for an application MAY be > omitted. Applications should have a statement if the label can > be omitted. > > nit: applications or application protocols? > [JLS] I am pretty sure I meant applications. I'm having trouble picturing this, but will trust you that it makes sense. > The message IV is generated by the following steps: > > 1. Left-pad the Partial IV with zeros to the length of IV. > > 2. XOR the padded Partial IV with the context IV. > > nit: this procedure does not indicate how "the length of IV" is known (i.e., that it's a constant determined by the algorithm). > > [JLS] I don't think this is really necessary but "IV (determined by the algorithm)" > > Section 4.1 > > authenticated by the signature, or just present. An example of > header a parameter about the content is the content type header > > nit: s/header a/a header/ > [JLS] Yep > > A COSE Signed Message is defined in two parts. The CBOR object that > carries the body and information about the body is called the > COSE_Sign structure. The CBOR object that carries the signature and > > (COSE_Sign also carries the signature parts?) > [JLS] No - they are carried in COSE_Signature I thought the COSE_Sign structure contained one or more COSE_Signature structures. > Note: When a signature with a message recovery algorithm is used > (Section 9.1), the maximum number of bytes that can be recovered > is the length of the payload. The size of the payload is reduced > by the number of bytes that will be recovered. If all of the > > nit(?): it's the "size of the payload" *in the encoded COSE_Sign* object that is reduced, right? > [JLS] No it is the "size of the payload" as in the payload you signed. I'm having trouble parsing that -- it feels circular to me. "In the act of signing, the size of the payload you are signing is reduced by the number of bytes that will be recovered." So what's the payload, the longer thing or the shorter thing? > Section 4.3 > > proxy's cache. But the sender can cause a failure at the server if a > proxy, or an attacker, changes the set of accept values by including > the field in the application-supplied data. > > nit: "application-supplied data" reads pretty oddly to me, though given what section this is in I guess it is not limited to just being "additional authenticated data". > Also, it seems like more a property of the protocol the sender is using than the sole choice of the sender, to include or not include the set of accept values in the externally supplied data. > [JLS] No, it really is just externally supplied data - so changed to that > > This document describes the process for using a byte array of > externally supplied authenticated data; the method of constructing > the byte array is a function of the application. Applications that > > Why is this a "byte array" and not a "byte string"? > [JLS] This is dealing with a value passed in from the application and does not refer to a CBOR encoded value. Okay. > * If multiple items are included, applications need to ensure that > the same byte string cannot be produced if there are different > inputs. This would occur by appending the text strings 'AB' and > 'CDE' or by appending the text strings 'ABC' and 'DE'. This is > > (I liked this better as "could occur" of RFC 8152. Also, is concatenating" better than "appending", since we are posing the two strings as peers, not subject and object?) Also, sometimes this property is referred to as being an "injective mapping". > [JLS] somebody asked for the change from could to would. I debated it with them and then made the change. Going to concatenation makes sense. I don't think that giving the property a name would really help Okay. > Section 4.4 > > (I also had Roman's comment about the "CounterSignature" attributes in field (1).) > > 3. The protected attributes from the signer structure encoded in a > bstr type. If there are no protected attributes, a zero-length > byte string is used. This field is omitted for the COSE_Sign1 > signature structure and CounterSignature0 attributes. > > ("omitted" means "not present in the array at all", right?) > [JLS] Yes > > 4. The protected attributes from the application encoded in a bstr > type. If this field is not supplied, it defaults to a zero- > > Are these "protected attributes" the "externally supplied data" of Section 4.3? We should probably use the same terminology to talk about them... > [JLS] Yes - fixed in all three spots > > Section 5 > > counter signatures use the structure COSE_Countersign. This is same > structure as COSE_Signature and thus it can have protected > attributes, chained counter signatures and information about > identifying the key. Abbreviated counter signatures use the > > nit: "information about identifying the key" seems redundant. > [JLS] Changed to " This is same structure as COSE_Signature and thus it can have protected and unprotected attributes, including chained counter signatures." That probably works. (I was just expecting "information identifying the key" or "information about the key".) > specified. One result of this is that for COSE one can expand the > concept of counter signatures beyond just the idea of signing a > signature to being able to sign most of the structures without having > to create a new signing layer. When creating a counter signature, > > nit: this seems somewhat redundant with the first paragraph of the section ("this document extends to the concept of a counter signature to allow [...]"). > [JLS] Doesn't bother me - it falls out from the previous sentence > > Section 5.1 > > The COSE_Countersignature structure allows for the same set of > capabilities of a COSE_Signature. This means that all of the > > nit: "same set of capabilities as" > [JLS] Changed > > archiving services. More information on how this is used can be > found in the evidence record syntax described in [RFC4998]. > > nit: I'm binding "this" to "COSE_Countersignature", which causes this sentence to not make much sense. Perhaps "how this can be used" or "how countersignatures signing countersignatures can be used" or "long-term archiving services"? > [JLS] This is a really weird reading on your part, but changed. > > COSE_CounterSignature_Tagged = #6.98(COSE_CounterSignature) > > note that 6.98 is incorrect; this is going to be the TBD value. > [JLS] Cut and paste error - yes this is a TBD. > > Section 6.1 > > I think we need some forward-references to 6.3/6.4, here, since (e.g.) > 6.2 is referencing back here to fill in the ciphertext. > > The COSE_recipient structure is a CBOR array. The fields of the > array in order are: > [...] > ciphertext: This field contains the encrypted key encoded as a bstr. > All encoded keys are symmetric keys; the binary value of the key > is the content. If there is not an encrypted key, then this field > is encoded as a nil value. > > I guess it's impossible to have protected headers with no encrypted key (since you need a ciphertext for protected headers)? > [JLS] Yes that is true > > COSE_recipient = [ > Headers, > ciphertext : bstr / nil, > ? recipients : [+COSE_recipient] > ] > > side note(?): I'm not sure I really understand when the recursive COSE_recipient structure would be used at higher depths of recursion. > [JLS] Did you take a look at Appendix B Not when I wrote this :) > passwords: The CEK is encrypted in a KEK that is derived from a > password. As of when this document was published, no password > algorithms have been defined. > > If there aren't any, do we need to include it in the taxonomy? > > [JLS] It is only a matter of time. Personally I was waiting for Argon2 get someplace before even trying to define one. > > Section 6.3 > > It's slightly amusing that the "Enc_structure" is actually the AAD, not anything encrypted :) > [JLS] You are easily amused then. > > Section 6.4 > > 1. Verify that the 'protected' field is empty. > > 2. Verify that there was no external additional authenticated data > supplied for this operation. > > Presumably we fail the operation if either verification fails? > [JLS] Yes that would be my expectation. > > Section 7.3 > > 3. The protected attributes from the application encoded as a bstr > type. If this field is not supplied, it defaults to a zero- > > [as above, using consistent terminology for "externally supplied data" > would be useful.] > [JLS] see above > > Section 8 > > A COSE Key structure is built on a CBOR map. The set of common > parameters that can appear in a COSE Key can be found in the IANA > "COSE Key Common Parameters" registry (Section 12.4). Additional > parameters defined for specific key types can be found in the IANA > "COSE Key Type Parameters" registry ([COSE.KeyParameters]). > > It's slightly jarring to have a section reference for one registry but an external reference for the other. > [JLS] It doesn't really bother me > > Section 8.1 > > cryptographic operation. Note that the same key can be in a > different key structure with a different or no algorithm > specified; however, this is considered to be a poor security > practice. > > Depending on the answer to my question on -algs about capabilities and their use, this statement might need to be updated. > [JLS] Not clear which comment you are referring to Oops, the referred-to question was "Am I reading this right that the idea is to use capabilities to lock a key down to a single curve?" > kid: This parameter is used to give an identifier for a key. The > identifier is not structured and can be anything from a user- > provided byte string to a value computed on the public portion of > the key. This field is intended for matching against a 'kid' > parameter in a message in order to filter down the set of keys > that need to be checked. > > I suggest reiterating that it is not in any way a unique identifier. > [JLS] sure. > > Base IV: This parameter is defined to carry the base portion of an > IV. It is designed to be used with the Partial IV header > parameter defined in Section 3.1. This field provides the ability > to associate a Partial IV with a key that is then modified on a > > Er, isn't it the Base IV associated with the key and the Partial IV that's per-message? > [JLS] Yup. > > If different keys are derived for each sender, using the same Base > IV with Partial IVs starting at zero is likely to ensure that the > IV would not be used twice for a single key. If different keys > are derived for each sender, starting at the same Base IV is > likely to satisfy this condition. If the same key is used for > > The two sentences that start with "if different keys" seem to have some redundancy that could be eliminated. > [JLS] Looks like I tried two different ways to same the same thing and did not delete one of them. > > Section 9 > > to be exhaustive. New algorithms will be created which will not fit > into this taxonomy. If this occurs, then new documents addressing > this new algorithms are going to be needed. > > nit(?): this last sentence is written in a kind of colloquial style. > [JLS] Doesn't really add anything - delete > > Section 9.1 > > There are two signature algorithm schemes. The first is signature > > nit: mybe "two types of" (and "scheme" singular)? > [JLS] No, I think this is a correct usage. > > Section 9.2 > > Message Authentication Codes (MACs) provide data authentication and > integrity protection. They provide either no or very limited data > origination. A MAC, for example, cannot be used to prove the > identity of the sender to a third party. > > Hmm, should the s/can/cannot/ be filed as an erratum against 8152? > [JLS] Yes if we don't think we are going to have a fast publish. What is the current RFC Editor queue processing time? I think it's pushing 12 weeks, what with C238 and the bulge that accumulated in RFC-EDITOR (https://www.rfc-editor.org/current_queue.php). I'd happily approve a report if you want to file one. > Section 9.4 > > General KDFs work well with the first type of secret, can do > reasonably well with the second type of secret, and generally do > poorly with the last type of secret. Functions like PBES2 [RFC8018] > need to be used for non-random secrets. > > nit: To be analogous to the previous discussion of KDFs, shouldn't we refer to a PBKDF construction, not PBES (which provides an abstract API for password-based encryption that uses PBKDF1 under the covers)? > (Also, my understanding is that PBKDF1 is not exactly considered > state-of-the-art.) > [JLS] Given what I said above, if you really want to change this we could point to Argon2 My main complaint here is that there's a "type error" -- PBES2 is not a KDF (right?). I could tolerate dropping the last sentence entirely, or a bland "Specific KDF constructions are needed to be safely used with non-random secrets" (and no reference), but pointing to Argon2 would also be fine. > Section 9.5.1 > > * A header parameter identifying the shared secret SHOULD be > present. > > What type of header parameter might do that? > [JLS] Will KID would be one that could do this. Do we want to provide guidance in the doc, or is "kid" sufficiently self-explanatory and obvious? > Section 9.5.2 > > * The 'recipients' field is normally absent, but can be used. > Applications MUST deal with a recipient field being present that > has an unsupported algorithm, not being able to decrypt that > recipient is an acceptable way of dealing with it. Failing to > > nit: comma splice > [JLS] ok > > Section 9.5.3 > > When using a key transport algorithm, the COSE_Encrypt structure for > the recipient is organized as follows: > > Does key transport use COSE_Encrypt or COSE_Recipient? > [JLS] No, it uses COSE_Recipient. It used to use COSE_Encrypt until I change the syntax slightly. > > Section 9.5.4 > > any dynamic key material. One side effect of this is that perfect > forward secrecy (see [RFC4949]) is not achievable. A static key will > > Do we want to drop the "perfect"? > [JLS] Yes. > > The COSE_Encrypt structure for the recipient is organized as follows: > > Is COSE_Encrypt or COSE_Recipient used for direct key agreement? > [JLS] see above and others. Got it, thanks. > Section 9.5.5 > > The COSE_Encrypt structure for the recipient is organized as follows: > > Is COSE_Encrypt or COSE_Recipient used for key agreement with key wrap? > > * A header parameter identifying the recipient's key SHOULD be > present. A header parameter identifying the sender's key SHOULD > be present. > > Is there anything to say about what header parameters those might be? > [JLS] No, that would be more algorithm specific esp for the latter. > > Section 10 > > The document limits the restrictions it imposes on the CBOR Encoder > needs to work. > > nit: missing word or two? -algs seems to say "restrictions it imposes on how the CBOR Encoder needs to work". > [JLS] > > Section 11 > > * Applications need to determine the set of security algorithms that > are to be used. When selecting the algorithms to be used as the > mandatory-to-implement set, consideration should be given to > choosing different types of algorithms when two are chosen for a > specific purpose. An example of this would be choosing HMAC- > > Do we want to mention BCP 201 here? > [JLS] I don't have an issue with this, I forgot such a beast had been created. You have a lot of company :) > Section 12 > > Do we want to update the reference for the registries themselves (to point to both 8152 and this) in addition to the reference for the registered entries? > [JLS] Unless we move the DE guidance, I don't see any reason to. > > Section 12.3 > > The COSE Header Algorithm Parameters Registry is https://www.iana.org/assignments/cose/cose.xhtml#header-algorithm-parameters > , right? I don't see any of those being talked about in this document > -- they're discussed in the KDF algorithms section in 8152. So shouldn't this registry (and its entries) point to the algorithms doc, not this one? > [JLS] Yes they should (I think Alvaro(?) also remarked on this and you replied there too.) > Section 12.6 > > IANA added the following entries to the "CoAP Content-Formats" > registry while processing [RFC8152]. IANA is requested to update the > reference value from [RFC8152] to [[This Document]]. > > [no entries follow] > [JLS] s/the following// > > Section 13 > > There are a number of security considerations that need to be taken > into account by implementers of this specification. The security > considerations that are specific to an individual algorithm are > placed next to the description of the algorithm. While some > > [this stuff is in -algs, not -struct] > [JLS] Deleted > > There are a large number of algorithms presented in > [I-D.ietf-cose-rfc8152bis-algs] that use nonce values. Nonces > generally have some type of restriction on their values. Generally a > nonce needs to be a unique value either for a key or for some other > conditions. In all of these cases, there is no known requirement on > the nonce being both unique and unpredictable; under these > circumstances, it's reasonable to use a counter for creation of the > nonce. In cases where one wants the pattern of the nonce to be > > nit: this looks like a bad edit from the splitting off of the > algorithms: "all of these cases" cannot bind to "specified in this document" anymore, so we need to describe what we mean differently. > [JLS] Might just as well delete the duplicated paragraph. gone > > > One area that has been starting to get exposure is doing traffic > analysis of encrypted messages based on the length of the message. > > I think this may have graduated from "starting" to be more of a mainstream thing :) > [JLS] Given that I had to explain this initially, it is nice to know it has gone far more main stream. No longer starting. > > Section 14.1 > > side note: OpenSSL 1.0 (no minor version information given?)?! That stuff's EOL! > [JLS] I actually just updated the library in the last month to require 1.1 in order to get support for EdDSA, however yes it did not really what the minor version was because it was totally generic to that version. I changed that to 1.1, but given that this goes away before publishing I don't suppose it matters andy. Yeah, it was just a side note since it will go away. Thanks for updating it! > Section 14.4 > > side note: what's curve24459? > [JLS] You mean you don't recognize the really twisted curve of 25519 ;) > Section 15.1 > > [DSS] has only one usage now in -struct, which doesn't seem normative. > I'd expect it to only be normative in -algs. > Likewise for RFC 8032. > [JLS] Done > > It's also interesting to make a normative reference to -algs, which will be an informational RFC when published (given the current intended status). Are we creating it directly onto the downrefs registry? > [JLS] I could move the reference without any problems. However, putting it directly in to the downref registry is probably a good idea so that protocol documents can make algorithms MUST. I think we had someone (Barry?) mention on the telechat that we might not need to put it in the registry since it was unclear who else would need to reference it. So, thanks for stating a position -- I trust that the responsible AD will do the right thing. > Appendix A > > side note: it seems like any scheme for conveying information about what algorithm to use other than "implicit by key with each key limited to one algorithm" has some risk of allowing an attacker's input to cause the key holder to perform some operation using that key but with the "wrong" algorithm. I think that if the externally visible results of that operation are indistinguishable from "the input was ignored", that does not give the attacker a channel by which to attack the key, but I'm not 100% sure. Even an application-layer "rejected due to bad input" > might be enough of a lever to enable some types of attack. > [JLS] The current CoRE group communication document is breaking the "one key one algorithm" rule although in an offline way. At least for OSCORE, there would not be a way to distinguish between any of the "it did not decrypt" cases. Sigh. I wonder if I can convince any cryptographers to look at the group communication document. > Appendix B > > All of the currently defined recipient algorithm classes only use two > layers of the COSE_Encrypt structure. The first layer is the message > > COSE_Recipient? > [JLS] That’s what I get for renaming things. > > Acknowledgments > > Göran could probably get his proper name, now. > [JLS] I think he probably would as well. I think I've seen the RPC proactively do this, but nothing stops us from helping. Thanks for all the discussion and updates! -Ben From nobody Mon Jun 15 18:28:19 2020 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 7548B3A0F5B for ; Mon, 15 Jun 2020 18:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 v7jiLsEdHJwJ for ; Mon, 15 Jun 2020 18:28:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676133A0F54 for ; Mon, 15 Jun 2020 18:28:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7813AF406CC; Mon, 15 Jun 2020 18:28:13 -0700 (PDT) To: ietf@augustcellars.com, rdd@cert.org, kaduk@mit.edu, ivaylo@ackl.io, linuxwolf+ietf@outer-planes.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ietf@augustcellars.com, cose@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200616012813.7813AF406CC@rfc-editor.org> Date: Mon, 15 Jun 2020 18:28:13 -0700 (PDT) Archived-At: Subject: [COSE] [Technical Errata Reported] RFC8152 (6209) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 01:28:17 -0000 The following errata report has been submitted for RFC8152, "CBOR Object Signing and Encryption (COSE)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6209 -------------------------------------- Type: Technical Reported by: JimSchaad Section: 9 Original Text ------------- can be used to prove the identity Corrected Text -------------- can not be used to prove the identity Notes ----- MACs cannot be used to prove identity to a third party. There is a missing not in the sentence Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8152 (draft-ietf-cose-msg-24) -------------------------------------- Title : CBOR Object Signing and Encryption (COSE) Publication Date : July 2017 Author(s) : J. Schaad Category : PROPOSED STANDARD Source : CBOR Object Signing and Encryption Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Jun 15 18:44:16 2020 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 4DC7C3A0F75; Mon, 15 Jun 2020 18:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 yXiwZf2-6yJA; Mon, 15 Jun 2020 18:44:12 -0700 (PDT) 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 79DED3A0F74; Mon, 15 Jun 2020 18:44:11 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Jun 2020 18:44:04 -0700 From: Jim Schaad To: 'Benjamin Kaduk' CC: 'The IESG' , , , 'Matthew Miller' , References: <159183984940.7642.3215375794743353401@ietfa.amsl.com> <004c01d64297$360aa310$a21fe930$@augustcellars.com> <20200615230443.GO11992@kduck.mit.edu> In-Reply-To: <20200615230443.GO11992@kduck.mit.edu> Date: Mon, 15 Jun 2020 18:44:02 -0700 Message-ID: <00af01d6437f$9f30ee60$dd92cb20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLLhK51vaVhQCr2j2FaHM+f5QWv3gIn/U8/AYBLdn6m0pZLEA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 01:44:15 -0000 > -----Original Message----- > From: Benjamin Kaduk > Sent: Monday, June 15, 2020 4:05 PM > To: Jim Schaad > Cc: 'The IESG' ; = draft-ietf-cose-rfc8152bis-struct@ietf.org; cose- > chairs@ietf.org; 'Matthew Miller' ; > cose@ietf.org > Subject: Re: [COSE] Benjamin Kaduk's Discuss on = draft-ietf-cose-rfc8152bis- > struct-10: (with DISCUSS and COMMENT) >=20 > Hi Jim, >=20 > On Sun, Jun 14, 2020 at 03:00:23PM -0700, Jim Schaad wrote: > > > > > > -----Original Message----- > > From: Benjamin Kaduk via Datatracker > > Sent: Wednesday, June 10, 2020 6:44 PM > > To: The IESG > > Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org; = cose-chairs@ietf.org; > > cose@ietf.org; Matthew Miller ; > > linuxwolf+ietf@outer-planes.net > > Subject: Benjamin Kaduk's Discuss on > > draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-cose-rfc8152bis-struct-10: Discuss > > > > When responding, please keep the subject line intact and reply to = all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ > > > > > > > > = ---------------------------------------------------------------------- > > DISCUSS: > > = ---------------------------------------------------------------------- > > > > (Arguably a "discuss discuss".) > > > > If we don't have any worked examples of signatures with message = recovery, > should we include that possibility in the Internet Standard version of = the > protocol? Some of the description around how the details of this = would work > remain unclear to me. > > > > [JLS] I tried a couple of times to get Kenny interested in seeing if = anybody in > CFRG wanted to pursue this and never got anywhere. This text is here = as much > to let people know that such an algorithm might be defined in the = future and it > might cause some problems if it is. > > > > At one point I looked at looked at writing an experimental RFC which = would > define a version of this with RSA. The padding algorithm would look = like that in > PKCS #1.5 with the following change: PS =3D byte count || stolen = bytes || 0xff > where byte count is the length of stolen bytes and stolen bytes are = the last n > bytes of the signed message. Where byte count is the minimum of the > message length and (emLen - tLen - 4). I ended up not doing this = because I did > not want it to escape into the wild and I did not see any way of = having people > implement this for testing and still making sure that it was = contained. > > > > One pointer is > > = https://crypto.stackexchange.com/questions/17802/description-of-signat > > ures-with-message-recovery-as-in-iso-iec-9796-2-and-emv-si >=20 > I was thinking specifically of worked examples for COSE usage. E.g., = verifying > that the "payload" element of SOSE_Sign interoperates, especially when = the > signature provides full message recovery and how the "message sent" = and > recovered content are reconstituted into the "message content" > during the Verification() process. We don't give many details of how = that > would work or what an algorithm specification would need to provide in = order > to give a complete specification. [JLS] I don't have any problems with providing such a thing using the = evil signature algorithm that I outlined above on the examples website, = but I don't know that it has any place in the document. >=20 >=20 > > > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > > > > > > > > providing security services. The use of COSE, like JOSE and CMS, = is > > only in store and forward or offline protocols, different = solutions > > would be appropriate for online protocols although one can use = COSE > > in an online protocol after having done some type of online key > > establishment process. Any application which uses COSE for > > security > > > > > > be done before sending objects back and forth. > > [JLS] New text: > > The use of COSE, like JOSE and CMS, is only for use in store = and forward > or offline protocols. > > The use of COSE in online protocols needing encryption, > > require that an online key establishment process > > nit: comma splice (and the sentence after the comma is a bit long, = too). >=20 > [something doesn't seem to be showing up well in the text/plain = component > here; I'll try to take a look at the updated I-D when it lands] >=20 > > additional data fields as part of the structure. A common = structure > > is going to include a URI or other pointer to where the data that = is > > being hashed is kept, allowing this to be application-specific. > > > > This is "common" in the sense of "a design pattern expected to be = frequently > used", not "a common baseline", right? > > [JLS] Yes >=20 > "popular" is not quite right, though maybe "oft-used"? [JLS] Ok - trying to change it just made me sad. Rewrote to A one such application-specific element would be to include a = URI or other pointer to where the data that is being hashed can be = obtained. > > The following CDDL fragment identifies all of the top messages > > > > [hmm, maybe my earlier comment about "top-level message" was > > misguided] [JLS] see above comment. > > > > Section 3 > > > > or evaluation hints for the processing of the layer. These two > > buckets are available for use in all of the structures except for > > keys. While these buckets are present, they may not all be = usable in > > all instances. For example, while the protected bucket is = defined > > as > > > > nit: isn't "all buckets" just "both buckets"? > > [JLS] I probably meant to rite always though. > > > > > > h'a0'). The zero-length binary encoding is preferred because = it > > is both shorter and the version used in the serialization > > structures for cryptographic computation. After encoding the > > map, > > > > nit: this doesn't look like a complete sentence. > > [JLS] The RFC editor did not object last time. Noun =3D encoding, = verb =3D > preferred. >=20 > I was thinking more the parallelism in "is both and ", or = perhaps that > "shorter" invites a comparison with something unnamed ... I couldn't = really pin > my finger on it at the time. [JLS] The options were covered in the preceding sentences and I don't = know that you can get much shorter than a one byte encoding and still = have existence. > > > > malformed. Applications SHOULD verify that the same label does = not > > occur in both the protected and unprotected header parameters. = If > > the message is not rejected as malformed, attributes MUST be = obtained > > from the protected bucket before they are obtained from the > > unprotected bucket. > > > > I a little bit worry that "take from protected before unprotected", = combined > with "don't check for duplicates", means "last match wins" and the = unprotected > one gets used. Perhaps it's better to talk about taking precedence if = both are > present? > > [JLS] **** I don't understand your worry here. These are separate = maps and > thus there is no "last match wins" between the two different buckets. >=20 > I think this can depend on whether you see the application as doing "I = am going > to obtain all the attributes" or "I am going to get a value of = attribute ". In > the latter, you presumably stop once you get a value, here, from the = protected > bucket. In the former case, though, if you do "get all labels from = the protected > bucket, put into local cache, then get all labels from the unprotected = bucket, > put into the same cache", then a "last store wins" for the cache will = do the > wrong thing. > If that's not a relevant "worry", sorry for the noise. [JLS] No it is a relevant worry. There are two buckets and if you = combine the buckets you had better combine them in the correct way. You = are going to need to know if the cache is last wins, first wins or go = boom on duplicates. I am not sure what I can say to make things clearer = though. >=20 > > Section 3.1 > > > > alg: This header parameter is used to indicate the algorithm = used > > for the security processing. This header parameter MUST be > > authenticated where the ability to do so exists. This support = is > > provided by AEAD algorithms or construction (COSE_Sign, > > COSE_Sign1, COSE_Mac, and COSE_Mac0). This authentication can > > be > > > > Can countersignatures authenticate 'alg'? > > Is there an easy listing of the class of message that does *not* = allow for > authenticating 'alg'? > > [JLS] Where to start, all of the constructions/algorithms have the = ability to do > the authentication. The use of an AE algorithm does not allow this. = By > construction, the encryption structures (Encrypt, Encrypt0 and = Recipient) do not > do this, Changed to " (e.g. COSE_Sign and COSE_Mac0)" >=20 > We have a MUST-level requirement to do something "where the ability to = do so > exists". If we leave it to the reader to determine when the ability = to do so > exists, I don't expect 100% accuracy in practice, so I'm looking for a = way that > we can give clear guidance on when this protection needs to be = present. [JLS] Where the ability does not exist is when you do an AE algorithm. = It can be done everywhere else. (And don't get me started on all of the = arguments that I had with the OSCORE people about how important I = thought it was to do this.) Otherwise between the structure and the = algorithm (AEAD) you can always do this either in the protected = attributes or in external data. > > * Integer labels in the range -1 to -128 can be omitted as = they > > are algorithm dependent. If an application can correctly > > process an algorithm, it can be assumed that it will > > correctly > > > > Where is this sub-partitioning of the -1 to -65536 range specified, > > that any given algorithm will only assign "critical" header = parameters > > in the > > -1 to -128 range? If it's just convention I don't think the = declarative language > ("can be omitted") is appropriate. > > [JLS] There is no requirement that an algorithm is restricted to = that range. > The assumption is that purely optional items might be placed farther = out in the > range and thus need to be placed in the "crit" attribute. This is = just a > restriction, similar to the 0-7 range of things that can be omitted. >=20 > I agree that it's just a restriction, but the way it's written right = now it feels like > the core spec is making statements about what you should assume to be = the > case for algorithm-dependent values, without actually placing a = requirement > on the algorithm specifications to provide that property. If we said = that > algorithm specs can impose a similar requirement on which values are > required to implement and thus safe to omit, and suggested the range = of -1 to - > 128 for those values, I wouldn't have a problem, since that makes it = clear that > it's a property of the algorithm in question. [JLS] Does this read better? Integer labels in the range -1 to -128 can be omitted. Algorithms can = assign labels in this range where the ability to process the content of = the label is considered to be core to implementing the algorithm. = Algorithms can assign labels outside of this range where the ability to = process the content of the label is not considered to be core, but needs = to be understood to correctly process this instance. Integer labels in = the range -129 to -65536 SHOULD be included as these = would be less common header parameters that might not be generally = supported. >=20 > > * Labels for header parameters required for an application = MAY be > > omitted. Applications should have a statement if the label = can > > be omitted. > > > > nit: applications or application protocols? > > [JLS] I am pretty sure I meant applications. >=20 > I'm having trouble picturing this, but will trust you that it makes = sense. >=20 > > > > A COSE Signed Message is defined in two parts. The CBOR object = that > > carries the body and information about the body is called the > > COSE_Sign structure. The CBOR object that carries the signature > > and > > > > (COSE_Sign also carries the signature parts?) [JLS] No - they are > > carried in COSE_Signature >=20 > I thought the COSE_Sign structure contained one or more COSE_Signature > structures. Yes it does. I think of the "signature" as the byte string as being = different from the COSE_Signature structure. This is referring to the = first. >=20 > > Note: When a signature with a message recovery algorithm is = used > > (Section 9.1), the maximum number of bytes that can be = recovered > > is the length of the payload. The size of the payload is = reduced > > by the number of bytes that will be recovered. If all of the > > > > nit(?): it's the "size of the payload" *in the encoded COSE_Sign* = object that is > reduced, right? > > [JLS] No it is the "size of the payload" as in the payload you = signed. >=20 > I'm having trouble parsing that -- it feels circular to me. "In the = act of signing, > the size of the payload you are signing is reduced by the number of = bytes that > will be recovered." So what's the payload, the longer thing or the = shorter > thing? [JLS] The payload that is encrypted is the longer thing. The payload = that is carried in the COSE message is the shorter thing. >=20 > > Section 8.1 > > > > cryptographic operation. Note that the same key can be in a > > different key structure with a different or no algorithm > > specified; however, this is considered to be a poor security > > practice. > > > > Depending on the answer to my question on -algs about capabilities = and their > use, this statement might need to be updated. > > [JLS] Not clear which comment you are referring to >=20 > Oops, the referred-to question was "Am I reading this right that the = idea is to > use capabilities to lock a key down to a single curve?" [JLS] Capabilities are not used to lock a key down to a single curve. = The curve is a field in the COSE_Key object. > > Section 9.2 > > > > Message Authentication Codes (MACs) provide data authentication = and > > integrity protection. They provide either no or very limited = data > > origination. A MAC, for example, cannot be used to prove the > > identity of the sender to a third party. > > > > Hmm, should the s/can/cannot/ be filed as an erratum against 8152? > > [JLS] Yes if we don't think we are going to have a fast publish. = What is the > current RFC Editor queue processing time? >=20 > I think it's pushing 12 weeks, what with C238 and the bulge that = accumulated in > RFC-EDITOR (https://www.rfc-editor.org/current_queue.php). > I'd happily approve a report if you want to file one. [JLS] done >=20 > > Section 9.4 > > > > General KDFs work well with the first type of secret, can do > > reasonably well with the second type of secret, and generally do > > poorly with the last type of secret. Functions like PBES2 = [RFC8018] > > need to be used for non-random secrets. > > > > nit: To be analogous to the previous discussion of KDFs, shouldn't = we refer to > a PBKDF construction, not PBES (which provides an abstract API for = password- > based encryption that uses PBKDF1 under the covers)? > > (Also, my understanding is that PBKDF1 is not exactly considered > > state-of-the-art.) > > [JLS] Given what I said above, if you really want to change this we > > could point to Argon2 >=20 > My main complaint here is that there's a "type error" -- PBES2 is not = a KDF > (right?). I could tolerate dropping the last sentence entirely, or a = bland > "Specific KDF constructions are needed to be safely used with = non-random > secrets" (and no reference), but pointing to Argon2 would also be = fine. [JLS] Switched. >=20 > > Section 9.5.1 > > > > * A header parameter identifying the shared secret SHOULD be > > present. > > > > What type of header parameter might do that? > > [JLS] Will KID would be one that could do this. >=20 > Do we want to provide guidance in the doc, or is "kid" sufficiently = self- > explanatory and obvious? [JLS] I think that it is obvious. I also think something like "password = hint" would be as well, but is not currently defined. > > Section 15.1 > > > > [DSS] has only one usage now in -struct, which doesn't seem = normative. > > I'd expect it to only be normative in -algs. > > Likewise for RFC 8032. > > [JLS] Done > > > > It's also interesting to make a normative reference to -algs, which = will be an > informational RFC when published (given the current intended status). = Are we > creating it directly onto the downrefs registry? > > [JLS] I could move the reference without any problems. However, = putting it > directly in to the downref registry is probably a good idea so that = protocol > documents can make algorithms MUST. >=20 > I think we had someone (Barry?) mention on the telechat that we might = not > need to put it in the registry since it was unclear who else would = need to > reference it. So, thanks for stating a position -- I trust that the = responsible AD > will do the right thing. >=20 > > Appendix A > > > > side note: it seems like any scheme for conveying information about = what > algorithm to use other than "implicit by key with each key limited to = one > algorithm" has some risk of allowing an attacker's input to cause the = key holder > to perform some operation using that key but with the "wrong" = algorithm. I > think that if the externally visible results of that operation are = indistinguishable > from "the input was ignored", that does not give the attacker a = channel by > which to attack the key, but I'm not 100% sure. Even an = application-layer > "rejected due to bad input" > > might be enough of a lever to enable some types of attack. > > [JLS] The current CoRE group communication document is breaking the = "one > key one algorithm" rule although in an offline way. At least for = OSCORE, there > would not be a way to distinguish between any of the "it did not = decrypt" cases. >=20 > Sigh. I wonder if I can convince any cryptographers to look at the = group > communication document. [JLS] That is not where I would put the limited resources. I would have = them look at draft-ietf-lwig-curve-representations and ask if there are = issues using the same private key for an EdDSA signature and ECDH after = doing the mapping. I think I recently saw something on the CFRG list = which had a pointer to a paper saying that reuse for ECDH and ECDSA was = ok. > > Acknowledgments > > > > G=C3=B6ran could probably get his proper name, now. > > [JLS] I think he probably would as well. >=20 > I think I've seen the RPC proactively do this, but nothing stops us = from helping. Jim >=20 > Thanks for all the discussion and updates! >=20 > -Ben From nobody Mon Jun 15 22:18:32 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 891AA3A104C; Mon, 15 Jun 2020 22:18:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <159228470597.14028.11707324528215657516@ietfa.amsl.com> Date: Mon, 15 Jun 2020 22:18:26 -0700 Archived-At: Subject: [COSE] Murray Kucherawy's No Objection on draft-ietf-cose-rfc8152bis-struct-10: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 05:18:27 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-cose-rfc8152bis-struct-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In the interests of brevity, my review focused on the diff between this document and RFC 8152. Major points: I agree with Benjamin's concern that we seem to be leaving the Designated Experts for the IANA registries described here with advice in RFC 8152, which this document renders obsolete. I think that prose should be copied to this document so that it lives someplace current. I was originally tempted to DISCUSS this but I'm hesitating, so I'll just say I hope this is resolved appropriately. Some nits: Section 1: * "... structure for the CBOR objects which are ..." -- s/which/that/ * "... or offline protocols, different solutions ..." -- "different" should start a new sentence * "Any application which uses COSE for security ..." -- s/which/that/ Section 5: * The last sentence in the first paragraph: OLD: It needs to be noted that the counter signature needs to be treated as a separate operation from the initial operation even if it is applied by the same user as is done in [I-D.ietf-core-groupcomm-bis]. NEW: It needs to be noted that the counter signature is to be treated as a separate operation from the initial operation, even if it is applied by the same user, as is done in [I-D.ietf-core-groupcomm-bis]. * "This is same structure ..." -- s/same/the same/ * "That is the counter signature ..." -- comma after "is" * "... existence of the encrypted data is attested to." -- maybe "asserted" instead of "attested to"? Section 9: * "New algorithms will be created which will not fit ..." -- s/which/that/ Section 9.5.5: * In the final bullet, why aren't these MUSTs? Or in the alternative, when would one legitimately deviate from those SHOULDs? From nobody Tue Jun 16 08:56:27 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA92B3A17EE; Tue, 16 Jun 2020 08:56:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Cc: draft-ietf-cose-webauthn-algorithms@ietf.org, superuser@gmail.com, Ivaylo Petrov , cose-chairs@ietf.org, cose@ietf.org, ivaylo@ackl.io, rfc-editor@rfc-editor.org, The IESG MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159232297587.8357.17611823890611111626@ietfa.amsl.com> Date: Tue, 16 Jun 2020 08:56:15 -0700 Archived-At: Subject: [COSE] Protocol Action: 'COSE and JOSE Registrations for WebAuthn Algorithms' to Proposed Standard (draft-ietf-cose-webauthn-algorithms-08.txt) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 15:56:16 -0000 The IESG has approved the following document: - 'COSE and JOSE Registrations for WebAuthn Algorithms' (draft-ietf-cose-webauthn-algorithms-08.txt) as Proposed Standard This document is the product of the CBOR Object Signing and Encryption Working Group. The IESG contact persons are Murray Kucherawy, Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/ Technical Summary The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms in the IANA "COSE Algorithms" registry, which are used by WebAuthn and CTAP implementations: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1, and ECDSA using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry. Working Group Summary Consensus to publish appears to be firm, and a number of specific people were identified as having provided reviews, all of which have been addressed. Document Quality The document has had clear working group consensus for publication and it has been reviewed by a few working group participants since its adoption. Personnel Ivaylo Petrov is the document shepherd. Murray Kucherawy is the responsible Area Director. From nobody Tue Jun 16 19:48:25 2020 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 EC8063A0DDC; Tue, 16 Jun 2020 19:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 5U49LF_9WYCi; Tue, 16 Jun 2020 19:48:20 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3573A0DDD; Tue, 16 Jun 2020 19:48:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 77A79F406D6; Tue, 16 Jun 2020 19:48:16 -0700 (PDT) To: ietf@augustcellars.com, ietf@augustcellars.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: kaduk@mit.edu, iesg@ietf.org, cose@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200617024816.77A79F406D6@rfc-editor.org> Date: Tue, 16 Jun 2020 19:48:16 -0700 (PDT) Archived-At: Subject: [COSE] [Errata Verified] RFC8152 (6209) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 02:48:23 -0000 The following errata report has been verified for RFC8152, "CBOR Object Signing and Encryption (COSE)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6209 -------------------------------------- Status: Verified Type: Technical Reported by: JimSchaad Date Reported: 2020-06-16 Verified by: Benjamin Kaduk (IESG) Section: 9 Original Text ------------- can be used to prove the identity Corrected Text -------------- cannot be used to prove the identity Notes ----- MACs cannot be used to prove identity to a third party. There is a missing "not" in the sentence. -------------------------------------- RFC8152 (draft-ietf-cose-msg-24) -------------------------------------- Title : CBOR Object Signing and Encryption (COSE) Publication Date : July 2017 Author(s) : J. Schaad Category : PROPOSED STANDARD Source : CBOR Object Signing and Encryption Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Jun 16 20:02:44 2020 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 4E2923A0DEE; Tue, 16 Jun 2020 20:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 pPJ8v64di5yR; Tue, 16 Jun 2020 20:02:40 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797D93A0DEC; Tue, 16 Jun 2020 20:02:40 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05H32VGC028318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Jun 2020 23:02:33 -0400 Date: Tue, 16 Jun 2020 20:02:30 -0700 From: Benjamin Kaduk To: Jim Schaad Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, "'Matthew Miller'" , "'The IESG'" , cose@ietf.org Message-ID: <20200617030230.GB11992@kduck.mit.edu> References: <159183984940.7642.3215375794743353401@ietfa.amsl.com> <004c01d64297$360aa310$a21fe930$@augustcellars.com> <20200615230443.GO11992@kduck.mit.edu> <00af01d6437f$9f30ee60$dd92cb20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00af01d6437f$9f30ee60$dd92cb20$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 03:02:43 -0000 On Mon, Jun 15, 2020 at 06:44:02PM -0700, Jim Schaad wrote: > > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Monday, June 15, 2020 4:05 PM > > To: Jim Schaad > > Cc: 'The IESG' ; draft-ietf-cose-rfc8152bis-struct@ietf.org; cose- > > chairs@ietf.org; 'Matthew Miller' ; > > cose@ietf.org > > Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis- > > struct-10: (with DISCUSS and COMMENT) > > > > Hi Jim, > > > > On Sun, Jun 14, 2020 at 03:00:23PM -0700, Jim Schaad wrote: > > > > > > > > > -----Original Message----- > > > From: Benjamin Kaduk via Datatracker > > > Sent: Wednesday, June 10, 2020 6:44 PM > > > To: The IESG > > > Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org; cose-chairs@ietf.org; > > > cose@ietf.org; Matthew Miller ; > > > linuxwolf+ietf@outer-planes.net > > > Subject: Benjamin Kaduk's Discuss on > > > draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-cose-rfc8152bis-struct-10: Discuss > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut > > > this introductory paragraph, however.) > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > (Arguably a "discuss discuss".) > > > > > > If we don't have any worked examples of signatures with message recovery, > > should we include that possibility in the Internet Standard version of the > > protocol? Some of the description around how the details of this would work > > remain unclear to me. > > > > > > [JLS] I tried a couple of times to get Kenny interested in seeing if anybody in > > CFRG wanted to pursue this and never got anywhere. This text is here as much > > to let people know that such an algorithm might be defined in the future and it > > might cause some problems if it is. > > > > > > At one point I looked at looked at writing an experimental RFC which would > > define a version of this with RSA. The padding algorithm would look like that in > > PKCS #1.5 with the following change: PS = byte count || stolen bytes || 0xff > > where byte count is the length of stolen bytes and stolen bytes are the last n > > bytes of the signed message. Where byte count is the minimum of the > > message length and (emLen - tLen - 4). I ended up not doing this because I did > > not want it to escape into the wild and I did not see any way of having people > > implement this for testing and still making sure that it was contained. > > > > > > One pointer is > > > https://crypto.stackexchange.com/questions/17802/description-of-signat > > > ures-with-message-recovery-as-in-iso-iec-9796-2-and-emv-si > > > > I was thinking specifically of worked examples for COSE usage. E.g., verifying > > that the "payload" element of SOSE_Sign interoperates, especially when the > > signature provides full message recovery and how the "message sent" and > > recovered content are reconstituted into the "message content" > > during the Verification() process. We don't give many details of how that > > would work or what an algorithm specification would need to provide in order > > to give a complete specification. > [JLS] I don't have any problems with providing such a thing using the evil signature algorithm that I outlined above on the examples website, but I don't know that it has any place in the document. I also expect that such a thing doesn't have any place in the document. But where does that leave us, though -- do we have enough knowledge+experience for how to use signature with recovery for COSE messages to merit granting it full Internet Standard status? I can't say the answer for sure, just on my own authority; hence the "discuss discuss". > > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > > > > > > > providing security services. The use of COSE, like JOSE and CMS, is > > > only in store and forward or offline protocols, different solutions > > > would be appropriate for online protocols although one can use COSE > > > in an online protocol after having done some type of online key > > > establishment process. Any application which uses COSE for > > > security > > > > > > > > > be done before sending objects back and forth. > > > [JLS] New text: > > > The use of COSE, like JOSE and CMS, is only for use in store and forward > > or offline protocols. > > > The use of COSE in online protocols needing encryption, > > > require that an online key establishment process > > > nit: comma splice (and the sentence after the comma is a bit long, too). > > > > [something doesn't seem to be showing up well in the text/plain component > > here; I'll try to take a look at the updated I-D when it lands] > > > > > additional data fields as part of the structure. A common structure > > > is going to include a URI or other pointer to where the data that is > > > being hashed is kept, allowing this to be application-specific. > > > > > > This is "common" in the sense of "a design pattern expected to be frequently > > used", not "a common baseline", right? > > > [JLS] Yes > > > > "popular" is not quite right, though maybe "oft-used"? > > [JLS] Ok - trying to change it just made me sad. Rewrote to > > A one such application-specific element would be to include a URI or other pointer to where the data that is being hashed can be obtained. Thanks, that seems better on a few axes. > > > The following CDDL fragment identifies all of the top messages > > > > > > [hmm, maybe my earlier comment about "top-level message" was > > > misguided] [JLS] see above comment. > > > > > > Section 3 > > > > > > or evaluation hints for the processing of the layer. These two > > > buckets are available for use in all of the structures except for > > > keys. While these buckets are present, they may not all be usable in > > > all instances. For example, while the protected bucket is defined > > > as > > > > > > nit: isn't "all buckets" just "both buckets"? > > > [JLS] I probably meant to rite always though. > > > > > > > > > h'a0'). The zero-length binary encoding is preferred because it > > > is both shorter and the version used in the serialization > > > structures for cryptographic computation. After encoding the > > > map, > > > > > > nit: this doesn't look like a complete sentence. > > > [JLS] The RFC editor did not object last time. Noun = encoding, verb = > > preferred. > > > > I was thinking more the parallelism in "is both and ", or perhaps that > > "shorter" invites a comparison with something unnamed ... I couldn't really pin > > my finger on it at the time. > [JLS] The options were covered in the preceding sentences and I don't know that you can get much shorter than a one byte encoding and still have existence. Okay, let's leave it for the RFC Editor. > > > > > > malformed. Applications SHOULD verify that the same label does not > > > occur in both the protected and unprotected header parameters. If > > > the message is not rejected as malformed, attributes MUST be obtained > > > from the protected bucket before they are obtained from the > > > unprotected bucket. > > > > > > I a little bit worry that "take from protected before unprotected", combined > > with "don't check for duplicates", means "last match wins" and the unprotected > > one gets used. Perhaps it's better to talk about taking precedence if both are > > present? > > > [JLS] **** I don't understand your worry here. These are separate maps and > > thus there is no "last match wins" between the two different buckets. > > > > I think this can depend on whether you see the application as doing "I am going > > to obtain all the attributes" or "I am going to get a value of attribute ". In > > the latter, you presumably stop once you get a value, here, from the protected > > bucket. In the former case, though, if you do "get all labels from the protected > > bucket, put into local cache, then get all labels from the unprotected bucket, > > put into the same cache", then a "last store wins" for the cache will do the > > wrong thing. > > If that's not a relevant "worry", sorry for the noise. > [JLS] No it is a relevant worry. There are two buckets and if you combine the buckets you had better combine them in the correct way. You are going to need to know if the cache is last wins, first wins or go boom on duplicates. I am not sure what I can say to make things clearer though. I think the core of the (potential) issue is "first" -- "first" assumes something about what procedure is being used in a way that "priority over" or "has precedence" does not, which is what I was trying to get at. (Going into more detail about the procedure to use for which "first" makes sense feels like it's going in the wrong direction.) > > > > > Section 3.1 > > > > > > alg: This header parameter is used to indicate the algorithm used > > > for the security processing. This header parameter MUST be > > > authenticated where the ability to do so exists. This support is > > > provided by AEAD algorithms or construction (COSE_Sign, > > > COSE_Sign1, COSE_Mac, and COSE_Mac0). This authentication can > > > be > > > > > > Can countersignatures authenticate 'alg'? > > > Is there an easy listing of the class of message that does *not* allow for > > authenticating 'alg'? > > > [JLS] Where to start, all of the constructions/algorithms have the ability to do > > the authentication. The use of an AE algorithm does not allow this. By > > construction, the encryption structures (Encrypt, Encrypt0 and Recipient) do not > > do this, Changed to " (e.g. COSE_Sign and COSE_Mac0)" > > > > We have a MUST-level requirement to do something "where the ability to do so > > exists". If we leave it to the reader to determine when the ability to do so > > exists, I don't expect 100% accuracy in practice, so I'm looking for a way that > > we can give clear guidance on when this protection needs to be present. > > [JLS] Where the ability does not exist is when you do an AE algorithm. It can be done everywhere else. (And don't get me started on all of the arguments that I had with the OSCORE people about how important I thought it was to do this.) Otherwise between the structure and the algorithm (AEAD) you can always do this either in the protected attributes or in external data. Brainstorming (and feel free to do something completely different, or decide that it's not worth it), maybe "(The only algorithm and message-type combinations where this ability does not exist is when an authenticated encryption only (not AEAD) symmetric cipher mode is used for a [COSE_Encrypt*, COSE_Recipient*] message.)"? > > > * Integer labels in the range -1 to -128 can be omitted as they > > > are algorithm dependent. If an application can correctly > > > process an algorithm, it can be assumed that it will > > > correctly > > > > > > Where is this sub-partitioning of the -1 to -65536 range specified, > > > that any given algorithm will only assign "critical" header parameters > > > in the > > > -1 to -128 range? If it's just convention I don't think the declarative language > > ("can be omitted") is appropriate. > > > [JLS] There is no requirement that an algorithm is restricted to that range. > > The assumption is that purely optional items might be placed farther out in the > > range and thus need to be placed in the "crit" attribute. This is just a > > restriction, similar to the 0-7 range of things that can be omitted. > > > > I agree that it's just a restriction, but the way it's written right now it feels like > > the core spec is making statements about what you should assume to be the > > case for algorithm-dependent values, without actually placing a requirement > > on the algorithm specifications to provide that property. If we said that > > algorithm specs can impose a similar requirement on which values are > > required to implement and thus safe to omit, and suggested the range of -1 to - > > 128 for those values, I wouldn't have a problem, since that makes it clear that > > it's a property of the algorithm in question. > > [JLS] Does this read better? > > Integer labels in the range -1 to -128 can be omitted. Algorithms can assign labels in this range where the ability to process the content of the label is considered to be core to implementing the algorithm. Algorithms can assign labels outside of this range where the ability to process the content of the label is not considered to be core, but needs to be understood to correctly process this instance. Integer labels in the range -129 to -65536 SHOULD be included as these would be less common header parameters that might not be generally supported. That helps, yes. Even better would be normative language, like "algorithms MUST only assign labels in this range where [...]" :) > > > > > * Labels for header parameters required for an application MAY be > > > omitted. Applications should have a statement if the label can > > > be omitted. > > > > > > nit: applications or application protocols? > > > [JLS] I am pretty sure I meant applications. > > > > I'm having trouble picturing this, but will trust you that it makes sense. > > > > > > > > A COSE Signed Message is defined in two parts. The CBOR object that > > > carries the body and information about the body is called the > > > COSE_Sign structure. The CBOR object that carries the signature > > > and > > > > > > (COSE_Sign also carries the signature parts?) [JLS] No - they are > > > carried in COSE_Signature > > > > I thought the COSE_Sign structure contained one or more COSE_Signature > > structures. > > Yes it does. I think of the "signature" as the byte string as being different from the COSE_Signature structure. This is referring to the first. Okay ... but even in this sense the "signature" is *indirectly* contained in COSE_Sign, and I at least did not get the sense from this text that we intended the "directly carries" sense of the term. Maybe we should leave a note to ask the RFC Editor for help; I'm failing to come up with a good wording right now. > > > > > Note: When a signature with a message recovery algorithm is used > > > (Section 9.1), the maximum number of bytes that can be recovered > > > is the length of the payload. The size of the payload is reduced > > > by the number of bytes that will be recovered. If all of the > > > > > > nit(?): it's the "size of the payload" *in the encoded COSE_Sign* object that is > > reduced, right? > > > [JLS] No it is the "size of the payload" as in the payload you signed. > > > > I'm having trouble parsing that -- it feels circular to me. "In the act of signing, > > the size of the payload you are signing is reduced by the number of bytes that > > will be recovered." So what's the payload, the longer thing or the shorter > > thing? > > [JLS] The payload that is encrypted is the longer thing. The payload that is carried in the COSE message is the shorter thing. Using the same word to mean different things makes the reader work. I'd support adding some adjectives, but won't insist on it. > > > > > Section 8.1 > > > > > > cryptographic operation. Note that the same key can be in a > > > different key structure with a different or no algorithm > > > specified; however, this is considered to be a poor security > > > practice. > > > > > > Depending on the answer to my question on -algs about capabilities and their > > use, this statement might need to be updated. > > > [JLS] Not clear which comment you are referring to > > > > Oops, the referred-to question was "Am I reading this right that the idea is to > > use capabilities to lock a key down to a single curve?" > [JLS] Capabilities are not used to lock a key down to a single curve. The curve is a field in the COSE_Key object. Okay, thanks for clarifying. > > > Section 9.2 > > > > > > Message Authentication Codes (MACs) provide data authentication and > > > integrity protection. They provide either no or very limited data > > > origination. A MAC, for example, cannot be used to prove the > > > identity of the sender to a third party. > > > > > > Hmm, should the s/can/cannot/ be filed as an erratum against 8152? > > > [JLS] Yes if we don't think we are going to have a fast publish. What is the > > current RFC Editor queue processing time? > > > > I think it's pushing 12 weeks, what with C238 and the bulge that accumulated in > > RFC-EDITOR (https://www.rfc-editor.org/current_queue.php). > > I'd happily approve a report if you want to file one. > [JLS] done Thanks, verified! > > > Section 9.4 > > > > > > General KDFs work well with the first type of secret, can do > > > reasonably well with the second type of secret, and generally do > > > poorly with the last type of secret. Functions like PBES2 [RFC8018] > > > need to be used for non-random secrets. > > > > > > nit: To be analogous to the previous discussion of KDFs, shouldn't we refer to > > a PBKDF construction, not PBES (which provides an abstract API for password- > > based encryption that uses PBKDF1 under the covers)? > > > (Also, my understanding is that PBKDF1 is not exactly considered > > > state-of-the-art.) > > > [JLS] Given what I said above, if you really want to change this we > > > could point to Argon2 > > > > My main complaint here is that there's a "type error" -- PBES2 is not a KDF > > (right?). I could tolerate dropping the last sentence entirely, or a bland > > "Specific KDF constructions are needed to be safely used with non-random > > secrets" (and no reference), but pointing to Argon2 would also be fine. > [JLS] Switched. > > > > > > Section 9.5.1 > > > > > > * A header parameter identifying the shared secret SHOULD be > > > present. > > > > > > What type of header parameter might do that? > > > [JLS] Will KID would be one that could do this. > > > > Do we want to provide guidance in the doc, or is "kid" sufficiently self- > > explanatory and obvious? > [JLS] I think that it is obvious. I also think something like "password hint" would be as well, but is not currently defined. Okay. > > > Section 15.1 > > > > > > [DSS] has only one usage now in -struct, which doesn't seem normative. > > > I'd expect it to only be normative in -algs. > > > Likewise for RFC 8032. > > > [JLS] Done > > > > > > It's also interesting to make a normative reference to -algs, which will be an > > informational RFC when published (given the current intended status). Are we > > creating it directly onto the downrefs registry? > > > [JLS] I could move the reference without any problems. However, putting it > > directly in to the downref registry is probably a good idea so that protocol > > documents can make algorithms MUST. > > > > I think we had someone (Barry?) mention on the telechat that we might not > > need to put it in the registry since it was unclear who else would need to > > reference it. So, thanks for stating a position -- I trust that the responsible AD > > will do the right thing. > > > > > Appendix A > > > > > > side note: it seems like any scheme for conveying information about what > > algorithm to use other than "implicit by key with each key limited to one > > algorithm" has some risk of allowing an attacker's input to cause the key holder > > to perform some operation using that key but with the "wrong" algorithm. I > > think that if the externally visible results of that operation are indistinguishable > > from "the input was ignored", that does not give the attacker a channel by > > which to attack the key, but I'm not 100% sure. Even an application-layer > > "rejected due to bad input" > > > might be enough of a lever to enable some types of attack. > > > [JLS] The current CoRE group communication document is breaking the "one > > key one algorithm" rule although in an offline way. At least for OSCORE, there > > would not be a way to distinguish between any of the "it did not decrypt" cases. > > > > Sigh. I wonder if I can convince any cryptographers to look at the group > > communication document. > > [JLS] That is not where I would put the limited resources. I would have them look at draft-ietf-lwig-curve-representations and ask if there are issues using the same private key for an EdDSA signature and ECDH after doing the mapping. I think I recently saw something on the CFRG list which had a pointer to a paper saying that reuse for ECDH and ECDSA was ok. Fair enough. Thanks, as always, Ben From nobody Tue Jun 16 20:42:16 2020 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 3D0AB3A0E1D; Tue, 16 Jun 2020 20:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 vaCHq4US-6Ke; Tue, 16 Jun 2020 20:42:07 -0700 (PDT) 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 328023A0E1A; Tue, 16 Jun 2020 20:42:06 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 16 Jun 2020 20:41:58 -0700 From: Jim Schaad To: 'Benjamin Kaduk' CC: , , 'Matthew Miller' , 'The IESG' , References: <159183984940.7642.3215375794743353401@ietfa.amsl.com> <004c01d64297$360aa310$a21fe930$@augustcellars.com> <20200615230443.GO11992@kduck.mit.edu> <00af01d6437f$9f30ee60$dd92cb20$@augustcellars.com> <20200617030230.GB11992@kduck.mit.edu> In-Reply-To: <20200617030230.GB11992@kduck.mit.edu> Date: Tue, 16 Jun 2020 20:41:56 -0700 Message-ID: <011201d64459$41f2af10$c5d80d30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLLhK51vaVhQCr2j2FaHM+f5QWv3gIn/U8/AYBLdn4B16I9JQI/MdrVprOqjyA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 03:42:10 -0000 I think this is everything except for you discuss-discuss. Jim > -----Original Message----- > From: Benjamin Kaduk > Sent: Tuesday, June 16, 2020 8:03 PM > To: Jim Schaad > Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org; cose-chairs@ietf.org; 'Matthew > Miller' ; 'The IESG' ; > cose@ietf.org > Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis- > struct-10: (with DISCUSS and COMMENT) > > On Mon, Jun 15, 2020 at 06:44:02PM -0700, Jim Schaad wrote: > > > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Monday, June 15, 2020 4:05 PM > > > To: Jim Schaad > > > Cc: 'The IESG' ; > > > draft-ietf-cose-rfc8152bis-struct@ietf.org; cose- chairs@ietf.org; > > > 'Matthew Miller' ; > > > cose@ietf.org > > > Subject: Re: [COSE] Benjamin Kaduk's Discuss on > > > draft-ietf-cose-rfc8152bis- > > > struct-10: (with DISCUSS and COMMENT) > > > > > > Hi Jim, > > > > > > On Sun, Jun 14, 2020 at 03:00:23PM -0700, Jim Schaad wrote: > > > > > > > > > > > > -----Original Message----- > > > > From: Benjamin Kaduk via Datatracker > > > > Sent: Wednesday, June 10, 2020 6:44 PM > > > > To: The IESG > > > > Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org; > > > > cose-chairs@ietf.org; cose@ietf.org; Matthew Miller > > > > ; > > > > linuxwolf+ietf@outer-planes.net > > > > Subject: Benjamin Kaduk's Discuss on > > > > draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-cose-rfc8152bis-struct-10: Discuss > > > > > > > > When responding, please keep the subject line intact and reply to > > > > all email addresses included in the To and CC lines. (Feel free to > > > > cut this introductory paragraph, however.) > > > > > > > > > > > > Please refer to > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct > > > > / > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > ---- > > > > DISCUSS: > > > > ------------------------------------------------------------------ > > > > ---- > > > > > > > > (Arguably a "discuss discuss".) > > > > > > > > If we don't have any worked examples of signatures with message > > > > recovery, > > > should we include that possibility in the Internet Standard version > > > of the protocol? Some of the description around how the details of > > > this would work remain unclear to me. > > > > > > > > [JLS] I tried a couple of times to get Kenny interested in seeing > > > > if anybody in > > > CFRG wanted to pursue this and never got anywhere. This text is > > > here as much to let people know that such an algorithm might be > > > defined in the future and it might cause some problems if it is. > > > > > > > > At one point I looked at looked at writing an experimental RFC > > > > which would > > > define a version of this with RSA. The padding algorithm would look > > > like that in PKCS #1.5 with the following change: PS = byte count > > > || stolen bytes || 0xff where byte count is the length of stolen > > > bytes and stolen bytes are the last n bytes of the signed message. > > > Where byte count is the minimum of the message length and (emLen - > > > tLen - 4). I ended up not doing this because I did not want it to > > > escape into the wild and I did not see any way of having people implement > this for testing and still making sure that it was contained. > > > > > > > > One pointer is > > > > https://crypto.stackexchange.com/questions/17802/description-of-si > > > > gnat ures-with-message-recovery-as-in-iso-iec-9796-2-and-emv-si > > > > > > I was thinking specifically of worked examples for COSE usage. > > > E.g., verifying that the "payload" element of SOSE_Sign > > > interoperates, especially when the signature provides full message > > > recovery and how the "message sent" and recovered content are > reconstituted into the "message content" > > > during the Verification() process. We don't give many details of > > > how that would work or what an algorithm specification would need to > > > provide in order to give a complete specification. > > [JLS] I don't have any problems with providing such a thing using the evil > signature algorithm that I outlined above on the examples website, but I don't > know that it has any place in the document. > > I also expect that such a thing doesn't have any place in the document. > > But where does that leave us, though -- do we have enough > knowledge+experience for how to use signature with recovery for COSE > messages to merit granting it full Internet Standard status? I can't say the > answer for sure, just on my own authority; hence the "discuss discuss". > Well - I think that I do. I did play with this at one point which is why there are a number of - if you do this then ... statements in the draft. I don't think that there is anything in the base COSE document that is going to care about signature with recovery and the details can be left to an algorithm description when we get one. YMMV > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > ---- > > > > COMMENT: > > > > ------------------------------------------------------------------ > > > > ---- > > > > > > > > > > > > > > > > providing security services. The use of COSE, like JOSE and CMS, is > > > > only in store and forward or offline protocols, different solutions > > > > would be appropriate for online protocols although one can use COSE > > > > in an online protocol after having done some type of online key > > > > establishment process. Any application which uses COSE for > > > > security > > > > > > > > > > > > be done before sending objects back and forth. > > > > [JLS] New text: > > > > The use of COSE, like JOSE and CMS, is only for use in > > > > store and forward > > > or offline protocols. > > > > The use of COSE in online protocols needing encryption, > > > > require that an online key establishment process > > > > nit: comma splice (and the sentence after the comma is a bit long, too). > > > > > > [something doesn't seem to be showing up well in the text/plain > > > component here; I'll try to take a look at the updated I-D when it > > > lands] > > > > > > > additional data fields as part of the structure. A common structure > > > > is going to include a URI or other pointer to where the data that is > > > > being hashed is kept, allowing this to be application-specific. > > > > > > > > This is "common" in the sense of "a design pattern expected to be > > > > frequently > > > used", not "a common baseline", right? > > > > [JLS] Yes > > > > > > "popular" is not quite right, though maybe "oft-used"? > > > > [JLS] Ok - trying to change it just made me sad. Rewrote to > > > > A one such application-specific element would be to include a URI or > other pointer to where the data that is being hashed can be obtained. > > Thanks, that seems better on a few axes. > > > > > The following CDDL fragment identifies all of the top messages > > > > > > > > [hmm, maybe my earlier comment about "top-level message" was > > > > misguided] [JLS] see above comment. > > > > > > > > Section 3 > > > > > > > > or evaluation hints for the processing of the layer. These two > > > > buckets are available for use in all of the structures except for > > > > keys. While these buckets are present, they may not all be usable in > > > > all instances. For example, while the protected bucket is > > > > defined as > > > > > > > > nit: isn't "all buckets" just "both buckets"? > > > > [JLS] I probably meant to rite always though. > > > > > > > > > > > > h'a0'). The zero-length binary encoding is preferred because it > > > > is both shorter and the version used in the serialization > > > > structures for cryptographic computation. After encoding > > > > the map, > > > > > > > > nit: this doesn't look like a complete sentence. > > > > [JLS] The RFC editor did not object last time. Noun = encoding, > > > > verb = > > > preferred. > > > > > > I was thinking more the parallelism in "is both and ", or > > > perhaps that "shorter" invites a comparison with something unnamed > > > ... I couldn't really pin my finger on it at the time. > > [JLS] The options were covered in the preceding sentences and I don't know > that you can get much shorter than a one byte encoding and still have > existence. > > Okay, let's leave it for the RFC Editor. > > > > > > > > > malformed. Applications SHOULD verify that the same label does not > > > > occur in both the protected and unprotected header parameters. If > > > > the message is not rejected as malformed, attributes MUST be obtained > > > > from the protected bucket before they are obtained from the > > > > unprotected bucket. > > > > > > > > I a little bit worry that "take from protected before > > > > unprotected", combined > > > with "don't check for duplicates", means "last match wins" and the > > > unprotected one gets used. Perhaps it's better to talk about taking > > > precedence if both are present? > > > > [JLS] **** I don't understand your worry here. These are separate > > > > maps and > > > thus there is no "last match wins" between the two different buckets. > > > > > > I think this can depend on whether you see the application as doing > > > "I am going to obtain all the attributes" or "I am going to get a > > > value of attribute ". In the latter, you presumably stop once > > > you get a value, here, from the protected bucket. In the former > > > case, though, if you do "get all labels from the protected bucket, > > > put into local cache, then get all labels from the unprotected > > > bucket, put into the same cache", then a "last store wins" for the cache will > do the wrong thing. > > > If that's not a relevant "worry", sorry for the noise. > > [JLS] No it is a relevant worry. There are two buckets and if you combine the > buckets you had better combine them in the correct way. You are going to > need to know if the cache is last wins, first wins or go boom on duplicates. I am > not sure what I can say to make things clearer though. > > I think the core of the (potential) issue is "first" -- "first" assumes something > about what procedure is being used in a way that "priority over" > or "has precedence" does not, which is what I was trying to get at. (Going into > more detail about the procedure to use for which "first" makes sense feels like > it's going in the wrong direction.) How about /before they are obtained/and only if not present should they be obtained/ > > > > > > > > Section 3.1 > > > > > > > > alg: This header parameter is used to indicate the algorithm used > > > > for the security processing. This header parameter MUST be > > > > authenticated where the ability to do so exists. This support is > > > > provided by AEAD algorithms or construction (COSE_Sign, > > > > COSE_Sign1, COSE_Mac, and COSE_Mac0). This authentication > > > > can be > > > > > > > > Can countersignatures authenticate 'alg'? > > > > Is there an easy listing of the class of message that does *not* > > > > allow for > > > authenticating 'alg'? > > > > [JLS] Where to start, all of the constructions/algorithms have the > > > > ability to do > > > the authentication. The use of an AE algorithm does not allow this. > > > By construction, the encryption structures (Encrypt, Encrypt0 and Recipient) > do not > > > do this, Changed to " (e.g. COSE_Sign and COSE_Mac0)" > > > > > > We have a MUST-level requirement to do something "where the ability > > > to do so exists". If we leave it to the reader to determine when > > > the ability to do so exists, I don't expect 100% accuracy in > > > practice, so I'm looking for a way that we can give clear guidance on when > this protection needs to be present. > > > > [JLS] Where the ability does not exist is when you do an AE algorithm. It can > be done everywhere else. (And don't get me started on all of the arguments > that I had with the OSCORE people about how important I thought it was to do > this.) Otherwise between the structure and the algorithm (AEAD) you can > always do this either in the protected attributes or in external data. > > Brainstorming (and feel free to do something completely different, or decide > that it's not worth it), maybe "(The only algorithm and message-type > combinations where this ability does not exist is when an authenticated > encryption only (not AEAD) symmetric cipher mode is used for a > [COSE_Encrypt*, COSE_Recipient*] message.)"? > > > > > * Integer labels in the range -1 to -128 can be omitted as they > > > > are algorithm dependent. If an application can correctly > > > > process an algorithm, it can be assumed that it will > > > > correctly > > > > > > > > Where is this sub-partitioning of the -1 to -65536 range > > > > specified, that any given algorithm will only assign "critical" > > > > header parameters in the > > > > -1 to -128 range? If it's just convention I don't think the > > > > declarative language > > > ("can be omitted") is appropriate. > > > > [JLS] There is no requirement that an algorithm is restricted to that range. > > > The assumption is that purely optional items might be placed farther > > > out in the range and thus need to be placed in the "crit" attribute. > > > This is just a restriction, similar to the 0-7 range of things that can be > omitted. > > > > > > I agree that it's just a restriction, but the way it's written right > > > now it feels like the core spec is making statements about what you > > > should assume to be the case for algorithm-dependent values, without > > > actually placing a requirement on the algorithm specifications to > > > provide that property. If we said that algorithm specs can impose a > > > similar requirement on which values are required to implement and > > > thus safe to omit, and suggested the range of -1 to - > > > 128 for those values, I wouldn't have a problem, since that makes it > > > clear that it's a property of the algorithm in question. > > > > [JLS] Does this read better? > > > > Integer labels in the range -1 to -128 can be omitted. Algorithms can assign > labels in this range where the ability to process the content of the label is > considered to be core to implementing the algorithm. Algorithms can assign > labels outside of this range where the ability to process the content of the label > is not considered to be core, but needs to be understood to correctly process > this instance. Integer labels in the range -129 to -65536 > SHOULD be included as these would be less common header > parameters that might not be generally supported. > > That helps, yes. Even better would be normative language, like "algorithms > MUST only assign labels in this range where [...]" :) My problem with a MUST is that I don't know what it means to be "core to implementing". I think that is too vague to make the MUST useful. > > > > > > > > * Labels for header parameters required for an application MAY be > > > > omitted. Applications should have a statement if the label can > > > > be omitted. > > > > > > > > nit: applications or application protocols? > > > > [JLS] I am pretty sure I meant applications. > > > > > > I'm having trouble picturing this, but will trust you that it makes sense. > > > > > > > > > > > A COSE Signed Message is defined in two parts. The CBOR object that > > > > carries the body and information about the body is called the > > > > COSE_Sign structure. The CBOR object that carries the > > > > signature and > > > > > > > > (COSE_Sign also carries the signature parts?) [JLS] No - they are > > > > carried in COSE_Signature > > > > > > I thought the COSE_Sign structure contained one or more > > > COSE_Signature structures. > > > > Yes it does. I think of the "signature" as the byte string as being different > from the COSE_Signature structure. This is referring to the first. > > Okay ... but even in this sense the "signature" is *indirectly* contained in > COSE_Sign, and I at least did not get the sense from this text that we intended > the "directly carries" sense of the term. Maybe we should leave a note to ask > the RFC Editor for help; I'm failing to come up with a good wording right now. > I am sure they will love me for this. > > > > > > > Note: When a signature with a message recovery algorithm is used > > > > (Section 9.1), the maximum number of bytes that can be recovered > > > > is the length of the payload. The size of the payload is reduced > > > > by the number of bytes that will be recovered. If all of > > > > the > > > > > > > > nit(?): it's the "size of the payload" *in the encoded COSE_Sign* > > > > object that is > > > reduced, right? > > > > [JLS] No it is the "size of the payload" as in the payload you signed. > > > > > > I'm having trouble parsing that -- it feels circular to me. "In the > > > act of signing, the size of the payload you are signing is reduced > > > by the number of bytes that will be recovered." So what's the > > > payload, the longer thing or the shorter thing? > > > > [JLS] The payload that is encrypted is the longer thing. The payload that is > carried in the COSE message is the shorter thing. > > Using the same word to mean different things makes the reader work. I'd > support adding some adjectives, but won't insist on it. [JLS] Not a big issue - added "original" and "transmitted" as appropriate. > > > > > > > > Section 8.1 > > > > > > > > cryptographic operation. Note that the same key can be in a > > > > different key structure with a different or no algorithm > > > > specified; however, this is considered to be a poor security > > > > practice. > > > > > > > > Depending on the answer to my question on -algs about capabilities > > > > and their > > > use, this statement might need to be updated. > > > > [JLS] Not clear which comment you are referring to > > > > > > Oops, the referred-to question was "Am I reading this right that the > > > idea is to use capabilities to lock a key down to a single curve?" > > [JLS] Capabilities are not used to lock a key down to a single curve. The curve > is a field in the COSE_Key object. > > Okay, thanks for clarifying. > > > > > Section 9.2 > > > > > > > > Message Authentication Codes (MACs) provide data authentication and > > > > integrity protection. They provide either no or very limited data > > > > origination. A MAC, for example, cannot be used to prove the > > > > identity of the sender to a third party. > > > > > > > > Hmm, should the s/can/cannot/ be filed as an erratum against 8152? > > > > [JLS] Yes if we don't think we are going to have a fast publish. > > > > What is the > > > current RFC Editor queue processing time? > > > > > > I think it's pushing 12 weeks, what with C238 and the bulge that > > > accumulated in RFC-EDITOR (https://www.rfc- > editor.org/current_queue.php). > > > I'd happily approve a report if you want to file one. > > [JLS] done > > Thanks, verified! > > > > > Section 9.4 > > > > > > > > General KDFs work well with the first type of secret, can do > > > > reasonably well with the second type of secret, and generally do > > > > poorly with the last type of secret. Functions like PBES2 [RFC8018] > > > > need to be used for non-random secrets. > > > > > > > > nit: To be analogous to the previous discussion of KDFs, shouldn't > > > > we refer to > > > a PBKDF construction, not PBES (which provides an abstract API for > > > password- based encryption that uses PBKDF1 under the covers)? > > > > (Also, my understanding is that PBKDF1 is not exactly considered > > > > state-of-the-art.) > > > > [JLS] Given what I said above, if you really want to change this > > > > we could point to Argon2 > > > > > > My main complaint here is that there's a "type error" -- PBES2 is > > > not a KDF (right?). I could tolerate dropping the last sentence > > > entirely, or a bland "Specific KDF constructions are needed to be > > > safely used with non-random secrets" (and no reference), but pointing to > Argon2 would also be fine. > > [JLS] Switched. > > > > > > > > > Section 9.5.1 > > > > > > > > * A header parameter identifying the shared secret SHOULD be > > > > present. > > > > > > > > What type of header parameter might do that? > > > > [JLS] Will KID would be one that could do this. > > > > > > Do we want to provide guidance in the doc, or is "kid" sufficiently > > > self- explanatory and obvious? > > [JLS] I think that it is obvious. I also think something like "password hint" > would be as well, but is not currently defined. > > Okay. > > > > > Section 15.1 > > > > > > > > [DSS] has only one usage now in -struct, which doesn't seem normative. > > > > I'd expect it to only be normative in -algs. > > > > Likewise for RFC 8032. > > > > [JLS] Done > > > > > > > > It's also interesting to make a normative reference to -algs, > > > > which will be an > > > informational RFC when published (given the current intended > > > status). Are we creating it directly onto the downrefs registry? > > > > [JLS] I could move the reference without any problems. However, > > > > putting it > > > directly in to the downref registry is probably a good idea so that > > > protocol documents can make algorithms MUST. > > > > > > I think we had someone (Barry?) mention on the telechat that we > > > might not need to put it in the registry since it was unclear who > > > else would need to reference it. So, thanks for stating a position > > > -- I trust that the responsible AD will do the right thing. > > > > > > > Appendix A > > > > > > > > side note: it seems like any scheme for conveying information > > > > about what > > > algorithm to use other than "implicit by key with each key limited > > > to one algorithm" has some risk of allowing an attacker's input to > > > cause the key holder to perform some operation using that key but > > > with the "wrong" algorithm. I think that if the externally visible > > > results of that operation are indistinguishable from "the input was > > > ignored", that does not give the attacker a channel by which to > > > attack the key, but I'm not 100% sure. Even an application-layer "rejected > due to bad input" > > > > might be enough of a lever to enable some types of attack. > > > > [JLS] The current CoRE group communication document is breaking > > > > the "one > > > key one algorithm" rule although in an offline way. At least for > > > OSCORE, there would not be a way to distinguish between any of the "it did > not decrypt" cases. > > > > > > Sigh. I wonder if I can convince any cryptographers to look at the > > > group communication document. > > > > [JLS] That is not where I would put the limited resources. I would have them > look at draft-ietf-lwig-curve-representations and ask if there are issues using > the same private key for an EdDSA signature and ECDH after doing the > mapping. I think I recently saw something on the CFRG list which had a pointer > to a paper saying that reuse for ECDH and ECDSA was ok. > > Fair enough. > > Thanks, as always, > > Ben From nobody Tue Jun 16 22:06:45 2020 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 131143A0E99; Tue, 16 Jun 2020 22:06:37 -0700 (PDT) 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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ECT4l1whHpYI; Tue, 16 Jun 2020 22:06:35 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA283A0965; Tue, 16 Jun 2020 22:06:35 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05H56Rds027441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Jun 2020 01:06:29 -0400 Date: Tue, 16 Jun 2020 22:06:26 -0700 From: Benjamin Kaduk To: Jim Schaad Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, "'Matthew Miller'" , "'The IESG'" , cose@ietf.org Message-ID: <20200617050626.GK11992@kduck.mit.edu> References: <159183984940.7642.3215375794743353401@ietfa.amsl.com> <004c01d64297$360aa310$a21fe930$@augustcellars.com> <20200615230443.GO11992@kduck.mit.edu> <00af01d6437f$9f30ee60$dd92cb20$@augustcellars.com> <20200617030230.GB11992@kduck.mit.edu> <011201d64459$41f2af10$c5d80d30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011201d64459$41f2af10$c5d80d30$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 05:06:37 -0000 On Tue, Jun 16, 2020 at 08:41:56PM -0700, Jim Schaad wrote: > I think this is everything except for you discuss-discuss. Perhaps we should put it on the next telechat as a returning item to get some full-IESG time. (IIUC it needs another person balloting to hit the 2/3 criterion anyway, even after Roman and I clear.) -Ben From nobody Thu Jun 18 06:11:10 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFC43A0D89; Thu, 18 Jun 2020 06:11:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller , linuxwolf+ietf@outer-planes.net X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <159248586834.11403.17621451636544873207@ietfa.amsl.com> Date: Thu, 18 Jun 2020 06:11:08 -0700 Archived-At: Subject: [COSE] Magnus Westerlund's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 13:11:09 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-cose-rfc8152bis-struct-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Sorry for the late discuss, however rather than deferring the review two weeks we agreed that I would do a later review. This relates to the registries created in RFC 8152. These registries do exist, however the registry rules will not be documented in the replacement standards track document that is in force. And if you look at the IANA page for the COSE regsistries (https://www.iana.org/assignments/cose/cose.xhtml#algorithms), they simply reference back to RFC 8152 which after approval of this document will be an obsoleted RFC. Thus, I am of the opinion that the rules for expert review and other registration rules for an IETF created registry should exist in an current in force RFC that is referenced by the registry. Thus, I would propose that the registration rule texts from Section 16 in RFC 8152 is included in Section 12 of this document and also request the IANA to update the registry references to point to the new document. From nobody Thu Jun 18 10:23:00 2020 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 2B23D3A0D86; Thu, 18 Jun 2020 10:22:47 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=myidemia.onmicrosoft.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 B9vwgQ_M4pMI; Thu, 18 Jun 2020 10:22:45 -0700 (PDT) Received: from mx07-0018b601.pphosted.com (mx07-0018b601.pphosted.com [185.132.180.32]) (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 6B8C33A0D7C; Thu, 18 Jun 2020 10:22:43 -0700 (PDT) Received: from pps.filterd (m0136515.ppops.net [127.0.0.1]) by mx08-0018b601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05IHEW54031850; Thu, 18 Jun 2020 17:22:31 GMT Received: from eur03-am5-obe.outbound.protection.outlook.com (mail-am5eur03lp2056.outbound.protection.outlook.com [104.47.8.56]) by mx08-0018b601.pphosted.com with ESMTP id 31r970rdmc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Jun 2020 17:22:31 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DQxMm0ZdqJXelb80OqQqEDzrPAkT5SOzgSGhIQ4GbrSol0gpjimD6EA3qZcVbPqwDRz37S7QqprlkKLkA6eIxjzgGdChmTr1RYmmeEQa2ACPBTOzF3jR8OEMVDbz44/pEs71QIz63Hxsm2okC7M9arasHPeCvqQLvU8AoObBZ19mmNMVsdcBFqAyKidv27VJg8q0JQD5Qgm/XG74sYfOHGs2sJdrFS+tArn0PfGDyO6+XCi7ovmr5mziFi9vf+cfvN7VsAoJ5yKMl5s7RT3Eqq8l+kbJ7cf3J5sLETtWDMg5Rgq4UQxQTEpU2dtbCbb2qm0xT4q2OSXuQwF745tgrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K+majwnhgzBDuIkyqs20bxXIFHqJ8pcTOB+j2/LyNQc=; b=iQgUiWK9fVnHySTInw+odTWcRFCqLVMVus+0Nm/hQWe+ydQbRJ0rVHplOl46b54H3dUf4Yj7cS3jymFsT4wqkQf565777w3ytnxoiU5Z7rq1wyxRtmqRwj4IimeslH9iO2hlB6cgmmbX1Yho6U/ovarHGUJFR4jJaLOBAqi5dTFNPeDgirs1gIYqByvmUipxCJvNKMoNxJNuPkTHkokfU6VbQ26qMwXE0GbRqKoWWYLHaNF9Gh87yPH5YKCay42VQ8zVlT52Zdj58m2RW+y7UHofpK0zmuJ6dzIV4KO179tlPRNnZ8k1e8n3dvIAmTWYCNXqr+qyRGQwVWYULyRZow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=idemia.com; dmarc=pass action=none header.from=idemia.com; dkim=pass header.d=idemia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=myidemia.onmicrosoft.com; s=selector1-myidemia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K+majwnhgzBDuIkyqs20bxXIFHqJ8pcTOB+j2/LyNQc=; b=WE1vvu///BGx6A6+r96ARykHqb7JwDt6yGhWsKf7xZmiEoXW58O62V/Q8jRFDI+w5aP07ai6NjdMJACJFSthWHhaaJuXZjtjWutzMLMHQHerlk0mLUM6NQSNuVNIE19JLSsdpE+/m9cR6QT29JQcXyq63CQOqOhUkDnKX5xFD/0= Received: from PR3P189MB1052.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:46::16) by PR3P189MB0874.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:29::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Thu, 18 Jun 2020 17:22:29 +0000 Received: from PR3P189MB1052.EURP189.PROD.OUTLOOK.COM ([fe80::c0e2:2b6e:d67b:772c]) by PR3P189MB1052.EURP189.PROD.OUTLOOK.COM ([fe80::c0e2:2b6e:d67b:772c%2]) with mapi id 15.20.3109.021; Thu, 18 Jun 2020 17:22:29 +0000 From: DESPERRIER Jean-Marc To: Jim Schaad , 'Benjamin Kaduk' CC: "draft-ietf-cose-rfc8152bis-struct@ietf.org" , "cose-chairs@ietf.org" , 'Matthew Miller' , 'The IESG' , "cose@ietf.org" Thread-Topic: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) Thread-Index: AQHWP5HWYMx0dsxxqkKUJSenlcfm0ajYr0OAgAGkT4CAACyDAIABqEEAgAALBQCAAk6dUA== Date: Thu, 18 Jun 2020 17:22:29 +0000 Message-ID: References: <159183984940.7642.3215375794743353401@ietfa.amsl.com> <004c01d64297$360aa310$a21fe930$@augustcellars.com> <20200615230443.GO11992@kduck.mit.edu> <00af01d6437f$9f30ee60$dd92cb20$@augustcellars.com> <20200617030230.GB11992@kduck.mit.edu> <011201d64459$41f2af10$c5d80d30$@augustcellars.com> In-Reply-To: <011201d64459$41f2af10$c5d80d30$@augustcellars.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_431684b1-a5da-4051-9fb4-5631703e02d5_Enabled=True; MSIP_Label_431684b1-a5da-4051-9fb4-5631703e02d5_Name=Public authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=idemia.com; x-originating-ip: [165.225.76.96] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2ae818e6-8eed-48b6-c2cc-08d813ac2df0 x-ms-traffictypediagnostic: PR3P189MB0874: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0438F90F17 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IOu4XmVo6bxzCX7lkfCv+tPqmSQQoJx7SqujVUqyIDuq3g26YY0kq/PG54P3D3SQCMxKLg+Ylk00Jj8+O2cWXmm6jt1e5gsH1FFUdYr9mEFeSiIxUeZN62NfIvNvBKSyaEGLIDVcl7INwqI3bhMx63EEumJUZBp2UO//heJr3/Ys4qaa1s+l9LBXcCxUJuNMtFym/LT0iOE0p6wW30eGoTakMUSQ2LJTl5mIMX7oRmx30SzoEOiUjtB2B2AkqyvxBOKeFuAnNH5CS3l+LjXwYklEjCFRMyIYlR5EECJkBoaIF37xVUXVPkM8eQvZOMXYVtDRPbYYrhF4xEW66TLKlw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3P189MB1052.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(376002)(346002)(366004)(8676002)(33656002)(4326008)(71200400001)(2906002)(55016002)(186003)(26005)(54906003)(8936002)(5660300002)(66946007)(110136005)(478600001)(9686003)(83380400001)(76116006)(7696005)(52536014)(55236004)(86362001)(316002)(66556008)(64756008)(6506007)(66446008)(66476007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 21geQovNuqeCsHNRW6+X9P1e2M8Jd+fnl/3FQ6Y8EzRwC4nLLqsKfHV+B8Zw9B1bwqwrEDbpFZNlUVys991DGtBPD10n7DhrtM+PaePvg475FzXiH1VwIxRfR+WFsiRn6t4cDbHLsQrmQkBSoM8ruWpgT6Yw0hKBFmMRmKJmRKz25oi1H38nl+ktZ/gnllmQ6Es6DsmNJX/PlovGbBQ1ZbJQFv+wbjUirC3gfWg22KFnQOMDQPXlSHd4E+R4b2pKJe36oa4oCrmMx4j1mQvl2tX9n79hlVUFmbqunYPKeUaw30MqThKxValuB/9TNZaeu4hB5wpWYxT9QOMgtYCj4UoOtiTNDtBuZF4Bf4J8oUu/ci7X1kpbgFKOWw3n2D45FVwzBRdvxBvGctK8Gjm7RR5I1wa1L5boq1OP61woTiG5+dfYNx0eMp74w6DARXb+yRXHGOHpmhPCEYYi3zoX7TOYbuD+Wz7F+6ahsZG1uhE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: idemia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2ae818e6-8eed-48b6-c2cc-08d813ac2df0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 17:22:29.7567 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7694d41c-5504-43d9-9e40-cb254ad755ec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NW+kyF0UuUu8mzUDWUi4jP1ruBUYUPJPDeVl3UoL+HToECWUV2facMogmYr0eabbkOad1gXuogLSYB09oba/bQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P189MB0874 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9656 signatures=668680 X-Proofpoint-Spam-Details: rule=outbound_idemia_notspam policy=outbound_idemia score=0 malwarescore=0 impostorscore=0 mlxlogscore=999 cotscore=-2147483648 lowpriorityscore=0 clxscore=1011 bulkscore=0 suspectscore=0 phishscore=0 spamscore=0 adultscore=0 priorityscore=1501 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006180131 Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 17:22:54 -0000 SGksDQoNClNvcnJ5IHRoaXMgaXMgYSBjb21tZW50IGNvbWluZyB2ZXJ5IGxhdGUsIGJ1dCBJJ20g YWZyYWlkIEkgaGF2ZSBpZGVudGlmaWVkIGEgdmVyeSBzZXJpb3VzIGlzc3VlIHdpdGggY291bnRl ciBzaWduYXR1cmVzIHRoYXQgSSB3aXNoIHRvIHJpc2UgaGVyZSBhcyBpdCBzZWVtcyB0byBtZSB0 byBiZSBpbXBvcnRhbnQuDQpJIHdvdWxkIGJlIHJlYWxseSBoYXBweSB0byBiZSB0b3RhbGx5IHdy b25nIGFib3V0IGl0LCBidXQgdGhhdCB3b3VsZCByZXF1aXJlIGEgdmVyeSBkZWVwIG1pc3VuZGVy c3RhbmRpbmcgYWJvdXQgdGhlbSB0aGF0IHdvdWxkIGluIGFueSBjYXNlIHJlcXVpcmUgc29tZSBj bGFyaWZpY2F0aW9ucyBpbiB0aGUgdGV4dC4NCg0KSSBoYXZlIHNlZW4gdGhpcyBhY3R1YWxseSBz b21lIHdlZWtzIGFnbywgYnV0IHVudGlsIG5vdyBzb21lIG9mIHRoZSB0ZXh0IGFib3V0IGNvdW50 ZXJzaWduYXR1cmVzIGdvdCBtZSBzbyBjb25mdXNlZCBJIHdhc24ndCBzdXJlIEkgZGlkbid0IHdy b25nbHkgaW50ZXJwcmV0IG1ham9yIHBhcnRzIG9mIGl0Lg0KDQpTbyBoZXJlJ3MgbXkgcmVhZGlu ZyBzdGVwIGJ5IHN0ZXAgb2YgdGhlIHNwZWNpZmljYXRpb25zIGFib3V0IGNvdW50ZXJzaWduYXR1 cmUsIGFuZCB3aHkgSSBoYXZlIGFuIGlzc3VlIHdpdGggaXQgb2YgYSBjb250cmFkaWN0aW9uIGJl dHdlZW4gd2hhdCBpdCBzYXlzIGlzIGludGVuZGVkIHRvIGFuZCB3aGF0IGlzIHJlYWxseSBhY2hp ZXZlZCwgYW5kIGFsc28gZm9yIG1lIGRlZXAgdW5jbGFyaXR5IGFib3V0IHdoYXQgdGhlIHBheWxv YWQgb2YgYSBjb3VudGVyc2lnbmF0dXJlIGNvbnNpc3RzIG9mIDoNCg0KLS0tLS0tLS0tDQozLjEu ICBDb21tb24gQ09TRSBIZWFkZXIgUGFyYW1ldGVycw0KICAgICAgVGhlIGNvdW50ZXIgc2lnbmF0 dXJlIGhlYWRlcg0KICAgICAgcGFyYW1ldGVyIGNhbiBvY2N1ciBhcyBhbiB1bnByb3RlY3RlZCBh dHRyaWJ1dGUgaW4gYW55IG9mIHRoZQ0KICAgICAgZm9sbG93aW5nIHN0cnVjdHVyZXM6IENPU0Vf U2lnbjEsIENPU0VfU2lnbmF0dXJlLCBDT1NFX0VuY3J5cHQsDQogICAgICBDT1NFX3JlY2lwaWVu dCwgQ09TRV9FbmNyeXB0MCwgQ09TRV9NYWMsIGFuZCBDT1NFX01hYzAuIFRoZXNlDQogICAgICBz dHJ1Y3R1cmVzIGFsbCBoYXZlIHRoZSBzYW1lIGJlZ2lubmluZyBlbGVtZW50cywgc28gdGhhdCBh DQogICAgICBjb25zaXN0ZW50IGNhbGN1bGF0aW9uIG9mIHRoZSBjb3VudGVyIHNpZ25hdHVyZSBj YW4gYmUgY29tcHV0ZWQuDQogICAgICBEZXRhaWxzIG9uIGNvdW50ZXIgc2lnbmF0dXJlcyBhcmUg Zm91bmQgaW4gU2VjdGlvbiA1DQoNCk5vbmV0aGVsZXNzLCB0aGV5IGFyZSBkaWZmZXJlbmNlcyBi ZXR3ZWVuIHRob3NlIGZvcm1hdHMgdGhhdCBhdCBsZWFzdCBpbXBhY3QgdGhlIHBheWxvYWQsIGFu ZCB0aGUgdGV4dCBkb2Vzbid0IGNsYXJpZnkgZXhwbGljaXRseSBob3cgdGhleSBpbXBhY3QgY291 bnRlci1zaWduYXR1cmVzDQoNCi0tLS0tLS0tLQ0KNS4gIENvdW50ZXIgU2lnbmF0dXJlcw0KDQog ICBBIGNvdW50ZXIgc2lnbmF0dXJlIGlzIG5vcm1hbGx5IGRlZmluZWQgYXMgYSBzZWNvbmQgc2ln bmF0dXJlIHRoYXQNCiAgIGNvbmZpcm1zIGEgcHJpbWFyeSBzaWduYXR1cmUuICBBIG5vcm1hbCBl eGFtcGxlIG9mIGEgY291bnRlcg0KICAgc2lnbmF0dXJlIGlzIHRoZSBzaWduYXR1cmUgdGhhdCBh IG5vdGFyeSBwdWJsaWMgcGxhY2VzIG9uIGEgZG9jdW1lbnQNCiAgIGFzIHdpdG5lc3NpbmcgdGhh dCB5b3UgaGF2ZSBzaWduZWQgdGhlIGRvY3VtZW50LiAgVGh1cyBhcHBseWluZyBhDQogICBjb3Vu dGVyIHNpZ25hdHVyZSB0byBlaXRoZXIgdGhlIENPU0VfU2lnbmF0dXJlIG9yIENPU0VfU2lnbjEg b2JqZWN0cw0KICAgbWF0Y2ggdGhpcyB0cmFkaXRpb25hbCBkZWZpbml0aW9uLg0KDQpUaGlzIHdp bGwgb25seSBiZSB0cnVlIGlmIHRoZSBwYXlsb2FkIG9mIHRoZSBjb3VudGVyIHNpZ25hdHVyZSBp bmNvcnBvcmF0ZXMgdGhlIGJ5dGUgc3RyaW5nIHJlcHJlc2VudGluZyB0aGUgcHJpbWFyeSBzaWdu YXR1cmUgdmFsdWUuDQpJZiB0aGlzIG5vdCB0aGUgY2FzZSBmb3IgQ09TRSBjb3VudGVyIHNpZ25h dHVyZSwgdGhpcyB0ZXh0IE1VU1QgYmUgcmVtb3ZlZCBhbmQgY2xhcmlmaWNhdGlvbiBvdGhlcndp c2UgTVVTVCBiZSBicm91Z2h0IHRvIHRoZSBzdGFuZGFyZC4NClRoZSB1c2Ugb2YgdGhlIHRlcm0g Y291bnRlciBzaWduYXR1cmUgd2lsbCB0aGVuIGJlIG1pc2xlYWRpbmcsIGFuZCBzaG91bGQgYmUg Y29uc2lkZXJlZCB0byBiZSByZW1vdmVkLg0KDQogICBXaGVuIGRvbmUgb24gYSBDT1NFX1NpZ25h dHVyZSwgdGhlIG5vcm1hbCBjb3VudGVyIHNpZ25hdHVyZSBzZW1hbnRpY3MNCiAgIGFyZSBwcmVz ZXJ2ZWQuICBUaGF0IGlzIHRoZSBjb3VudGVyIHNpZ25hdHVyZSBtYWtlcyBhIHN0YXRlbWVudCBh Ym91dA0KICAgdGhlIGV4aXN0ZW5jZSBvZiBhIHNpZ25hdHVyZSBhbmQsIHdoZW4gdXNlZCBhcyBh IHRpbWVzdGFtcCwgYSB0aW1lDQogICBwb2ludCBhdCB3aGljaCB0aGUgc2lnbmF0dXJlIGV4aXN0 cw0KDQpUaGlzIHdpbGwgb25seSBiZSB0cnVlIGlmIHRoZSBwYXlsb2FkIG9mIHRoZSBjb3VudGVy IHNpZ25hdHVyZSBpbmNvcnBvcmF0ZXMgdGhlIGJ5dGUgc3RyaW5nIHJlcHJlc2VudGluZyB0aGUg cHJpbWFyeSBzaWduYXR1cmUgdmFsdWUuDQpJZiB0aGlzIG5vdCB0aGUgY2FzZSBmb3IgQ09TRSBj b3VudGVyIHNpZ25hdHVyZSwgdGhpcyB0ZXh0IE1VU1QgYmUgcmVtb3ZlZCBhbmQgY2xhcmlmaWNh dGlvbiBvdGhlcndpc2UgTVVTVCBiZSBicm91Z2h0IHRvIHRoZSBzdGFuZGFyZC4NClRoZSB1c2Ug b2YgdGhlIHRlcm0gY291bnRlciBzaWduYXR1cmUgd2lsbCB0aGVuIGJlIG1pc2xlYWRpbmcsIGFu ZCBzaG91bGQgYmUgY29uc2lkZXJlZCB0byBiZSByZW1vdmVkLg0KDQogICBXaGVuIGRvbmUgb24g YSBDT1NFX01hYyBvciBhDQogICBDT1NFX01hYzAsIG9uZSBlZmZlY3RpdmVseSB1cGdyYWRlcyB0 aGUgTUFDIG9wZXJhdGlvbiB0byBhIHNpZ25hdHVyZQ0KICAgb3BlcmF0aW9uLiAgDQoNClRoaXMg d2lsbCBiZSB0cnVlIGV2ZW4gd2hlbiB0aGUgcGF5bG9hZCBvZiB0aGUgY291bnRlciBzaWduYXR1 cmUgb25seSBpbmNvcnBvcmF0ZXMgdGhlIG1hYyAncGF5bG9hZCcsIGFuZCBub3QgaXRzICd0YWcn Lg0KDQogICBXaGVuIGRvbmUgb24gYSBDT1NFX0VuY3J5cHQgb3IgQ09TRV9FbmNyeXB0MCwgdGhl DQogICBleGlzdGVuY2Ugb2YgdGhlIGVuY3J5cHRlZCBkYXRhIGlzIGF0dGVzdGVkIHRvLg0KDQpU aGlzIHdpbGwgYmUgdHJ1ZSBldmVuIHdoZW4gb25seSAnY2lwaGVydGV4dCcgaXMgaW5jbHVkZWQg aW4gdGhlIGNvdW50ZXJzaWduYXR1cmUgcGF5bG9hZC4NCg0KLS0tLS0tLS0tDQo1LjEuICBGdWxs IENvdW50ZXIgU2lnbmF0dXJlcw0KICAgIFRoZSBwcm9jZXNzIG9mIGNyZWF0aW5nIGFuZCB2YWxp ZGF0aW5nIGFiYnJldmlhdGVkDQogICBjb3VudGVyIHNpZ25hdHVyZXMgaXMgZGVmaW5lZCBpbiBT ZWN0aW9uIDQuNC4NCg0KMSkgYWJicmV2aWF0ZWQgaGVyZSBzZWVtcyBiZSBhIHR5cG8gDQoNCjIp IFRoZSBwcm9jZXNzIGluIFNlY3Rpb24gNC40IGRvZXNuJ3Qgc3BlY2lmeSBleHBsaWNpdGx5IGhv dyB0byBwb3B1bGF0ZSB0aGUgcGF5bG9hZCBlbGVtZW50IG9mIHRoZSBTaWdfc3RydWN0dXJlIGlu IHRoZSBjYXNlIG9mIGEgY291bnRlciBzaWduYXR1cmUNCkNsYXJpZmljYXRpb24gYWJvdXQgdGhh dCBpcyBhYnNvbHV0ZWx5IHJlcXVpcmVkIGVpdGhlciBoZXJlIGluIHNlY3Rpb24gNS4xIG9yIGlu IHNlY3Rpb24gNC40DQoNCi0tLS0tLS0tLQ0KNC40LiAgU2lnbmluZyBhbmQgVmVyaWZpY2F0aW9u IFByb2Nlc3MNCiAgIDUuICBUaGUgcGF5bG9hZCB0byBiZSBzaWduZWQgZW5jb2RlZCBpbiBhIGJz dHIgdHlwZS4gIFRoZSBwYXlsb2FkIGlzDQogICAgICAgcGxhY2VkIGhlcmUgaW5kZXBlbmRlbnQg b2YgaG93IGl0IGlzIHRyYW5zcG9ydGVkLg0KDQoxKSBGb3IgY291bnRlciBzaWduYXR1cmUgb2Yg YSBzaWduYXR1cmUsIHRoZSBzaW1wbGVzdCBpbnRlcnByZXRhdGlvbiBvZiB0aGlzIHRleHQgaXMg dGhhdCB0aGUgcGF5bG9hZCBpcyB0aGUgJ3BheWxvYWQnIGVsZW1lbnQgb2YgdGhlIGluaXRpYWwg c2lnbmF0dXJlLg0KVGhleSBhcmUgaG93ZXZlciBtYWpvciBpc3N1ZXMgaWYgaW50ZXJwcmV0ZWQg bGlrZSB0aGF0Lg0KSWYgSSBoYXZlIHJlYWQgaXRzIHNvdXJjZSBjb3JyZWN0bHksIHRoZSBDT1NF LUpBVkEgaW1wbGVtZW50YXRpb24gZG9lcyBkbyBjb3VudGVyLXNpZ25hdHVyZXMgb2Ygc2lnbmF0 dXJlcyB0aGlzIHdheS4NCg0KSWYgdGhpcyBpcyB3aGF0J3MgaW50ZW5kZWQsIHRoZW4gQ09TRSBj b3VudGVyIHNpZ25hdHVyZXMgYXJlbid0IGNvdW50ZXIgc2lnbmF0dXJlcyBpbiB0aGUgY2xhc3Np Y2FsIG1lYW5pbmcsIHRoZXkgYXJlIGluIGZhY3QgYmFzaWNhbGx5IGZ1bGx5IGVxdWl2YWxlbnQg dG8gY29zaWduYXR1cmVzLCBnaXZlbiB0aGF0IHdoYXQgdGhleSBpbmNsdWRlIGlzIG9ubHkgdGhl IHByaW1hcnkgcGF5bG9hZCwgYW5kIGRvZXNuJ3QgaW5jbHVkZSB0aGUgcHJpbWFyeSBzaWduYXR1 cmUuDQpTbyBhbGwgdGV4dCBzdWdnZXN0aW5nIG90aGVyd2lzZSBzaG91bGQgYmUgcmVtb3ZlZCBm cm9tIHRoZSBzdGFuZGFyZC4NCk5ldyB0ZXh0IHNob3VsZCBiZSBhZGRlZCB0byBtYWtlIGl0IGV4 dHJlbWVseSBjbGVhciB0aGF0IHRob3NlIHNpZ25hdHVyZXMgY2FuJ3QgZnVuY3Rpb24gYXMgYWN0 dWFsIGNvdW50ZXItc2lnbmF0dXJlcy4gDQpJIHdvdWxkIGFjdHVhbGx5IGJlIGluIGZhdm9yIG9m IHJlbW92aW5nIHVzZSBvZiB0aGUgdGVybSBjb3VudGVyLXNpZ25hdHVyZSBnaXZlbiBob3cgbWlz bGVhZGluZyBpdCB3b3VsZCBiZSB0aGVuLg0KDQpJZiB0aGUgaW50ZW50IGlzIGZvciBjb3VudGVy IHNpZ25hdHVyZSBpbiB0aGlzIHN0YW5kYXJkIHRvIGJlIHJlYWwgY291bnRlciBzaWduYXR1cmVz LCB0aGVuIGFuIGV4cGxpY2l0IGNsYXJpZmljYXRpb24gaXMgcmVxdWlyZWQgYWJvdXQgaG93ICdw YXlsb2FkJyBpcyBwb3B1bGF0ZWQuDQpUaGUgc2ltcGxlc3Qgc29sdXRpb24gaXMgcHJvYmFibHkg dG8gc2F5IHRoYXQgaXQgaW5jbHVkZXMgYWxsIG9mIHRoZSBwcmltYXJ5IHNpZ25hdHVyZSBzdHJ1 Y3R1cmUsIGV4Y2VwdCB0aGF0IGFsbCBvZiB0aGUgJ3VucHJvdGVjdGVkJyBoZWFkZXJzIHNoYWxs IGJlIHJlbW92ZWQgZmlyc3QgKHRoZXJlIHdvdWxkIGJlIHJlY3Vyc2lvbiBwcm9ibGVtcyBvdGhl cndpc2UpDQpUaGlzIHNwZWNpZmljYWxseSBzb2x2ZXMgdGhlIGlzc3VlIG9mIHNwZWNpZnlpbmcg d2hpY2ggb2YgdGhlIGluaXRpYWwgc2lnbmF0dXJlIGlzIGNvdW50ZXJzaWduZWQgaW4gY2FzZSB0 aGV5IGFyZSBtdWx0aXBsZSBzaWduZXJzLiANClNvbHV0aW9uIHRvIGluY2x1ZGUgbGVzcyBvZiB0 aGUgaW5pdGlhbCBzdHJ1Y3R1cmUgaW4gdGhlIGNvdW50ZXIgc2lnbmF0dXJlIHNlZW0gdG8gYmUg bW9yZSBjb21wbGV4LCBhbmQgd291bGQgbmVlZCBhbnl3YXkgdG8gaW5jbHVkZSBhbGwgb2YgdGhl IGluaXRpYWwgc2lnbmVycywgZXhjZXB0IGlmIGRlc2lnbmluZyBhIHdheSB0byBzcGVjaWZ5IG9u bHkgb25lIG9mIHRoZW0NCihtYXliZSB3aGVuIHRoZSBjb3VudGVyIHNpZ25hdHVyZSBpcyBpbnNl cnRlZCBpbnNpZGUgdGhlICd1bnByb3RlY3RlZCcgZWxlbWVudCBvZiBoaXMgc3BlY2lmaWMgc2ln bmF0dXJlID8pLg0KDQoyKSBGb3IgY291bnRlciBzaWduYXR1cmUgb2YgYSBtYWMsIHRoZSBzaW1w bGVzdCBpbnRlcnByZXRhdGlvbiBvZiB0aGlzIHRleHQgaXMgdGhhdCB0aGUgcGF5bG9hZCBpcyB0 aGUgJ3BheWxvYWQnIGVsZW1lbnQgb2YgdGhlIGluaXRpYWwgc2lnbmF0dXJlIGFuZCAndGFnJyBp c24ndCBpbmNsdWRlZCBpbiB0aGUgY291bnRlcnNpZ25hdHVyZS4gDQpUaGVyZSdzIG5vdCBhIG1h am9yIGlzc3VlIGlmIGludGVycHJldGVkIGxpa2UgdGhhdCwgYXMgSSBkaWRuJ3Qgc2VlIGEgY2xh aW0gdGhhdCB0aGlzIHdvdWxkIGNvbnRyYWRpY3QuDQoNCjMpIEZvciBlbmNyeXB0ZWQgY29udGVu dCwgdGhlIHNpbXBsZXN0IGludGVycHJldGF0aW9uIG9mIHRoaXMgdGV4dCBpcyB0aGF0IHRoZSBw YXlsb2FkIGlzIHRoZSAnY2lwaGVydGV4dCcgZWxlbWVudCAuDQpUaGVyZSdzIG5vdCBhIG1ham9y IGlzc3VlIGlmIGludGVycHJldGVkIGxpa2UgdGhhdCwgbm9uZXRoZWxlc3MgaXQgd291bGQgYmUg bWFkZSBjbGVhcmVyIGJ5IHNwZWNpZnlpbmcgaXQgZXhwbGljaXRseQ0KDQotLS0tLS0tLS0NCjUu Mi4gIEFiYnJldmlhdGVkIENvdW50ZXIgU2lnbmF0dXJlcw0KICAgSW5zdGVhZCwgdGhlIHBhcmFt ZXRlcnMgZm9yIGNvbXB1dGluZyBvciB2ZXJpZnlpbmcgdGhlDQogICBhYmJyZXZpYXRlZCBjb3Vu dGVyIHNpZ25hdHVyZSBhcmUgaW5mZXJyZWQgZnJvbSB0aGUgc2FtZSBjb250ZXh0IHVzZWQNCiAg IHRvIGRlc2NyaWJlIHRoZSBlbmNyeXB0aW9uLCBzaWduYXR1cmUsIG9yIE1BQyBwcm9jZXNzaW5n DQoNCjEpIFRoaXMgYXBwZWFycyB0byBtZWFuIHRoYXQgaWYgYSBzaWduYXR1cmUgd2l0aCBhIHNp bmdsZSBzaWduZXIgaXMgY291bnRlci1zaWduZWQgdGhpcyB3YXksIHRoZSBjb250ZW50ICsgdGhl IHByb3RlY3RlZCBoZWFkZXJzICsgdGhlIHNpZ25lciBhcmUgdGhlIHNhbWUgYXMgdGhlIGluaXRp YWwgc2lnbmF0dXJlID8NCiAgICBJZiBzbywgaXQgZG9lc24ndCBzZWVtIHRvIGhhdmUgbXVjaCB2 YWx1ZSwgc2luY2UgaXQgcmVzaWducyBleGFjdGx5IHRoZSBzYW1lIHRoaW5nIChleGNlcHQgdGhl IHNpZ25lciBwcm90ZWN0ZWQgaGVhZGVyIGlmIGFwcGxpY2FibGUpLCBzbyBpdCBzaG91bGQgYmUg bWFkZSBldmVuIG1vcmUgZXhwbGljaXQNCklmIHRoZXkgYXJlIG11bHRpcGxlIHNpZ25lcnMgb2Yg dGhlIGluaXRpYWwgc2lnbmF0dXJlLCBpcyBpdCBpbnRlbmRlZCB0aGF0IHRoZSBzaWduZXIgbXVz dCBiZSB0aGUgZmlyc3Qgb2YgdGhlIGxpc3QgPw0KRm9yIG1hYyBhbmQgZW5jcnlwdGlvbiwgaXQn cyB1bmNsZWFyIGhvdyB0aGUgc2lnbmVyIHB1YmxpYyBrZXkgd2lsbCBiZSBpZGVudGlmaWVkLCBh cyB3ZSBoYXZlIG9ubHkgdGhlIGluZm9ybWF0aW9uIGZvciB0aGUgbWFjL2VuY3J5cHRpb24ga2V5 Lg0KDQpJZiB3aGF0IGlzIGFjdHVhbGx5IGludGVuZGVkIHRoYXQgdGhlIGlkZW50aWZpY2F0aW9u IG9mIHRoZSBjb3VudGVyLXNpZ25lciBpcyB0aHJvdWdoIGFuIG91dC1vZi1iYW5kIG1lY2hhbmlz bSBhbmQgZG9lc24ndCBuZWVkIHRvIGhhdmUgYSByZWxhdGlvbiB3aXRoIHRoZSBjb3VudGVyIHNp Z25lZCBlbGVtZW50IHNpZ25hdHVyZSwgZW5jcnlwdGlvbiBvciBtYWMsIHRoaXMgc2hvdWxkIGJl IHNwZWNpZmllZC4NCg0KMikgVG8gZnVuY3Rpb24gYXMgYW4gYWN0dWFsIGNvdW50ZXItc2lnbmF0 dXJlIGZvciBzaWduYXR1cmVzLCB0aGUgc2FtZSBpc3N1ZSB3aXRoIHRoZSBwYXlsb2FkIGlzIHBy ZXNlbnQgYXMgZm9yIGZ1bGwgY291bnRlciBzaWduYXR1cmVzDQoNCjMpIFRoZXJlIGlzIG5vIHNh bXBsZSBvZiBhbiBhYmJyZXZpYXRlZCBjb3VudGVyIHNpZ25hdHVyZQ0KLS0tLS0tLS0tLS0tLS0t DQo= From nobody Thu Jun 18 10:53:27 2020 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 6A68A3A0DA2; Thu, 18 Jun 2020 10:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 OHEfznJvVgWb; Thu, 18 Jun 2020 10:53:19 -0700 (PDT) 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 AF18F3A0DA3; Thu, 18 Jun 2020 10:53:18 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Jun 2020 10:53:11 -0700 From: Jim Schaad To: 'Benjamin Kaduk' , 'The IESG' CC: , , , 'Matthew Miller' References: <159183990940.7725.14952700358572148848@ietfa.amsl.com> In-Reply-To: <159183990940.7725.14952700358572148848@ietfa.amsl.com> Date: Thu, 18 Jun 2020 10:53:10 -0700 Message-ID: <01b101d64599$56ddaf10$04990d30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLNMCuwZrzKLnHZ+xfW3Sbr0xE1gKbvj1iw Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-algs-09: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 17:53:23 -0000 > -----Original Message----- > From: Benjamin Kaduk via Datatracker > Sent: Wednesday, June 10, 2020 6:45 PM > To: The IESG > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; > cose@ietf.org; Matthew Miller ; > linuxwolf+ietf@outer-planes.net > Subject: Benjamin Kaduk's Discuss on = draft-ietf-cose-rfc8152bis-algs-09: (with > DISCUSS and COMMENT) >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-cose-rfc8152bis-algs-09: Discuss >=20 > When responding, please keep the subject line intact and reply to all = email > addresses included in the To and CC lines. (Feel free to cut this = introductory > paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I think we need to check the [MAC] reference; following links (and = chasing > redirects) seems to only find a 1985 publication that talks about DES, = with no > mention of AES-CBC-MAC. [JLS] This is one of the dangers of using algorithms are not considered = to be "good". The first attacks on it were published in 2000 as far as = I know. This is why we should be using CMAC but too many people only do = the CBC-MAC. =20 This is the reference that NIST SP800-38B uses A. Menezes, P. van Oorschot, S. Vanstone, Handbook of Applied = Cryptography, CRC Press, Inc., Boca Raton (1996). >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > It's interesting that both -struct and -algs make the claim in the = Abstract that > "this specification describes how to create and process signatures, = message > authentication codes, and encryption using CBOR for serialization". = Shouldn't > that only be true for one of them? >=20 > I'd really like to see a reference for the analysis of and = validity/safety of the > deviations from RFC 5869 HKDF, in Section 5.1. [JLS] I am going to assume you are referring to using AES for the PRF. = I don't know if such a thing exists. I can tell you where I got my = personal analysis however. When the TLS 1.3 design group was meeting in = Seattle, I spent about 20 minutes discussion what the required = capabilities of the PRF are needed to get things to work correctly. At = least part of the discussion in the group which occurred around the same = time was the ability to break the two halves of HKDF separated the way = that TLS does. Found something: https://eprint.iacr.org/2010/264.pdf look in appendix = D point 4. >=20 > Section 1 >=20 > Should we refer to RFC 8259 by its STD number (90)? Done >=20 > Section 1.3 >=20 > We don't seem to use the "AE" term (just -struct does). [JLS] I copied over the new definitions from -struct. I would rather = have it than not have it. >=20 > Section 2.1.1 >=20 > Note: Use of a deterministic signature technique is a good idea = even > when good random number generation exists. Doing so both reduces = the >=20 > Note the ongoing work in the CFRG on "deterministic signatures with = additional > randomness" (the name has been changing a bit recently), and fault = attacks on > deterministic signatures. Done - including the reference. >=20 > Section 2.2.1 >=20 > How public values are computed is not the same when looking at = EdDSA > and Elliptic Curve Diffie-Hellman (ECDH); for this reason, they > should not be used with the other algorithm. >=20 > Just to check: the claim is that EdDSA and ECDH compute public values > differently (not EdDSA and ECDSA?), but that EdDSA keys should not be = used > with algorithms other than EdDSA? [JLS]=20 >=20 > If batch signature verification is performed, a well-seeded > cryptographic random number generator is REQUIRED. Signing and = non- > batch signature verification are deterministic operations and do = not > need random numbers of any kind. >=20 > RFC 8032 doesn't talk about "batch" at all, so a reference is probably = in order. [JLS] Section 8.2 of RFC 8032. It looks like they changed the wording a = bit from an earlier verion. =20 >=20 > Section 3.1 >=20 > Some recipient algorithms transport the key, while others derive a > key from secret data. For those algorithms that transport the key > (such as AES Key Wrap), the size of the HMAC key SHOULD be the same > size as the underlying hash function. For those algorithms that > derive the key (such as ECDH), the derived key MUST be the same = size > as the underlying hash function. >=20 > "same size as the output of the underlying hash function", please -- = hash > functions can also have an internal block size that is larger. [JLS] Done. >=20 > Section 3.2.1 >=20 > * A single key must only be used for messages of a fixed or known > length. If this is not the case, an attacker will be able to >=20 > What's an example of a known-but-not-fixed length message? Just = something > with internal framing? [JLS] This is a length extension problem. You need to know that the = message you validated is the same length as the message that was MAC-ed = by the sender. This is the reason for CMAC coming into existence. >=20 > Section 4.1 >=20 > The Galois/Counter Mode (GCM) mode is a generic authenticated > encryption block cipher mode defined in [AES-GCM]. The GCM mode is > combined with the AES block encryption algorithm to define an AEAD > cipher. >=20 > GCM on its own is merely AE but AES-GCM is AEAD? That doesn't seem to = add > up... [JLS] Actually, GCM is not an AE algorithm, it is a mode. Ok - it now = reads AEAD. >=20 > Section 6.1.2 >=20 > If the salt/nonce value is generated randomly, then it is suggested > that the length of the random value be the same length as the hash > function underlying HKDF. While there is no way to guarantee that = it >=20 > "output length of the hash function", please. [JLS] Done. >=20 > Section 6.2, 6.3, 6.4 >=20 > Why does Direct Key [encryption] get its own top-level subsection with > reference to -struct, but we jump straight into AES Key Wrap without a > wrapping "Key Wrap" subsection or -struct reference, and likewise for = "Direct > Key Agreement" and "Key Agreement with Key Wrap"? It feels like = Section 6.1 > is the outlier here. >=20 > Section 6.3 >=20 > be unique for the pair of keys being used. It is acceptable to > use a global counter that is incremented for every static-static > operation and use the resulting value. When using static keys, >=20 > Perhaps say something strongly worded about storing the updated = counter > value to permanent storage before using the resulting key? [JLS] Done. >=20 > Section 7.2 >=20 > s/X25591/X25519/ [JLS] Yep >=20 > Section 8 >=20 > The algorithm identifier is not part of the capabilities data as it > should already be part of message structure. There is a = presumption > in the way that this is laid out is that the algorithm identifier >=20 > nit: strike the last "is". >=20 > itself is not needed to be a part of this as it is specified in a > different location. >=20 > nit(?): "be a part of this" is a little vague/informal. >=20 > capabilities. This means that if one wishes to enumerate all of = the > capabilities for a device which implements ECDH, it requires = multiple > pairs of capability structures (algorithm, key) to deal with the > different key types and curves that are supported. For a key, the >=20 > An example of this would be pretty helpful. >=20 > Section 8.1 >=20 > * OKP, EC2: The list of capabilities is: >=20 > - The key type value. (1 for OKP or 2 for EC2.) >=20 > - One curve for that key type from the "COSE Elliptic Curve" > registry. >=20 > Am I reading this right that the idea is to use capabilities to lock a = key down to > a single curve? >=20 > * Symmetric: The list of capabilities is: >=20 > - The key type value (4). >=20 > but we're not using this opportunity to indicate whether a symmetric = key is for > encryption vs. HMAC? >=20 > Section 8.2 >=20 > (from the "COSE Key Types" Registry). It is expected future > registered algorithms could have zero, one, or multiple elements. >=20 > nit: missing "that". [JLS] Section 8 has been re-written - you are going to need to review = again. >=20 > Section 10 >=20 > Is [this document] going to be added as a reference on these = registries? > Should it replace or augment 8152 in that role? [JLS] We will see what happens w/ the question I sent to Barry about = Jean-Marc's DISCUSS on -struct. It applies to this document as well. >=20 > I think that the COSE Header Algorithm Parameters Registry updates = need to > be in this document, not -struct. [JLS] Done. >=20 > Section 10.1, 10.2 >=20 > Do we want to say anything about the encoded verson of the = Capabilities array > being an array of integers? [JLS] It isn't. I can be either integers or text strings. >=20 > Section 10.2 >=20 > Why is the word "reserved" in the description for the IV-GENERATION > algorithm? [JLS] I did reserve this at one point and finally am registering it. - = Gone. >=20 > Section 11 >=20 > I'm not 100% sure that we want the security considerations to be so = close to > identical between -struct and -algs. [JLS] I will take another pass at trying to delete things. >=20 > One area that has been starting to get exposure is doing traffic > analysis of encrypted messages based on the length of the message. >=20 > I think this may have graduated from "starting" to be more of a = mainstream > thing :) [JLS] I guess I should go and see if you had any other comments. >=20 > Section 12.1 >=20 > Trying to chase [MAC] gives me a "reference has moved" notice. > I guess there's a newer version? [JLS] Why do I feel like I discussed this one already? -- Ah - because = it is a Discuss. >=20 > Section 12.2 >=20 > I think RFC 8017 needs to be normative, since we use it for I2OSP [JLS] Yeah - that makes sense. >=20 > Acknowledgments >=20 > G=C3=B6ran could probably get his proper name, now. [JLS] done. >=20 >=20 From nobody Thu Jun 18 10:55:10 2020 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 EEB293A0DA5; Thu, 18 Jun 2020 10:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 BXR2ScvF6Dlm; Thu, 18 Jun 2020 10:55:02 -0700 (PDT) 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 64D963A0DA2; Thu, 18 Jun 2020 10:55:02 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Jun 2020 10:54:56 -0700 From: Jim Schaad To: "'Rob Wilton (rwilton)'" , 'The IESG' CC: , , , 'Matthew Miller' References: <159172658835.26172.4590101163395195141@ietfa.amsl.com> <00c301d63eb3$9039bf20$b0ad3d60$@augustcellars.com> In-Reply-To: Date: Thu, 18 Jun 2020 10:54:55 -0700 Message-ID: <01b201d64599$951e92d0$bf5bb870$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGt8PvhRubwAU5WHR14eMnKEkUjfwJpSho5AWZicCWpDBZPcA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 17:55:05 -0000 Rob, I have spent way too long trying to do edits and re-writes and additions = and deletions on this. I don't think that I can even read it anymore. = However, = https://cose-wg.github.io/cose-rfc8152bis/draft-ietf-cose-rfc8152bis-algs= .html#name-cose-capabilities has an updated version of this that I think = will address all of your comments. Please review. Thanks, Jim -----Original Message----- From: Rob Wilton (rwilton) =20 Sent: Wednesday, June 10, 2020 4:03 AM To: Jim Schaad ; 'The IESG' Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; = cose@ietf.org; 'Matthew Miller' Subject: RE: Robert Wilton's No Objection on = draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) Hi Jim, Please see inline ... > -----Original Message----- > From: Jim Schaad > Sent: 10 June 2020 00:13 > To: Rob Wilton (rwilton) ; 'The IESG'=20 > > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org;=20 > cose@ietf.org; 'Matthew Miller' > Subject: RE: Robert Wilton's No Objection on=20 > draft-ietf-cose-rfc8152bis- > algs-09: (with COMMENT) >=20 >=20 >=20 > -----Original Message----- > From: Robert Wilton via Datatracker > Sent: Tuesday, June 9, 2020 11:16 AM > To: The IESG > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org;=20 > cose@ietf.org; Matthew Miller ; > linuxwolf+ietf@outer-planes.net > Subject: Robert Wilton's No Objection on=20 > draft-ietf-cose-rfc8152bis-algs- > 09: (with COMMENT) >=20 > Robert Wilton has entered the following ballot position for > draft-ietf-cose-rfc8152bis-algs-09: No Objection >=20 > When responding, please keep the subject line intact and reply to all=20 > email addresses included in the To and CC lines. (Feel free to cut=20 > this introductory paragraph, however.) >=20 >=20 > Please refer to=20 > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Hi, >=20 > I've only reviewed the diff against RFC8152. The vast majority of = this > document seemed to have only minimal changes and looked fine from what = > I could see. >=20 > A few minor comments that may help improve the document: >=20 >=20 > 8. COSE Capabilities >=20 > Two different types of capabilities are defined: capabilities for > algorithms and capabilities for key structures. Once defined by > registration with IANA, the list of capabilities is immutable. If = it > is later found that a new capability is needed for a key type or an > algorithm, it will require that a new code point be assigned to = deal > with that. As a general rule, the capabilities are going to map to > algorithm-specific header parameters or key parameters, but they do > not need to do so. An example of this is the HSS-LMS key > capabilities defined below where the hash algorithm used is = included. >=20 > Defining the capabilities list as immutable seemed like a misnomer to=20 > me because a new IANA registration would mutate the list. Perhaps=20 > this sentence, and the one following it, could be removed? > [JLS] The whole object is that once registered with IANA, it will=20 > never be changed even by IANA. Thus I believe that the word immutable = > seems to be correct. If this is changed then existing signatures will = > fail and key derivation functions will generate different results. [RW] I'm still slightly confused, and alas the more I read the text the more = confused I become ;-) Hence a clarifying question: Does "the list of capabilities is = immutable", does it mean that the list of capabilities associated with a = given algorithm or key structure is immutable? Or does it mean that the = entire list of defined capabilities as a set is immutable? [JLS] The intention is to say that it is fixed for a single algorithm or = key type and not the entire list. And in the following paragraph, where is states "The capability = structure is an array of values" does it mean the capability structure = associated with a particular algorithm or key? [JLS] Yes Another question relates to "The capability structure is an array of = values,", does this mean "The capability structure for a given algorithm = or key is an ordered array of values, the order ... " [JLS] Yes The paragraph below also mentions multiple pairs of capability = structures. Do the capabilities always come as a pair of an algorithm = and a key? If there are multiple pairs then how are they encoded, = presumably as an array of pairs? If capabilities do not always come as = a pair then you do you differentiate between a capability defining an = algorithm and one defining a key? >=20 > The capability structure is an array of values, the order being > dependent on the specific algorithm or key. For an algorithm, the > first element should always be a key type value, but the items that > are specific to a key should not be included in the algorithm > capabilities. This means that if one wishes to enumerate all of = the > capabilities for a device which implements ECDH, it requires = multiple > pairs of capability structures (algorithm, key) to deal with the > different key types and curves that are supported. For a key, the > first element should also be a key type value. While this means = that > this value will be duplicated if both an algorithm and key = capability > are used, the key type is needed in order to understand the rest of > the values. >=20 > Should you be using RFC 2119 language here? And should " key should=20 > not be included" be "MUST NOT"? > [JLS] Responded to this point in Roman's comments. >=20 > For the ECDH case, does that mean that the "algorithm" entry will be=20 > duplicated with different "key" entries? If so, would it help clarify = > to explicitly state this? > [JLS] Would pointing to the second and third examples in section 8.3=20 > along with some explanatory text? [RW]=20 Perhaps, but I think that it would also be useful to have an example of = supporting ECDH-ES with both P-256 and X25519 curves, and how that would = be encoded (if that makes sense). I also couldn't convince myself that the numerical values that are used = in the examples are necessary right, please can you check that they are. = E.g., the first two example have the same numeric encoding, and the two = ECDH-ES have different encodings of the algorithm. But perhaps that is = just my confusion about how this works. Regards, Rob >=20 > Jim >=20 > Thanks, > Rob >=20 >=20 From nobody Thu Jun 18 11:11:07 2020 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 13C933A0DD8; Thu, 18 Jun 2020 11:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Gf2tGLioRZbB; Thu, 18 Jun 2020 11:11:03 -0700 (PDT) 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 0442B3A0DD3; Thu, 18 Jun 2020 11:11:02 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Jun 2020 11:10:56 -0700 From: Jim Schaad To: 'Murray Kucherawy' , 'The IESG' CC: , , , 'Matthew Miller' References: <159185596258.26467.14069214515654867983@ietfa.amsl.com> In-Reply-To: <159185596258.26467.14069214515654867983@ietfa.amsl.com> Date: Thu, 18 Jun 2020 11:10:55 -0700 Message-ID: <01bd01d6459b$d16bd200$74437600$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKj8DHTPdQyfYbkqNd9KB3h9U8n3KdDU56A Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Murray Kucherawy's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 18:11:05 -0000 > -----Original Message----- > From: Murray Kucherawy via Datatracker > Sent: Wednesday, June 10, 2020 11:13 PM > To: The IESG > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; > cose@ietf.org; Matthew Miller > Subject: Murray Kucherawy's No Objection on = draft-ietf-cose-rfc8152bis-algs- > 09: (with COMMENT) >=20 > Murray Kucherawy has entered the following ballot position for > draft-ietf-cose-rfc8152bis-algs-09: No Objection >=20 > When responding, please keep the subject line intact and reply to all = email > addresses included in the To and CC lines. (Feel free to cut this = introductory > paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > As others have pointed out, the Abstract needs fixing. >=20 > I'm surprised none of my colleagues thought the document status and = downrefs > problem isn't worthy of a DISCUSS, because it's important to get = right. But as > one of the newbies of the group I'll go along with them and merely = pile on by > mentioning it again. >=20 > And lo, a bunch of editorial nits: >=20 > Section 1: > * "... small in terms of messages transport and implementation size = ..." -- > s/messages/message/ [JLS] Some where it became /messages transported/ >=20 > Section 1.4: > * Missing period at the end of the last sentence. [JLS] Fixed >=20 > Section 2: > * "Part Section 9.1 of ..." -- remove "Part" [JLS] Not my fault - it is xml2rfc that put it there. Put a note in the = xml. >=20 > Section 2.1: > * "... collisions of this value leads to ..." -- s/leads/lead/ > * "(2 coordinate elliptic curve)" -- suggest "two" instead of "2" [JLS] Definitely. >=20 > OLD: > Other documents can define it to work with other curves and points = in the > future. > NEW: > Future documents may extend support to include other curves and = points. [JLS] Fixed. >=20 > Section 2.1.1: > * "... truncate a hash function down ..." -- "down" feels redundant = here [JLS] done >=20 > Section 2.2.1: > * "... for this reason, they should not be used with the other = algorithm." -- I > don't understand what this is saying. [JLS] How about /they should not/the public key should not/? >=20 > Section 3: > * "Part Section 9.2 of ..." -- remove "Part" > * "... such as MD5 has decreased over time; the security ..." -- = s/;/,/ [JLS] See above. >=20 > Section 3.2: > * Where is "IV" defined? [JLS] It is now. >=20 > Section 3.2.1: > * "Cipher Block Chaining (CBC) mode, if the same key ..." -- maybe add = "In" at > the front? [JLS] Fixed. >=20 > Section 4: > * Errant "Part" at the front again. [JLS] Ditto >=20 > Section 5: > * ... and again. [JLS] Ditto >=20 > Section 5.1: > * I had to look up what a "bstr" is. Is that definition assumed to be = imported > from somewhere? [JLS] Imported in the section "CBOR Grammar" but not explicitly done so. >=20 > Section 6: > * "Part" again. [JLS] Ditto >=20 > Section 8: > * I don't understand the second paragraph of this section. [JLS] See the message to Rob - The entire section has been drastically = re-written >=20 > Section 10.2: > * "... this registration, if this is ..." -- "If" should start a new = sentence. > * "... then the DE should be ..." -- s/DE/Designated Expert/ [JLS] Fixed. >=20 > Section 11: > * "One area that has been starting to get exposure is doing traffic = ..." -- the > word "doing" feels out of place here [JLS] Changed here and in -struct. Jim >=20 >=20 From nobody Thu Jun 18 11:14:24 2020 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 817D33A0DD8; Thu, 18 Jun 2020 11:14:23 -0700 (PDT) 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=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 DEx40iX6zqDU; Thu, 18 Jun 2020 11:14:21 -0700 (PDT) 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 051C83A0DD0; Thu, 18 Jun 2020 11:14:20 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Jun 2020 11:14:11 -0700 From: Jim Schaad To: 'Martin Duke' CC: 'The IESG' , , , , 'Matthew Miller' References: <159176657029.21875.10088343710386665224@ietfa.amsl.com> <008801d6433a$c6e244d0$54a6ce70$@augustcellars.com> In-Reply-To: Date: Thu, 18 Jun 2020 11:14:10 -0700 Message-ID: <01be01d6459c$45aa6d20$d0ff4760$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BF_01D64561.994D69E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHVtGfUFBi+5CIiLSIQJo/8vmDqlwFimrY3Ai1OwxOow1BCkA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Martin Duke's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 18:14:24 -0000 ------=_NextPart_000_01BF_01D64561.994D69E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Martin Duke =20 Sent: Monday, June 15, 2020 10:48 AM To: Jim Schaad Cc: The IESG ; draft-ietf-cose-rfc8152bis-algs@ietf.org; = cose-chairs@ietf.org; cose@ietf.org; Matthew Miller = Subject: Re: Martin Duke's No Objection on = draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) =20 s/contents algorithm/contents, I think, but otherwise LGTM. =20 this is non-blocking, but I don't see a reason to include the AE = definition in this document at all, but I"m happy to consider these = issues addressed. [JLS] Fixed =20 On Mon, Jun 15, 2020 at 10:31 AM Jim Schaad > wrote: -----Original Message----- From: Martin Duke via Datatracker >=20 Sent: Tuesday, June 9, 2020 10:23 PM To: The IESG > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org = ; cose-chairs@ietf.org = ; cose@ietf.org ; = Matthew Miller >; = linuxwolf+ietf@outer-planes.net = =20 Subject: Martin Duke's No Objection on = draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) Martin Duke has entered the following ballot position for draft-ietf-cose-rfc8152bis-algs-09: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As everyone else has pointed out, the header needs to be fixed to = indicate this is Informational, not Standards Track. Section 1. s/messages transport/message transport s/of the Javascript/of Javascript [JLS] Done. Sec 1.3 In the definitions of =E2=80=9CAE=E2=80=9D and =E2=80=9CAEAD=E2=80=9D, I = don=E2=80=99t understand the functional difference between = authentication of =E2=80=9Cplaintext contents=E2=80=9D (AE) and = authentication of =E2=80=9Cnon-encrypted data=E2=80=9D (AEAD). AFAICT AE = isn=E2=80=99t actually used in the document, so it might be easiest to = simply delete it. [JLS] I have updated the text to read as follows, does that make it = clearer? Authenticated Encryption (AE) algorithms are = encryption algorithms that provide an authentication check of the = contents algorithm with the encryption service. An example of an AE = algorithm used in COSE is AES Key Wrap . = These algorithms are used for key encryption algorithms, but AEAD = algorithms would be preferred. Authenticated Encryption with Associated Data (AEAD) algorithms provide the same authentication service = of the content as AE algorithms do. They also allow for associated = data to be included in the authentication service, but which is not part = of the encrypted body. An example of an AEAD algorithm used in COSE = is AES-GCM . These algorithms are used for = content encryption and can be used for key encryption as well. Sec 1.5. Replace the URL with a reference. [JLS] Fixed. I actually read this whole document but got pretty lost by the end, not = being an expert in this area. ------=_NextPart_000_01BF_01D64561.994D69E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From: = Martin Duke <martin.h.duke@gmail.com>
Sent: Monday, = June 15, 2020 10:48 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: The IESG = <iesg@ietf.org>; draft-ietf-cose-rfc8152bis-algs@ietf.org; = cose-chairs@ietf.org; cose@ietf.org; Matthew Miller = <linuxwolf+ietf@outer-planes.net>
Subject: Re: Martin = Duke's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with = COMMENT)

 

s/contents algorithm/contents, I think, but otherwise = LGTM.

 

this is non-blocking, but I don't see a reason to = include the AE definition in this document at all, but I"m happy to = consider these issues addressed.

[JLS] Fixed

 

On = Mon, Jun 15, 2020 at 10:31 AM Jim Schaad <ietf@augustcellars.com> = wrote:



-----Original = Message-----
From: Martin Duke via Datatracker <noreply@ietf.org>
Sent: Tuesday, June 9, = 2020 10:23 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; cose@ietf.org; = Matthew Miller <linuxwolf+ietf@outer-planes.net>; linuxwolf+ietf@outer-planes.net
Subject: Martin = Duke's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with = COMMENT)

Martin Duke has entered the following ballot position = for
draft-ietf-cose-rfc8152bis-algs-09: No Objection

When = responding, please keep the subject line intact and reply to all email = addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml
for more information about IESG DISCUSS and COMMENT = positions.


The document, along with other ballot positions, = can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cose-rfc815= 2bis-algs/



-------------------------------------------= ---------------------------
COMMENT:
------------------------------= ----------------------------------------

As everyone else has = pointed out, the header needs to be fixed to indicate this is = Informational, not Standards Track.

Section 1.
s/messages = transport/message transport
s/of the Javascript/of = Javascript
[JLS] Done.

Sec 1.3
In the definitions of = =E2=80=9CAE=E2=80=9D and =E2=80=9CAEAD=E2=80=9D, I don=E2=80=99t = understand the functional difference between authentication of = =E2=80=9Cplaintext contents=E2=80=9D (AE) and authentication of = =E2=80=9Cnon-encrypted data=E2=80=9D (AEAD). AFAICT AE isn=E2=80=99t = actually used in the document, so it might be easiest to simply delete = it.
[JLS]  I have updated the text to read as follows, does that = make it clearer?

Authenticated Encryption (AE) <xref = target=3D"RFC5116"/> algorithms are encryption algorithms = that provide an authentication check of the contents algorithm with the = encryption service.  An example of an AE algorithm used in COSE is = AES Key Wrap <xref target=3D"RFC3394"/>.  These = algorithms are used for key encryption algorithms, but AEAD algorithms = would be preferred.

Authenticated Encryption with Associated Data = (AEAD) <xref target=3D"RFC5116"/> algorithms provide the = same authentication service of the content as AE algorithms do.  =  They also allow for associated data to be included in the = authentication service, but which is not part of the encrypted = body.    An example of an AEAD algorithm used in COSE is = AES-GCM <xref target=3D"RFC5116"/>.    These = algorithms are used for content encryption and can be used for key = encryption as well.


Sec 1.5. Replace the URL with a = reference.
[JLS] Fixed.

I actually read this whole document = but got pretty lost by the end, not being an expert in this = area.



------=_NextPart_000_01BF_01D64561.994D69E0-- From nobody Fri Jun 19 06:52:58 2020 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 4A6A43A0A0C for ; Fri, 19 Jun 2020 06:52:56 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.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 Y5hedeNX12cr for ; Fri, 19 Jun 2020 06:52:53 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 F0CC23A09F7 for ; Fri, 19 Jun 2020 06:52:52 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id g18so705320wrm.2 for ; Fri, 19 Jun 2020 06:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Tp7wokdVO7xrpSn7CHbc2U6o541lAAwSHFEcIbCffj8=; b=BsKZBhoolZ0gK0H3ztgFFAB7ghTBimOy4U//SZ1E9axRyIBZ1CKG/b2bfVyi+5fbSz do/eqYZ0MRqldIrzP3pOFvatNHc3AknYjRK/4Ya6QsIeJRVhy5MssWc/OVi/5r5PjFEZ hDRaISZGaDsNDzhztQtxXPNFpBtPUGYW325rfMHFnMTK/6oSAOQTvCgbMvGg3AuXpuYr eOx/tVY9Stx58wl0CqSknokTwlqOeDo0OcpXDESR6i0p+cnJRpkirlJAB/6aWZpMgAwM bVe/KOCQlYAaXh0gKREWF+nWLEvI1GeRt/iByl9oj/svul+HlZsg1Vx5h4/MHr0EmE38 UUXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Tp7wokdVO7xrpSn7CHbc2U6o541lAAwSHFEcIbCffj8=; b=OVQLrvAIN0GrYu93wTu9TmHnz+ERuxTdWgq1XxL0nIYyXGr4unOUdtoPZrLTKDiIbv UAApPLJNe64VHcxqWw8/3hFru2iROMSMqyjJnhc/gThU5VBRhwrPJrqxzkJ4VVfc7myv qnsHSoAG3ktVkOrXKI1TMyfXQPfYyE1qBT0PklSzwhjKmTiGUSyPHHYJ53Sfdf3n57eJ 3cajCr3tga8rOaJ4wWs1nqg94Dh+CDWPIhT7ErK7Xjf/vQFouWuywRMXORjGIy31bsOV zla4+i4gTDMDjR4dZxolgN7dxXQv+n91QlaKDEnK4wITwwFhP6sAlJL5k5WprfPUKnJD GxGw== X-Gm-Message-State: AOAM533agCe79ldieZfYk7ixbXxFdCTm/skiEIRtcntTshPZg/Ah1gzB MONksp5edjX5mTCgYlRkPqe+TLGePbjVE/mkoxSx6sSN35U= X-Google-Smtp-Source: ABdhPJwxj1ZueTXgVEIO3OJb6+blsdr2NXHLbOuCX+nydw1qMqeVEvyn1U6JqL1PwRT9AVcb8q0Uqin4RxZ/ND/dwZQ= X-Received: by 2002:a5d:65cd:: with SMTP id e13mr4530331wrw.213.1592574770564; Fri, 19 Jun 2020 06:52:50 -0700 (PDT) MIME-Version: 1.0 References: <159251992201.11993.15942540018989542642@ietfa.amsl.com> In-Reply-To: <159251992201.11993.15942540018989542642@ietfa.amsl.com> From: Ivaylo Petrov Date: Fri, 19 Jun 2020 15:52:24 +0200 Message-ID: To: cose Content-Type: multipart/alternative; boundary="0000000000007a613f05a87035b7" Archived-At: Subject: [COSE] Fwd: Nomcom 2020-2021 Final Call For Volunteers X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 13:52:56 -0000 --0000000000007a613f05a87035b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, I am forwarding you this reminder that the NomCom is still accepting volunteers and they would like to have much more than they currently do. The participation will give you a chance to meet a number of nice people, get a much better understanding of the IETF from the inside and in a way allow the normal functioning of the IETF. Please consider it. Best regards, Ivaylo ---------- Forwarded message --------- From: NomCom Chair 2020 Date: Fri, Jun 19, 2020 at 12:40 AM Subject: Nomcom 2020-2021 Final Call For Volunteers To: IETF Announcement List Cc: Hi IETFers, We're down to the last week of accepting NomCom volunteers. And I need more! Lots more! I have 64. I'd really like to get another 100 names. Hopefully, some of you are checking the volunteer box on IETF 108 registration. But I don't have anything from canceled IETF 107 registration, and the NomCom question wasn't asked on IETF 106. So I need a flood of volunteers to come in over the next week. Barbara =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The IETF NomCom appoints people to fill the open slots on the LLC, IETF Trust, the IAB, and the IESG. Ten voting members for the NomCom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the NomCom can be found in BCP 10 (RFC 8713). RFC 3797 details the selection algorithm. Special for this year (and only this year), we also have RFC 8788 (one-off update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer: Members of the IETF community must have attended at least three of the last five in-person IETF meetings in order to volunteer. The five meetings are the five most recent in-person meetings that ended prior to the date on which the solicitation for NomCom volunteers was submitted for distribution to the IETF community. Because no IETF 107 in-person meeting was held, for the 2020-2021 Nominating Committee those five meetings are IETFs 102 [Montreal, Canada; July 2018], 103 [Bangkok, Thailand; November 2018], 104 [Prague, Czech Republic; March 2019], 105 [Montreal, Canada; July 2019], and 106 [Singapore; November 2019]. Keep in mind that eligibility is based on in-person attendance at the five listed meetings. You can check your eligibility at: https://www.ietf.org/registration/nomcom.py. If you qualify, please volunteer. Before you decide to volunteer, please remember that anyone appointed to this NomCom will not be considered as a candidate for any of the positions that the 2020 - 2021 NomCom is responsible for filling. People commonly volunteer by ticking the box on IETF registration forms. The IETF 106 form did not ask whether people were willing to volunteer. IETF 107 did ask, but all those registrations were canceled. I have asked the Secretariat if it is possible to get the list if volunteers from canceled IETF 107 registrations. If that list is available, I will contact all who are verified as eligible. But given the uncertainty of this process, I would encourage people to volunteer directly (see the bottom of this email for instructions). Thank you for volunteering! The list of people and posts whose terms end with the March 2021 IETF meeting, and thus the positions for which this NomCom is responsible, are IETF Trust: Joel Halpern LLC: Maja Andjelkovic IAB: Jari Arkko Jeff Tantsura Mark Nottingham Stephen Farrell Wes Hardaker Zhenbin Li IESG: Alissa Cooper, IETF Chair/GEN AD Alvaro Retana, RTG AD Barry Leiba, ART AD Deborah Brungard, RTG AD =C3=89ric Vyncke, INT AD Magnus Westerlund, TSV AD Roman Danyliw, SEC AD Warren Kumari, OPS AD All appointments are for 2 years. The Routing area has 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas (that have more than one AD) have at least one continuing AD. The primary activity for this NomCom will begin in July 2020 and should be completed in January 2021. The NomCom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. While being a NomCom member does require some time commitment it is also a very rewarding experience. As a member of the NomCom it is very important that you be willing and able to attend either videoconference or in-person meetings (which may not happen) during 14-20 November (IETF 109 - Bangkok) to conduct interviews. Videoconference attendance will be supported whether or not there are in-person meetings. Orientation and setting of the NomCom schedule will be done by videoconference during the week 20-24 July (exact time and date to be determined after NomCom membership is finalized on July 12), the week prior to IETF 108. Being at IETF 110 (Prague) is not essential. Please volunteer by sending me an email before 23:59 UTC June 24, 2020, as follows: To: nomcom-chair-2020@ietf.org Subject: NomCom 2020-21 Volunteer Please include the following information in the email body: Your Full Name: // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: // For confirmation if selected You should expect an email response from me within 5 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that NomCom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the NomCom is a great way to contribute to the IETF! You can find a detailed timeline on the NomCom web site at: https://datatracker.ietf.org/nomcom/2020/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next few weeks. Thank you! Barbara Stark bs7652 at att dot com nomcom-chair-2020 at ietf dot org --0000000000007a613f05a87035b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

I am forwarding you this reminder that the NomCom is still accepti= ng volunteers and they would like to have much more than they currently do.= The participation will give you a chance to meet a number of nice=C2=A0peo= ple, get a much better understanding of the IETF from the inside and in a w= ay allow the normal functioning of the IETF. Please consider it.

Best regards,
Iva= ylo


---------- Forwarded message ---------
From: NomCom Chair 2020 <nomcom-chair-2020@i= etf.org>
Date: Fri, Jun 19, 2020 at 12:40 AM
Subject: N= omcom 2020-2021 Final Call For Volunteers
To: IETF Announcement List <= ;ietf-announce@ietf.org>Cc: <ietf@ietf.org>
=

Hi IETFers,
We're down to the last week of accepting NomCom volunteers. And I need = more! Lots more!

I have 64. I'd really like to get another 100 names. Hopefully, some of= you are checking the volunteer box on IETF 108 registration. But I don'= ;t have anything from canceled IETF 107 registration, and the NomCom questi= on wasn't asked on IETF 106. So I need a flood of volunteers to come in= over the next week.
Barbara
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The IETF NomCom appoints people to fill the open slots on the LLC, IETF Tru= st, the IAB, and the IESG.

Ten voting members for the NomCom are selected in a verifiably random way f= rom a pool of volunteers. The more volunteers, the better chance we have of= choosing a random yet representative cross section of the IETF population.=

The details of the operation of the NomCom can be found in BCP 10 (RFC 8713= ). RFC 3797 details the selection algorithm.

Special for this year (and only this year), we also have RFC 8788 (one-off = update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer:

=C2=A0 =C2=A0 =C2=A0 Members of the IETF community must have attended at le= ast three of
=C2=A0 =C2=A0 =C2=A0 the last five in-person IETF meetings in order to volu= nteer.

=C2=A0 =C2=A0 =C2=A0 The five meetings are the five most recent in-person m= eetings that
=C2=A0 =C2=A0 =C2=A0 ended prior to the date on which the solicitation for = NomCom
=C2=A0 =C2=A0 =C2=A0 volunteers was submitted for distribution to the IETF = community.
=C2=A0 =C2=A0 =C2=A0 Because no IETF 107 in-person meeting was held, for th= e 2020-2021
=C2=A0 =C2=A0 =C2=A0 Nominating Committee those five meetings are IETFs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 102 [Montreal, Canada; July 2018],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 103 [Bangkok, Thailand; November 2018],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 104 [Prague, Czech Republic; March 2019],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 105 [Montreal, Canada; July 2019], and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 106 [Singapore; November 2019].

Keep in mind that eligibility is based on in-person attendance at the five = listed meetings. You can check your eligibility at: https= ://www.ietf.org/registration/nomcom.py.

If you qualify, please volunteer. Before you decide to volunteer, please re= member that anyone appointed to this NomCom will not be considered as a can= didate for any of the positions that the 2020 - 2021 NomCom is responsible = for filling.

People commonly volunteer by ticking the box on IETF registration forms. Th= e IETF 106 form did not ask whether people were willing to volunteer. IETF = 107 did ask, but all those registrations were canceled. I have asked the Se= cretariat if it is possible to get the list if volunteers from canceled IET= F 107 registrations. If that list is available, I will contact all who are = verified as eligible. But given the uncertainty of this process, I would en= courage people to volunteer directly (see the bottom of this email for inst= ructions). Thank you for volunteering!

The list of people and posts whose terms end with the March 2021 IETF meeti= ng, and thus the positions for which this NomCom is responsible, are

IETF Trust:
=C2=A0 =C2=A0 Joel Halpern

LLC:
=C2=A0 =C2=A0 Maja Andjelkovic

IAB:
=C2=A0 =C2=A0 Jari Arkko
=C2=A0 =C2=A0 Jeff Tantsura
=C2=A0 =C2=A0 Mark Nottingham
=C2=A0 =C2=A0 Stephen Farrell
=C2=A0 =C2=A0 Wes Hardaker
=C2=A0 =C2=A0 Zhenbin Li

IESG:
=C2=A0 =C2=A0 Alissa Cooper, IETF Chair/GEN AD
=C2=A0 =C2=A0 Alvaro Retana, RTG AD
=C2=A0 =C2=A0 Barry Leiba, ART AD
=C2=A0 =C2=A0 Deborah Brungard, RTG AD
=C2=A0 =C2=A0 =C3=89ric Vyncke, INT AD
=C2=A0 =C2=A0 Magnus Westerlund, TSV AD
=C2=A0 =C2=A0 Roman Danyliw, SEC AD
=C2=A0 =C2=A0 Warren Kumari, OPS AD

All appointments are for 2 years. The Routing area has 3 ADs and the Genera= l area has 1; all other areas have 2 ADs. Thus, all areas (that have more t= han one AD) have at least one continuing AD.

The primary activity for this NomCom will begin in July 2020 and should be = completed in January 2021.=C2=A0 The NomCom will have regularly scheduled c= onference calls to ensure progress. There will be activities to collect req= uirements from the community, review candidate questionnaires, review feedb= ack from community members about candidates, and talk to candidates.

While being a NomCom member does require some time commitment it is also a = very rewarding experience.

As a member of the NomCom it is very important that you be willing and able= to attend either videoconference or in-person meetings (which may not happ= en) during 14-20 November (IETF 109 - Bangkok) to conduct interviews. Video= conference attendance will be supported whether or not there are in-person = meetings. Orientation and setting of the NomCom schedule will be done by vi= deoconference during the week 20-24 July (exact time and date to be determi= ned after NomCom membership is finalized on July 12), the week prior to IET= F 108.=C2=A0 Being at IETF 110 (Prague) is not essential.

Please volunteer by sending me an email before 23:59 UTC June 24, 2020, as = follows:

To: nomcom-= chair-2020@ietf.org
Subject: NomCom 2020-21 Volunteer

Please include the following information in the email body:

Your Full Name:
=C2=A0 =C2=A0 // as you write it on the IETF registration form

Current Primary Affiliation:
=C2=A0 =C2=A0 // Typically what goes in the Company field
=C2=A0 =C2=A0 // in the IETF Registration Form

Emails:
=C2=A0 =C2=A0// All email addresses used to register for the past 5 IETF me= etings
=C2=A0 =C2=A0// Preferred email address first

Telephone:
=C2=A0 =C2=A0 // For confirmation if selected

You should expect an email response from me within 5 business days stating = whether or not you are qualified.=C2=A0 If you don't receive this respo= nse, please re-send your email with the tag "RESEND"" added = to the subject line.

If you are not yet sure if you would like to volunteer, please consider tha= t NomCom members play a very important role in shaping the leadership of th= e IETF.=C2=A0 Questions by email or voice are welcome. Volunteering for the= NomCom is a great way to contribute to the IETF!

You can find a detailed timeline on the NomCom web site at:
=C2=A0 =C2=A0 https://datatracker.ietf.org/nomcom/2020/=

I will be publishing a more detailed target timetable, as well as details o= f the randomness seeds to be used for the RFC 3797 selection process, withi= n the next few weeks.

Thank you!

Barbara Stark
bs7652 at att dot com
nomcom-chair-2020 at ietf dot org

--0000000000007a613f05a87035b7-- From nobody Fri Jun 19 08:07:48 2020 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 A8F863A0AB1; Fri, 19 Jun 2020 08:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YQctfz6w; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pueg1Igi 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 x4aPS9bhPJfb; Fri, 19 Jun 2020 08:07:41 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03EB13A0AA1; Fri, 19 Jun 2020 08:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14620; q=dns/txt; s=iport; t=1592579261; x=1593788861; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Xv3tPhT9CpjI71UInsysV3Yy2jMY6hzW4N1Tk/yDtb0=; b=YQctfz6wUOmwD3DZt4RnWCL3ELLcLa6FNPKZTMkndwy7D2OTGcHuoZNt ewgttEhrKRTVSq4K2UShTkIOdGQEVojFo8FR3f/A/wCUFm4oIwcm/13Up 0JtbzAh8VkZacAwKtfP69MI+xxOUiris5Y9YgusjPYtE55hmzFHAGt5JN o=; IronPort-PHdr: =?us-ascii?q?9a23=3AkFplfhESnpYL+lC0XvwDwZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401wWbVJjU9ulYgOfSt6n6QioL5pPS+HwBcZkZUR?= =?us-ascii?q?gDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh5CMdBw?= =?us-ascii?q?7jPgdxIu3vAcjZiMHkn+y38ofYNgNPgjf1aLhuLRKw+APWsMRz48NiJ689xw?= =?us-ascii?q?GPrGFPfrFdxHhjIhSYmBOv6w=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxBQBt1Oxe/5BdJa1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUlEHb1gvLAqEGoNGA41AmFSBQoEQA1ULAQEBDAEBIwo?= =?us-ascii?q?CBAEBhEQCF4IRAiQ4EwIDAQELAQEFAQEBAgEGBG2FLgglDIVyAQEBAQMSERE?= =?us-ascii?q?MAQEpDgELBAIBCA4DBAEBAwImAgICMBUICAIEAQ0FCBqDBYJLAy4BAwusUQK?= =?us-ascii?q?BOYhhdoEygwEBAQWBRkGDTBiCDgMGgQ4qgmeJexqBQT+BEAFDgk0+glwCAQI?= =?us-ascii?q?BgSYBEgEHHCSCbjOCLY52I4MQhmCbTgqCWohChiOFXYUHgnGJJIUciy+CG5E?= =?us-ascii?q?rihWUMwIEAgQFAg4BAQWBaiJmWBEHcBU7gmlQFwINgzSKagsYFIM6gmSCMIV?= =?us-ascii?q?CdAI1AgYIAQEDCXyOcgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,255,1589241600"; d="scan'208";a="528238605" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Jun 2020 15:07:39 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 05JF7duO005975 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Jun 2020 15:07:39 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Jun 2020 10:07:39 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Jun 2020 10:07:38 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 19 Jun 2020 10:07:38 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Msny4cCd4ktAA6jNqvxRA6vzQezNpJk7lKeKGsrWAZBLI49mtSvDNlRbVFAsgR+JHhBvIeDZvPNLh7g7fcmeSkoyDz6IZgvkhWeRYNEApaE7J4rX+EQZoYEvewj66oymoLO/+T6/jdXVzcACA/kj8yBE7/ue0iKavkbonbIOrftr3EQi1NvO6DD3J3HENjNF26I/zhkeV8+Tobn6ffZFMrH/zAK7kNWFs9xKiMaM7DSDudorpHgCe/3Hs9Y4y6TVVQ32C7fNTQinlfNPcQUA5zxJkeN00reZIL0AZEPbq2rzN0naSwHPaf5GQaec1zp45sGgoLelhq6tNYS+nfhAEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xv3tPhT9CpjI71UInsysV3Yy2jMY6hzW4N1Tk/yDtb0=; b=U7+j3yJifFzOX3MA+CFkDOmbYLNJ5B0o298H9nVHjalyRz9GNlhlt/Ruj5V3nlnQwrECwLg/9VGumWRykoMOWrRKiVQDMfJxt+GJIQQZGBcV6G0GsXgVtY7H6FhaTP+RbBivqQwoMRN/WA9LfS/YkGLNiy65hAbvBJaWOiRJ71nsWEJlgdBPxuc6Z6IJSpQDqmPCrkJ5+R1EP/HGW90SHn4bDFZP7yobaGRHlDqYahG4/uw1Hiq7I4HoYE142F9f/TS2yokO/O5tBmUybrHY8p1FdSeNW4DxAzRgg9n+S9Dzdv64NhSnEekOVq+Ni/xFnZiaZbHLhQkk4+eZDvPAEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xv3tPhT9CpjI71UInsysV3Yy2jMY6hzW4N1Tk/yDtb0=; b=pueg1IgiGa3KgBCt3WX+sWj11dl09jEn7gjZc3CKHOOFer64Ntl7Su9suuvFAxTBazgzGzzBNErqWgA3xIMi8KSbhsEdnNHt04JXskOdUgd6jzMrHWDQ3nTFgmelbAgunryN2lPBZfrsAooVJGg3fZttqT0AEzjtEfl+nBT7XcI= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3140.namprd11.prod.outlook.com (2603:10b6:208:77::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Fri, 19 Jun 2020 15:07:37 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18%5]) with mapi id 15.20.3109.023; Fri, 19 Jun 2020 15:07:36 +0000 From: "Rob Wilton (rwilton)" To: Jim Schaad , "'The IESG'" CC: "draft-ietf-cose-rfc8152bis-algs@ietf.org" , "cose-chairs@ietf.org" , "cose@ietf.org" , "'Matthew Miller'" Thread-Topic: Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) Thread-Index: AQHWPoog2C1ANtZ1AUyxZq1l8KMrnajQ6gaAgACcDMCADS//gIABV8FQ Date: Fri, 19 Jun 2020 15:07:36 +0000 Message-ID: References: <159172658835.26172.4590101163395195141@ietfa.amsl.com> <00c301d63eb3$9039bf20$b0ad3d60$@augustcellars.com> <01b201d64599$951e92d0$bf5bb870$@augustcellars.com> In-Reply-To: <01b201d64599$951e92d0$bf5bb870$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.15.79.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 901af061-8c34-474f-4532-08d814628096 x-ms-traffictypediagnostic: BL0PR11MB3140: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RKYvUz3bwmtUtPYMruaP6+LXqFzmt+1mEge5QFwWcb7MV2oDkex/EEqyemXQIVuIll9PPjw6r56YKySUfscyLUkYDZYe0EsFY74yQfh1HOSsFXGyADwDD5afl8z+XH3x9j09FbJPWlGs9DbrjGa3vjb+gX9bAKLnfEhuiQNrkP/dxJd1XyB4MDkaiTQDqE/ML1Tk+YNPlxMm/oC6BRhoDlJUZK8uwWYNAcPE3fm6ocBqHg1sVqF7Z7GzIPtGJx/0/KWLl9D2RwHSWBXHusqZ/pVt7iHJtbqHSVgeGUMhvcYwSErEvOzlYnT4iuk0sikGjCeUyWzmS5xePYa7avUOd/SJWxTeEVSLU6R6z7OXJ9OB/4+rvrhlCsInJflUYxxpe9oRX3xVCyOh627cLqcl1A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(396003)(39860400002)(136003)(376002)(66446008)(64756008)(76116006)(66476007)(66556008)(66946007)(54906003)(110136005)(316002)(478600001)(9686003)(55016002)(83080400001)(6506007)(53546011)(52536014)(966005)(71200400001)(86362001)(5660300002)(8936002)(186003)(2906002)(7696005)(33656002)(26005)(8676002)(4326008)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: xZv8wvwymZkY4oRyY1lfDeu94B3qct5YveufjOmsC09lC4zYFrE2OaRP1jHVr2CUGEkfMFW3mjCDnulrELOO1YHfbHa+IhuKivKPnb/uyprWijGMp6XmjOr+j2ZUTX7XgNOMTuV5jjl1g3vi8flkHNLfNS6DO4MWnl+n3b6FkrJ7JNL53D+wTHccV/ES9vHV8aVAnfWb7VZT9cW/sm2uS+IiTzB4NgqbaD2Su84Q1QRtO5UD0St1VJFjmfYAmh3BPIzldsbtGQXmMfyyrHxaa/iqLOWhJ0aVZaSgUMrVZRirWFvqjml0lwYzE0nXT+aE9F+tQDM8mYvqarXs9JGkkCTdJJykjdtklqJMaZJ94p/N/jfU4akaSNhFk/bngA2XcxR6ocV40UWMCJM3UlR0DmDy25fwG6V7G0SS4j63SLKpZzYeTio60ITJuGHV3vtDtFA6oC1vANUag0oYNaBmLxkNuUK4m63q+8/RlpWNckY= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 901af061-8c34-474f-4532-08d814628096 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 15:07:36.8718 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Bk7zQ4og+KgW5oVedB1j4rPGYmf4vtgN0ilSM4278u0v0jqbg9SzmgBD8k7Ivk5OuzHwN8HQg/sCnzVgxIWuSQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3140 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [COSE] Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 15:07:46 -0000 SGkgSmltLA0KDQpTb3JyeSwgYnV0IEknbSBzdGlsbCBzdHJ1Z2dsaW5nIHRvIGZ1bGx5IHVuZGVy c3RhbmQgdGhlIGNhcGFiaWxpdHkgdGV4dC4gIFRoYXQgbWF5IGJlIGJlY2F1c2UgaXQgaXMgdG9v IGZhciBvdXQgb2YgbXkgZG9tYWluIG9mIGV4cGVydGlzZSwgb3IgaXQgbWF5IGJlIGJlY2F1c2Ug dGhlIHRleHQgaXMgdW5jbGVhci4gIEl0IGlzIGFsc28gd29ydGggbm90aW5nIHRoYXQgSSd2ZSBu b3QgcmVhZCB0aGUgZW50aXJlIGRvY3VtZW50LCBqdXN0IHRoZSBkaWZmcy4gIEFsc28gbm90ZSB0 aGF0IHRoZXNlIGFyZSBqdXN0IGNvbW1lbnRzIGludGVuZGVkIHRvIGhlbHAgdGhlIHJlYWRhYmls aXR5IG9mIHRoZSBkb2N1bWVudCwgdGhleSBkb24ndCBibG9jayB0aGUgcHJvZ3Jlc3Npb24gb2Yg dGhlIGRvY3VtZW50LCBzbyB0aGUgYXV0aG9ycyBhcmUgYXQgbGliZXJ0eSB0byBpZ25vcmUgdGhl bSBpZiB0aGV5IGNob29zZS4NCg0KRnJvbSB0aGUgbGF0ZXN0IHRleHQgb24gZ2l0aHViLCB0aGUg dGhpbmdzIHRoYXQgSSBkb24ndCBmdWxseSB1bmRlcnN0YW5kLCBvciBwb3RlbnRpYWxseSBmaW5k IHRoZSB0ZXh0IHNvbWV3aGF0IGNvbmZ1c2luZyBhcmU6DQoNCg0KIlRoaXMgbWVhbnMgdGhhdCBp ZiBvbmUgd2lzaGVzIHRvIGVudW1lcmF0ZSBhbGwgb2YgdGhlIGNhcGFiaWxpdGllcyBmb3IgYSBk ZXZpY2Ugd2hpY2ggaW1wbGVtZW50cyBFQ0RILCBpdCByZXF1aXJlcyBtdWx0aXBsZSBwYWlycyBv ZiBjYXBhYmlsaXR5IHN0cnVjdHVyZXMgKGFsZ29yaXRobSwga2V5KSB0byBkZWFsIHdpdGggdGhl IGRpZmZlcmVudCBrZXkgdHlwZXMgYW5kIGN1cnZlcyB0aGF0IGFyZSBzdXBwb3J0ZWQuIg0KDQox LiBJcyB0aGUgdXNlIG9mIGEgcGFpciBvZiBjYXBhYmlsaXRpZXMgKGFsZ29yaXRobSBjYXBhYmls aXRpZXMsIGtleSBjYXBhYmlsaXRpZXMpIG5vcm1hdGl2ZSwgb3IganVzdCBhbiBleGFtcGxlIHVz YWdlPyAgSS5lLiBpcyB0aGlzIG9uZSB3YXkgdGhhdCB0aGlzIGNvdWxkIGJlIGFjaGlldmVkLCBv ciB0aGUgb25seSB3YXkgdGhhdCB0aGlzIHdvdWxkIGJlIGFjaGlldmVkLg0KDQoNCiJKdXN0IGFu IGFsZ29yaXRobSBjYXBhYmlsaXR5OiBUaGlzIGlzIHVzZWZ1bCBpZiB5b3Ugd2FudCB0byByZXF1 aXJlIGEgc3BlY2lmaWMgYWxnb3JpdGhtIHN1Y2ggYXMgRUNEU0EsIGJ1dCB5b3UgYXJlIGFnbm9z dGljIGFib3V0IHdoaWNoIGN1cnZlIGlzIGJlaW5nIHVzZWQuIFNlZSB0aGUgZmlyc3QgZXhhbXBs ZS4iDQoNCjIuIElzIHRoZSBjYXBhYmlsaXR5IGFjdHVhbGx5IHNheWluZyB0aGF0IGEgc3BlY2lm aWMgYWxnb3JpdGhtIGlzIGJlaW5nIHVzZWQsIG9yIGlzIGl0IHRoYXQgYSBwYXJ0aWN1bGFyIGtl eSB0eXBlIGlzIGJlaW5nIHVzZWQgZm9yIHRoZSBhbGdvcml0aG0/ICBbR2l2ZW4gdGhhdCB0aGUg YWxnb3JpdGhtIGNhcGFiaWxpdGllcyBkb24ndCBlbmNvZGUgdGhlIGNob2ljZSBvZiBhbGdvcml0 aG0uXQ0KDQoNCiJKdXN0IGEga2V5IHR5cGUgY2FwYWJpbGl0eTogVGhpcyBpcyB1c2VmdWwgaWYg eW91IHdhbnQgdG8gcmVxdWlyZSBhIHNwZWNpZmljIGN1cnZlIHN1Y2ggYXMgUC0yNTYsIGJ1dCB3 aWxsIGFjY2VwdCBhbnkgYWxnb3JpdGhtIHVzaW5nIHRoYXQgY3VydmUgKGUuZy4gYm90aCBFQ0RT QSBhbmQgRUNESCkuIFNlZSB0aGUgc2Vjb25kIGV4YW1wbGUuIg0KDQozLiBQcmVzdW1hYmx5IHRo aXMgZXhhbXBsZSBpcyBhbHNvIGNvbnN0cmFpbmluZyB0aGUga2V5IHR5cGUgdG8gRUMyIGFzIHdl bGwgYXMgdGhlIGN1cnZlIHRvIFAtMjU2Pw0KDQoNCiJCb3RoIGFuIGFsZ29yaXRobSBhbmQgYSBr ZXkgdHlwZSBjYXBhYmlsaXR5OiBUaGlzIGlzIHVzZWQgaWYgb25lIG5lZWRzIHRvIG5haWwgZG93 biBhbGwgb2YgdGhlIG9wdGlvbnMgc3Vycm91bmRpbmcgYW4gYWxnb3JpdGhtIEUuZy4gRWREU0Eg d2l0aCB0aGUgY3VydmUgWDI1NTE5LiBTZWUgdGhlIHRoaXJkIGV4YW1wbGUgd2hpY2gganVzdCBj b25jYXRlbmF0ZXMgdGhlIHR3byBjYXBhYmlsaXRpZXMgdG9nZXRoZXIuIg0KDQo0LiBBbSBJIHJp Z2h0IHRvIGVuc3VyZSB0aGF0IGEgc2VwYXJhdGUgc3BlY2lmaWNhdGlvbiwgd2hlcmUgdGhlIGNh cGFiaWxpdGllcyBzdHJ1Y3R1cmVzIGFyZSBiZWluZyB1c2VkLCB3b3VsZCBzcGVjaWZ5IHRoYXQg dGhlIGNhcGFiaWxpdGllcyBhcmUgZGVmaW5lZCBhcyBhbiBhcnJheSBvZiBhbGdvcml0aG0gY2Fw YWJpbGl0aWVzIGZvbGxvd2VkIGJ5IGtleSB2YWx1ZSBjYXBhYmlsaXRpZXMuIFtSZWxhdGVkIHRv IGNvbW1lbnQgMSBhYm92ZS5dDQoNCg0KTml0czoNCg0KSSB3b3VsZCBzdWdnZXN0IHRoYXQgaXQg d291bGQgYmUgYmV0dGVyIHRvIHN3aXRjaCB0aGUgb3JkZXIgb2YgIjguMiBBc3NpZ25tZW50cyBm b3IgRXhpc3RpbmcgQWxnb3JpdGhtcyIgYW5kICI4LjEgQXNzaWdubWVudHMgZm9yIEV4aXN0aW5n IEtleSBUeXBlcyIsIHNpbmNlIGVsc2V3aGVyZSBpbiB0aGlzIHNlY3Rpb24gdGhlIHRleHQgYWx3 YXlzIHRhbGtzIGFib3V0IGFsZ29yaXRobXMgYmVmb3JlIGtleSB0eXBlcy4NCg0KSW4gdGhlIGV4 YW1wbGVzLCB5b3UgbWF5IHdhbnQgdG8gcmVtaW5kIHRoYXQgdGhlIGFsZ29yaXRobSB0eXBlIGlz IG5vdCBpbmNsdWRlZCBpbiB0aGUgY2FwYWJpbGl0eSBkYXRhIGJlY2F1c2UgaXQgc2hvdWxkIGFs cmVhZHkgYmUga25vd24gZnJvbSBlbHNld2hlcmUuDQoNCkZpbmFsbHksIGluIHRoZSBleGFtcGxl cywgeW91IG1pZ2h0IHdpc2ggdG8gcmVwaGFzZSB0byBhdm9pZCBzZWNvbmQgcGVyc29uIGxhbmd1 YWdlLCBzdWNoIGFzIHVzaW5nICJ5b3UiLg0KDQpSZWdhcmRzLA0KUm9iDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxh cnMuY29tPg0KPiBTZW50OiAxOCBKdW5lIDIwMjAgMTg6NTUNCj4gVG86IFJvYiBXaWx0b24gKHJ3 aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT47ICdUaGUgSUVTRycgPGllc2dAaWV0Zi5vcmc+DQo+ IENjOiBkcmFmdC1pZXRmLWNvc2UtcmZjODE1MmJpcy1hbGdzQGlldGYub3JnOyBjb3NlLWNoYWly c0BpZXRmLm9yZzsNCj4gY29zZUBpZXRmLm9yZzsgJ01hdHRoZXcgTWlsbGVyJyA8bGludXh3b2xm K2lldGZAb3V0ZXItcGxhbmVzLm5ldD4NCj4gU3ViamVjdDogUkU6IFJvYmVydCBXaWx0b24ncyBO byBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtDQo+IGFsZ3MtMDk6ICh3 aXRoIENPTU1FTlQpDQo+IA0KPiBSb2IsDQo+IA0KPiBJIGhhdmUgc3BlbnQgd2F5IHRvbyBsb25n IHRyeWluZyB0byBkbyBlZGl0cyBhbmQgcmUtd3JpdGVzIGFuZCBhZGRpdGlvbnMNCj4gYW5kIGRl bGV0aW9ucyBvbiB0aGlzLiAgSSBkb24ndCB0aGluayB0aGF0IEkgY2FuIGV2ZW4gcmVhZCBpdCBh bnltb3JlLg0KPiBIb3dldmVyLCBodHRwczovL2Nvc2Utd2cuZ2l0aHViLmlvL2Nvc2UtcmZjODE1 MmJpcy9kcmFmdC1pZXRmLWNvc2UtDQo+IHJmYzgxNTJiaXMtYWxncy5odG1sI25hbWUtY29zZS1j YXBhYmlsaXRpZXMgaGFzIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGlzDQo+IHRoYXQgSSB0aGlu ayB3aWxsIGFkZHJlc3MgYWxsIG9mIHlvdXIgY29tbWVudHMuICBQbGVhc2UgcmV2aWV3Lg0KPiAN Cj4gVGhhbmtzLCBKaW0NCj4gDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPg0KPiBTZW50 OiBXZWRuZXNkYXksIEp1bmUgMTAsIDIwMjAgNDowMyBBTQ0KPiBUbzogSmltIFNjaGFhZCA8aWV0 ZkBhdWd1c3RjZWxsYXJzLmNvbT47ICdUaGUgSUVTRycgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBk cmFmdC1pZXRmLWNvc2UtcmZjODE1MmJpcy1hbGdzQGlldGYub3JnOyBjb3NlLWNoYWlyc0BpZXRm Lm9yZzsNCj4gY29zZUBpZXRmLm9yZzsgJ01hdHRoZXcgTWlsbGVyJyA8bGludXh3b2xmK2lldGZA b3V0ZXItcGxhbmVzLm5ldD4NCj4gU3ViamVjdDogUkU6IFJvYmVydCBXaWx0b24ncyBObyBPYmpl Y3Rpb24gb24gZHJhZnQtaWV0Zi1jb3NlLXJmYzgxNTJiaXMtDQo+IGFsZ3MtMDk6ICh3aXRoIENP TU1FTlQpDQo+IA0KPiBIaSBKaW0sDQo+IA0KPiBQbGVhc2Ugc2VlIGlubGluZSAuLi4NCj4gDQo+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBKaW0gU2NoYWFkIDxpZXRm QGF1Z3VzdGNlbGxhcnMuY29tPg0KPiA+IFNlbnQ6IDEwIEp1bmUgMjAyMCAwMDoxMw0KPiA+IFRv OiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+OyAnVGhlIElFU0cnDQo+ ID4gPGllc2dAaWV0Zi5vcmc+DQo+ID4gQ2M6IGRyYWZ0LWlldGYtY29zZS1yZmM4MTUyYmlzLWFs Z3NAaWV0Zi5vcmc7IGNvc2UtY2hhaXJzQGlldGYub3JnOw0KPiA+IGNvc2VAaWV0Zi5vcmc7ICdN YXR0aGV3IE1pbGxlcicgPGxpbnV4d29sZitpZXRmQG91dGVyLXBsYW5lcy5uZXQ+DQo+ID4gU3Vi amVjdDogUkU6IFJvYmVydCBXaWx0b24ncyBObyBPYmplY3Rpb24gb24NCj4gPiBkcmFmdC1pZXRm LWNvc2UtcmZjODE1MmJpcy0NCj4gPiBhbGdzLTA5OiAod2l0aCBDT01NRU5UKQ0KPiA+DQo+ID4N Cj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogUm9iZXJ0IFdp bHRvbiB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+DQo+ID4gU2VudDogVHVlc2Rh eSwgSnVuZSA5LCAyMDIwIDExOjE2IEFNDQo+ID4gVG86IFRoZSBJRVNHIDxpZXNnQGlldGYub3Jn Pg0KPiA+IENjOiBkcmFmdC1pZXRmLWNvc2UtcmZjODE1MmJpcy1hbGdzQGlldGYub3JnOyBjb3Nl LWNoYWlyc0BpZXRmLm9yZzsNCj4gPiBjb3NlQGlldGYub3JnOyBNYXR0aGV3IE1pbGxlciA8bGlu dXh3b2xmK2lldGZAb3V0ZXItcGxhbmVzLm5ldD47DQo+ID4gbGludXh3b2xmK2lldGZAb3V0ZXIt cGxhbmVzLm5ldA0KPiA+IFN1YmplY3Q6IFJvYmVydCBXaWx0b24ncyBObyBPYmplY3Rpb24gb24N Cj4gPiBkcmFmdC1pZXRmLWNvc2UtcmZjODE1MmJpcy1hbGdzLQ0KPiA+IDA5OiAod2l0aCBDT01N RU5UKQ0KPiA+DQo+ID4gUm9iZXJ0IFdpbHRvbiBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJh bGxvdCBwb3NpdGlvbiBmb3INCj4gPiBkcmFmdC1pZXRmLWNvc2UtcmZjODE1MmJpcy1hbGdzLTA5 OiBObyBPYmplY3Rpb24NCj4gPg0KPiA+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhl IHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiA+IGVtYWlsIGFkZHJlc3Nl cyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dA0KPiA+ IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ID4NCj4gPg0KPiA+IFBs ZWFzZSByZWZlciB0bw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rp c2N1c3MtY3JpdGVyaWEuaHRtbA0KPiA+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cg RElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+ID4NCj4gPg0KPiA+IFRoZSBkb2N1bWVu dCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToN Cj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvc2UtcmZj ODE1MmJpcy1hbGdzLw0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBDT01N RU5UOg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4gSSd2ZSBvbmx5 IHJldmlld2VkIHRoZSBkaWZmIGFnYWluc3QgUkZDODE1Mi4gICBUaGUgdmFzdCBtYWpvcml0eSBv ZiB0aGlzDQo+ID4gZG9jdW1lbnQgc2VlbWVkIHRvIGhhdmUgb25seSBtaW5pbWFsIGNoYW5nZXMg YW5kIGxvb2tlZCBmaW5lIGZyb20gd2hhdA0KPiA+IEkgY291bGQgc2VlLg0KPiA+DQo+ID4gQSBm ZXcgbWlub3IgY29tbWVudHMgdGhhdCBtYXkgaGVscCBpbXByb3ZlIHRoZSBkb2N1bWVudDoNCj4g Pg0KPiA+DQo+ID4gOC4gIENPU0UgQ2FwYWJpbGl0aWVzDQo+ID4NCj4gPiAgICBUd28gZGlmZmVy ZW50IHR5cGVzIG9mIGNhcGFiaWxpdGllcyBhcmUgZGVmaW5lZDogY2FwYWJpbGl0aWVzIGZvcg0K PiA+ICAgIGFsZ29yaXRobXMgYW5kIGNhcGFiaWxpdGllcyBmb3Iga2V5IHN0cnVjdHVyZXMuICBP bmNlIGRlZmluZWQgYnkNCj4gPiAgICByZWdpc3RyYXRpb24gd2l0aCBJQU5BLCB0aGUgbGlzdCBv ZiBjYXBhYmlsaXRpZXMgaXMgaW1tdXRhYmxlLiAgSWYgaXQNCj4gPiAgICBpcyBsYXRlciBmb3Vu ZCB0aGF0IGEgbmV3IGNhcGFiaWxpdHkgaXMgbmVlZGVkIGZvciBhIGtleSB0eXBlIG9yIGFuDQo+ ID4gICAgYWxnb3JpdGhtLCBpdCB3aWxsIHJlcXVpcmUgdGhhdCBhIG5ldyBjb2RlIHBvaW50IGJl IGFzc2lnbmVkIHRvIGRlYWwNCj4gPiAgICB3aXRoIHRoYXQuICBBcyBhIGdlbmVyYWwgcnVsZSwg dGhlIGNhcGFiaWxpdGllcyBhcmUgZ29pbmcgdG8gbWFwIHRvDQo+ID4gICAgYWxnb3JpdGhtLXNw ZWNpZmljIGhlYWRlciBwYXJhbWV0ZXJzIG9yIGtleSBwYXJhbWV0ZXJzLCBidXQgdGhleSBkbw0K PiA+ICAgIG5vdCBuZWVkIHRvIGRvIHNvLiAgQW4gZXhhbXBsZSBvZiB0aGlzIGlzIHRoZSBIU1Mt TE1TIGtleQ0KPiA+ICAgIGNhcGFiaWxpdGllcyBkZWZpbmVkIGJlbG93IHdoZXJlIHRoZSBoYXNo IGFsZ29yaXRobSB1c2VkIGlzIGluY2x1ZGVkLg0KPiA+DQo+ID4gRGVmaW5pbmcgdGhlIGNhcGFi aWxpdGllcyBsaXN0IGFzIGltbXV0YWJsZSBzZWVtZWQgbGlrZSBhIG1pc25vbWVyIHRvDQo+ID4g bWUgYmVjYXVzZSBhIG5ldyBJQU5BIHJlZ2lzdHJhdGlvbiB3b3VsZCBtdXRhdGUgdGhlIGxpc3Qu ICBQZXJoYXBzDQo+ID4gdGhpcyBzZW50ZW5jZSwgYW5kIHRoZSBvbmUgZm9sbG93aW5nIGl0LCBj b3VsZCBiZSByZW1vdmVkPw0KPiA+IFtKTFNdIFRoZSB3aG9sZSBvYmplY3QgaXMgdGhhdCBvbmNl IHJlZ2lzdGVyZWQgd2l0aCBJQU5BLCBpdCB3aWxsDQo+ID4gbmV2ZXIgYmUgY2hhbmdlZCBldmVu IGJ5IElBTkEuICBUaHVzIEkgYmVsaWV2ZSB0aGF0IHRoZSB3b3JkIGltbXV0YWJsZQ0KPiA+IHNl ZW1zIHRvIGJlIGNvcnJlY3QuICBJZiB0aGlzIGlzIGNoYW5nZWQgdGhlbiBleGlzdGluZyBzaWdu YXR1cmVzIHdpbGwNCj4gPiBmYWlsIGFuZCBrZXkgZGVyaXZhdGlvbiBmdW5jdGlvbnMgd2lsbCBn ZW5lcmF0ZSBkaWZmZXJlbnQgcmVzdWx0cy4NCj4gW1JXXQ0KPiANCj4gSSdtIHN0aWxsIHNsaWdo dGx5IGNvbmZ1c2VkLCBhbmQgYWxhcyB0aGUgbW9yZSBJIHJlYWQgdGhlIHRleHQgdGhlIG1vcmUN Cj4gY29uZnVzZWQgSSBiZWNvbWUgOy0pDQo+IA0KPiBIZW5jZSBhIGNsYXJpZnlpbmcgcXVlc3Rp b246IERvZXMgInRoZSBsaXN0IG9mIGNhcGFiaWxpdGllcyBpcyBpbW11dGFibGUiLA0KPiBkb2Vz IGl0IG1lYW4gdGhhdCB0aGUgbGlzdCBvZiBjYXBhYmlsaXRpZXMgYXNzb2NpYXRlZCB3aXRoIGEg Z2l2ZW4NCj4gYWxnb3JpdGhtIG9yIGtleSBzdHJ1Y3R1cmUgaXMgaW1tdXRhYmxlPyAgT3IgZG9l cyBpdCBtZWFuIHRoYXQgdGhlIGVudGlyZQ0KPiBsaXN0IG9mIGRlZmluZWQgY2FwYWJpbGl0aWVz IGFzIGEgc2V0IGlzIGltbXV0YWJsZT8NCj4gW0pMU10gVGhlIGludGVudGlvbiBpcyB0byBzYXkg dGhhdCBpdCBpcyBmaXhlZCBmb3IgYSBzaW5nbGUgYWxnb3JpdGhtIG9yDQo+IGtleSB0eXBlIGFu ZCBub3QgdGhlIGVudGlyZSBsaXN0Lg0KPiANCj4gQW5kIGluIHRoZSBmb2xsb3dpbmcgcGFyYWdy YXBoLCB3aGVyZSBpcyBzdGF0ZXMgIlRoZSBjYXBhYmlsaXR5IHN0cnVjdHVyZQ0KPiBpcyBhbiBh cnJheSBvZiB2YWx1ZXMiIGRvZXMgaXQgbWVhbiB0aGUgY2FwYWJpbGl0eSBzdHJ1Y3R1cmUgYXNz b2NpYXRlZA0KPiB3aXRoIGEgcGFydGljdWxhciBhbGdvcml0aG0gb3Iga2V5Pw0KPiBbSkxTXSBZ ZXMNCj4gDQo+IEFub3RoZXIgcXVlc3Rpb24gcmVsYXRlcyB0byAiVGhlIGNhcGFiaWxpdHkgc3Ry dWN0dXJlIGlzIGFuIGFycmF5IG9mDQo+IHZhbHVlcywiLCBkb2VzIHRoaXMgbWVhbiAiVGhlIGNh cGFiaWxpdHkgc3RydWN0dXJlIGZvciBhIGdpdmVuIGFsZ29yaXRobQ0KPiBvciBrZXkgaXMgYW4g b3JkZXJlZCBhcnJheSBvZiB2YWx1ZXMsIHRoZSBvcmRlciAuLi4gIg0KPiBbSkxTXSBZZXMNCj4g DQo+IFRoZSBwYXJhZ3JhcGggYmVsb3cgYWxzbyBtZW50aW9ucyBtdWx0aXBsZSBwYWlycyBvZiBj YXBhYmlsaXR5IHN0cnVjdHVyZXMuDQo+IERvIHRoZSBjYXBhYmlsaXRpZXMgYWx3YXlzIGNvbWUg YXMgYSBwYWlyIG9mIGFuIGFsZ29yaXRobSBhbmQgYSBrZXk/ICBJZg0KPiB0aGVyZSBhcmUgbXVs dGlwbGUgcGFpcnMgdGhlbiBob3cgYXJlIHRoZXkgZW5jb2RlZCwgcHJlc3VtYWJseSBhcyBhbiBh cnJheQ0KPiBvZiBwYWlycz8gIElmIGNhcGFiaWxpdGllcyBkbyBub3QgYWx3YXlzIGNvbWUgYXMg YSBwYWlyIHRoZW4geW91IGRvIHlvdQ0KPiBkaWZmZXJlbnRpYXRlIGJldHdlZW4gYSBjYXBhYmls aXR5IGRlZmluaW5nIGFuIGFsZ29yaXRobSBhbmQgb25lIGRlZmluaW5nDQo+IGEga2V5Pw0KPiAN Cj4gPg0KPiA+ICAgIFRoZSBjYXBhYmlsaXR5IHN0cnVjdHVyZSBpcyBhbiBhcnJheSBvZiB2YWx1 ZXMsIHRoZSBvcmRlciBiZWluZw0KPiA+ICAgIGRlcGVuZGVudCBvbiB0aGUgc3BlY2lmaWMgYWxn b3JpdGhtIG9yIGtleS4gIEZvciBhbiBhbGdvcml0aG0sIHRoZQ0KPiA+ICAgIGZpcnN0IGVsZW1l bnQgc2hvdWxkIGFsd2F5cyBiZSBhIGtleSB0eXBlIHZhbHVlLCBidXQgdGhlIGl0ZW1zIHRoYXQN Cj4gPiAgICBhcmUgc3BlY2lmaWMgdG8gYSBrZXkgc2hvdWxkIG5vdCBiZSBpbmNsdWRlZCBpbiB0 aGUgYWxnb3JpdGhtDQo+ID4gICAgY2FwYWJpbGl0aWVzLiAgVGhpcyBtZWFucyB0aGF0IGlmIG9u ZSB3aXNoZXMgdG8gZW51bWVyYXRlIGFsbCBvZiB0aGUNCj4gPiAgICBjYXBhYmlsaXRpZXMgZm9y IGEgZGV2aWNlIHdoaWNoIGltcGxlbWVudHMgRUNESCwgaXQgcmVxdWlyZXMgbXVsdGlwbGUNCj4g PiAgICBwYWlycyBvZiBjYXBhYmlsaXR5IHN0cnVjdHVyZXMgKGFsZ29yaXRobSwga2V5KSB0byBk ZWFsIHdpdGggdGhlDQo+ID4gICAgZGlmZmVyZW50IGtleSB0eXBlcyBhbmQgY3VydmVzIHRoYXQg YXJlIHN1cHBvcnRlZC4gIEZvciBhIGtleSwgdGhlDQo+ID4gICAgZmlyc3QgZWxlbWVudCBzaG91 bGQgYWxzbyBiZSBhIGtleSB0eXBlIHZhbHVlLiAgV2hpbGUgdGhpcyBtZWFucyB0aGF0DQo+ID4g ICAgdGhpcyB2YWx1ZSB3aWxsIGJlIGR1cGxpY2F0ZWQgaWYgYm90aCBhbiBhbGdvcml0aG0gYW5k IGtleSBjYXBhYmlsaXR5DQo+ID4gICAgYXJlIHVzZWQsIHRoZSBrZXkgdHlwZSBpcyBuZWVkZWQg aW4gb3JkZXIgdG8gdW5kZXJzdGFuZCB0aGUgcmVzdCBvZg0KPiA+ICAgIHRoZSB2YWx1ZXMuDQo+ ID4NCj4gPiBTaG91bGQgeW91IGJlIHVzaW5nIFJGQyAyMTE5IGxhbmd1YWdlIGhlcmU/ICBBbmQg c2hvdWxkICIga2V5IHNob3VsZA0KPiA+IG5vdCBiZSBpbmNsdWRlZCIgYmUgIk1VU1QgTk9UIj8N Cj4gPiBbSkxTXSBSZXNwb25kZWQgdG8gdGhpcyBwb2ludCBpbiBSb21hbidzIGNvbW1lbnRzLg0K PiA+DQo+ID4gRm9yIHRoZSBFQ0RIIGNhc2UsIGRvZXMgdGhhdCBtZWFuIHRoYXQgdGhlICJhbGdv cml0aG0iIGVudHJ5IHdpbGwgYmUNCj4gPiBkdXBsaWNhdGVkIHdpdGggZGlmZmVyZW50ICJrZXki IGVudHJpZXM/ICBJZiBzbywgd291bGQgaXQgaGVscCBjbGFyaWZ5DQo+ID4gdG8gZXhwbGljaXRs eSBzdGF0ZSB0aGlzPw0KPiA+IFtKTFNdIFdvdWxkIHBvaW50aW5nIHRvIHRoZSBzZWNvbmQgYW5k IHRoaXJkIGV4YW1wbGVzIGluIHNlY3Rpb24gOC4zDQo+ID4gYWxvbmcgd2l0aCBzb21lIGV4cGxh bmF0b3J5IHRleHQ/DQo+IFtSV10NCj4gDQo+IFBlcmhhcHMsIGJ1dCBJIHRoaW5rIHRoYXQgaXQg d291bGQgYWxzbyBiZSB1c2VmdWwgdG8gaGF2ZSBhbiBleGFtcGxlIG9mDQo+IHN1cHBvcnRpbmcg RUNESC1FUyB3aXRoIGJvdGggUC0yNTYgYW5kIFgyNTUxOSBjdXJ2ZXMsIGFuZCBob3cgdGhhdCB3 b3VsZA0KPiBiZSBlbmNvZGVkIChpZiB0aGF0IG1ha2VzIHNlbnNlKS4NCj4gDQo+IEkgYWxzbyBj b3VsZG4ndCBjb252aW5jZSBteXNlbGYgdGhhdCB0aGUgbnVtZXJpY2FsIHZhbHVlcyB0aGF0IGFy ZSB1c2VkIGluDQo+IHRoZSBleGFtcGxlcyBhcmUgbmVjZXNzYXJ5IHJpZ2h0LCBwbGVhc2UgY2Fu IHlvdSBjaGVjayB0aGF0IHRoZXkgYXJlLg0KPiBFLmcuLCB0aGUgZmlyc3QgdHdvIGV4YW1wbGUg aGF2ZSB0aGUgc2FtZSBudW1lcmljIGVuY29kaW5nLCBhbmQgdGhlIHR3bw0KPiBFQ0RILUVTIGhh dmUgZGlmZmVyZW50IGVuY29kaW5ncyBvZiB0aGUgYWxnb3JpdGhtLiAgQnV0IHBlcmhhcHMgdGhh dCBpcw0KPiBqdXN0IG15IGNvbmZ1c2lvbiBhYm91dCBob3cgdGhpcyB3b3Jrcy4NCj4gDQo+IFJl Z2FyZHMsDQo+IFJvYg0KPiANCj4gDQo+ID4NCj4gPiBKaW0NCj4gPg0KPiA+IFRoYW5rcywNCj4g PiBSb2INCj4gPg0KPiA+DQo+IA0KDQo= From nobody Fri Jun 19 09:08:56 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE363A0893; Fri, 19 Jun 2020 09:08:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: lflynn@amsl.com, kaduk@mit.edu, cose@ietf.org, cose-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159258293457.18032.1277520699698107982@ietfa.amsl.com> Date: Fri, 19 Jun 2020 09:08:54 -0700 Archived-At: Subject: [COSE] cose - Update to a Meeting Session Request for IETF 108 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 16:08:55 -0000 An update to a meeting session request has just been submitted by Liz Flynn, on behalf of the cose working group. --------------------------------------------------------- Working Group Name: CBOR Object Signing and Encryption Area Name: Security Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: core dispatch lamps lpwan saag secdispatch Technology Overlap: cfrg rats teep suit Key Participant Conflict: ace cbor lake People who must be present: Matthew A. Miller Benjamin Kaduk Ivaylo Petrov Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jun 19 15:07:19 2020 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 83B3F3A0EBF for ; Fri, 19 Jun 2020 15:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=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 ouab41M6eish for ; Fri, 19 Jun 2020 15:07:15 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650094.outbound.protection.outlook.com [40.107.65.94]) (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 A257F3A0EBD for ; Fri, 19 Jun 2020 15:07:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T2zARTigAVapzKgkIvvs3o6f/CxkUqbwWbKRsZqCrMmdrFPPVXgS91ts8O8yyUvIoEa+KMu9Zd//cy7xu2NBeYfOpyZC38Hv0Nxw1H8FuoKL+xQ3GEuGjfjL9ev5C1W4fJxzrSW+MiaPWamjgWKl/O+kfPyENjwUKrKV14u2wOLk9u24aKaf+x0bK5wTZuaNXz0cTpQjB2GejAVq/JrdX8lIkmmBFa6IYmQTvdsWS9D5xM81J8hUZ6eA6kkf82rEB4SqfeTLa6S2c1XiPVa/ZqJ6WyJN9wU45zfmQbN4YBWQNUVYP0EuLaj17SM/db2zXwGDvWUqbZGB/5upjIHLTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZVk5S4LmXtJ9LaTLt5hRVAqtx/B7wgKspViibhCFOPE=; b=FYvi0v/3doLvcJt4yjRKFQ9ihR11bsXaBBu9Q1NX0avFT8FnSWuVBi12/Mdu6F+tiGNXnr8eaFogSFEnYLboXAa0Fr3jtswLd6EmZ9anr8mjAgT0ddjvrfK+0yDy9qiYaDrBlWER2ploU1LjacInCebb8kHZ9cd/rOeDk3Zg548ZAyJAJ9Bs6nsRzRCg5X2PLA2DT08l0vLTdoaDoKURWdYJMA+9eSw37FUGRhe2jIfxHA1vQC5RXizmR+n4PhjhYBLfDQt9dQ5gNxsYY+qyoJROlg7XhkFso/+TtttTtgVsVxYwQbejMWPDJW/dzytuf8HgcxlKIJcrp/lpIKa7yg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZVk5S4LmXtJ9LaTLt5hRVAqtx/B7wgKspViibhCFOPE=; b=G8zYvE17Hss56OmvtPIovMednkxnBUfXropg58KsURwk0WzMsTpS+7+UYPpGnd/xCuw60U47x0Wasp0u3DIhlijLCRHgibjR5zcLQatT1NvgxzL81W2NsKzzrX0jajwDKFohs82fchNyEvXUDpQY2zhsLQej2354m8jdkvd7/1M= Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0762.namprd00.prod.outlook.com (2603:10b6:610:61::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3157.0; Fri, 19 Jun 2020 22:07:13 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::3c44:1c81:e278:edb0]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::3c44:1c81:e278:edb0%2]) with mapi id 15.20.3157.000; Fri, 19 Jun 2020 22:07:13 +0000 From: Mike Jones To: "cose@ietf.org" Thread-Topic: Registrations for all WebAuthn algorithm identifiers completed Thread-Index: AdZGZkubGYowJ76XQrmNPXHw1rfwgAAH6B2w Date: Fri, 19 Jun 2020 22:07:13 +0000 Message-ID: References: In-Reply-To: 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_ActionId=d5f88146-6734-4547-8e3c-16c411ce7d17; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-19T18:20:08Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: fce98813-d094-43c3-217a-08d8149d1f16 x-ms-traffictypediagnostic: CH2PR00MB0762: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dMI2LsfBrrtJ82jT/jenf8lIZH0kJRA0PMzn/NmiwJkCJ3/uSX6TkGrwJvp2zA8qvJRDErIBI7S2aOYuBSKV5x62YgELeLH9E0M3ANPzBcL3X3zPCCiWBrO91dTSWc0NmJRP27KrIi9lkWG7emIJ7yFUVxhXHLmUAW1Y6vmxLeX7EBAwqpqO0SX+zWTF/ifPgw8Pg+2LK7CiCIQDsLlV6BGJ49YYeE09l5B5vcZJTjlnNc3GtBAiWL1/571n0F5HWBctJvbTBSYeTcUpQgUaYlm3kOC1EsP7bJMXwqlayStul7fAkDzXuVqUHmCW+snZ7LaEnyWKxp2z5o9qByBzgS/rbQMYUBXGHkgZr+3dH/dEz2zTK+FsWXDm7iKUQO23Ljdn3OUgynXRVdz1qMDet5rfC3j4oKsTe3Q9H+/+jiNv7GoBk7VNpBTXG3TVpyWU x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(376002)(346002)(136003)(366004)(478600001)(76116006)(66556008)(66476007)(66446008)(64756008)(66946007)(55016002)(6916009)(966005)(53546011)(5660300002)(9686003)(52536014)(71200400001)(2940100002)(2906002)(8936002)(8676002)(82960400001)(186003)(26005)(83380400001)(8990500004)(7696005)(316002)(10290500003)(82950400001)(86362001)(6506007)(166002)(33656002)(6606295002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ZMVE3B1NtkA/W71DLeeXzJk/gTRkU1dogJ0n36h7cQDuBfn0Lqbq0z4VVNodYiCreEx1xDZMCjmFexpq4phWy447qXpwpC+srwJHKzgUaOfyZePHr/hUtqDUW1qux1MdrWxsLFG1TKaAbvX9FAP+DfVP7DUwBhiAwQ60fRvbOOfjvB3l3Dwg4pMvD0VwOOeEYxTxIDloX9UciP7Jr5mES56nUa0eQV7DhOnnxnb+RjUqO3Qpja8lA4Ya8Umxyq7yLB68XfjgMtQW4rVS2yai50YLmw4zulo6bI6npbrleVx/zdO0u+s2qtY2d0bvXKU7NE5zMHrSIzn3p4weduOZykITEk1mMsfbQSfn/oDtB221sal+l/AAOP0sFGdrfQj3LWQsYmDaAIlWvACkhEoK54tg137Npo1wuEd4wGiY6Qvcm5kh485N4XY4AdRUfMakWw8NGc0Ct6gRYCHsy3yK/Gce3jyluOiZTZxeD9a6MxQ= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0678CAC5062A1747AD36F9A4F5980CH2PR00MB0678namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fce98813-d094-43c3-217a-08d8149d1f16 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 22:07:13.5755 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: S1zjacPU1tS+BjgqGW2rX93Yk3ORUui/qCAo+QkGE3LzIuW5/YeJ51x9ILKWMYUM4vaSWNETfe1DyO/ZRg7CpA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0762 Archived-At: Subject: [COSE] FW: Registrations for all WebAuthn algorithm identifiers completed X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 22:07:18 -0000 --_000_CH2PR00MB0678CAC5062A1747AD36F9A4F5980CH2PR00MB0678namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Mike Jones Sent: Friday, June 19, 2020 3:06 PM To: 'public-webauthn@w3.org' Subject: Registrations for all WebAuthn algorithm identifiers completed We wrote the specification COSE and JOSE Registrations for WebAuthn Algorit= hms to = create and register COSE and JOSE algorithm and elliptic curve identifiers = for algorithms used by WebAuthn and CTAP2 that didn't yet exist. I'm happy= to report that all these registrations are now complete and the specificat= ion has progressed to the RFC Editor. Thanks to the COSE working group for supporting this work. Search for WebAuthn in the IANA COSE Registry and the IANA JOSE Registry to see the registrations. These are now stable and = can be used by applications, both in the WebAuthn/FIDO2 space and for other= application areas, including decentralized identity (where the secp256k1 "= bitcoin curve" is in widespread use). The algorithms registered are: * RS256 - RSASSA-PKCS1-v1_5 using SHA-256 - new for COSE * RS384 - RSASSA-PKCS1-v1_5 using SHA-384 - new for COSE * RS512 - RSASSA-PKCS1-v1_5 using SHA-512 - new for COSE * RS1 - RSASSA-PKCS1-v1_5 using SHA-1 - new for COSE * ES256K - ECDSA using secp256k1 curve and SHA-256 - new for COSE and= JOSE The elliptic curves registered are: * secp256k1 - SECG secp256k1 curve - new for COSE and JOSE -- Mike P.S. This notice was also posted at https://self-issued.info/?p=3D2106 an= d as @selfissued. --_000_CH2PR00MB0678CAC5062A1747AD36F9A4F5980CH2PR00MB0678namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Mike Jones
Sent: Friday, June 19, 2020 3:06 PM
To: 'public-webauthn@w3.org' <public-webauthn@w3.org>
Subject: Registrations for all WebAuthn algorithm identifiers comple= ted

 

We wrote the specification COSE and JOSE Regi= strations for WebAuthn Algorithms to create and register COSE and J= OSE algorithm and elliptic curve identifiers for algorithms used by WebAuthn and CTAP2 that didn’t yet exist.&nbs= p; I’m happy to report that all these registrations are now complete = and the specification has progressed to the RFC Editor.  Thanks to the COSE working group<= /a> for supporting this work.

 

Search for WebAuthn in the IANA COSE Registry and the IANA JOSE Registry to see the registrations.  These are now stable= and can be used by applications, both in the WebAuthn/FIDO2 space and for = other application areas, including decentralized identity (where the secp256k1 “bitcoin curve” is in widespread use).

 

The algorithms registered are:

  • RS256<= /span> – RSASSA-PKCS1-v1_5 using SHA= -256 – new for COSE
=
·       RS384 – RSASSA-PKCS1-v=
1_5 using SHA-384 – new for COSE
=
·       RS512 – RSASSA-PKCS1-v=
1_5 using SHA-512 – new for COSE
=
·       RS1 – RSASSA-PKCS1-v1_=
5 using SHA-1 – new for COSE
=
·       ES256K – ECDSA using s=
ecp256k1 curve and SHA-256 – new for COSE and JOSE<=
/pre>

 


The elliptic curves registered are:


=
·       secp256k1 – SECG secp2=
56k1 curve – new for COSE and JOSE


 


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


 


P.S.   This notice was also posted at 
https://self-issued.info/?p=3D2106 and as 
@selfissued.


 
--_000_CH2PR00MB0678CAC5062A1747AD36F9A4F5980CH2PR00MB0678namp_-- From nobody Sat Jun 20 19:27:49 2020 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 4F4143A083F; Sat, 20 Jun 2020 19:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 eNMaDN4pFzX7; Sat, 20 Jun 2020 19:27:45 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D62F73A0840; Sat, 20 Jun 2020 19:27:44 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05L2RZbw008951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 20 Jun 2020 22:27:38 -0400 Date: Sat, 20 Jun 2020 19:27:35 -0700 From: Benjamin Kaduk To: Jim Schaad Cc: "'The IESG'" , draft-ietf-cose-rfc8152bis-algs@ietf.org, cose-chairs@ietf.org, "'Matthew Miller'" , cose@ietf.org Message-ID: <20200621022735.GD11992@kduck.mit.edu> References: <159183990940.7725.14952700358572148848@ietfa.amsl.com> <01b101d64599$56ddaf10$04990d30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <01b101d64599$56ddaf10$04990d30$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-algs-09: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 02:27:47 -0000 On Thu, Jun 18, 2020 at 10:53:10AM -0700, Jim Schaad wrote: > > > > -----Original Message----- > > From: Benjamin Kaduk via Datatracker > > Sent: Wednesday, June 10, 2020 6:45 PM > > To: The IESG > > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; > > cose@ietf.org; Matthew Miller ; > > linuxwolf+ietf@outer-planes.net > > Subject: Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-algs-09: (with > > DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-cose-rfc8152bis-algs-09: Discuss > > > > When responding, please keep the subject line intact and reply to all email > > addresses included in the To and CC lines. (Feel free to cut this introductory > > paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I think we need to check the [MAC] reference; following links (and chasing > > redirects) seems to only find a 1985 publication that talks about DES, with no > > mention of AES-CBC-MAC. > [JLS] This is one of the dangers of using algorithms are not considered to be "good". The first attacks on it were published in 2000 as far as I know. This is why we should be using CMAC but too many people only do the CBC-MAC. > > This is the reference that NIST SP800-38B uses > A. Menezes, P. van Oorschot, S. Vanstone, Handbook of Applied Cryptography, CRC Press, Inc., Boca Raton (1996). That looks like something that would work (though I no longer have an easily accessible copy). > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > It's interesting that both -struct and -algs make the claim in the Abstract that > > "this specification describes how to create and process signatures, message > > authentication codes, and encryption using CBOR for serialization". Shouldn't > > that only be true for one of them? > > > > I'd really like to see a reference for the analysis of and validity/safety of the > > deviations from RFC 5869 HKDF, in Section 5.1. > [JLS] I am going to assume you are referring to using AES for the PRF. I don't know if such a thing exists. I can tell you where I got my personal analysis however. When the TLS 1.3 design group was meeting in Seattle, I spent about 20 minutes discussion what the required capabilities of the PRF are needed to get things to work correctly. At least part of the discussion in the group which occurred around the same time was the ability to break the two halves of HKDF separated the way that TLS does. AES-CBC-MAC as the PRF, but also for sometimes skipping the extract step. > Found something: https://eprint.iacr.org/2010/264.pdf look in appendix D point 4. I think this is probably also what Bob Moskowitz came up with when he was using the analogous CMAC-based KDF for HIP-DEX. Definitely add it as a reference. I do note that "the analytical results in [the CBC-MAC] case are much more restricted than with HMAC" and also that point 5 discusses a modification of K(1) that "may be advisable with other PRF modes (such as CBC-MAC)". I suppose that we cannot safely make that modification at this time, at least without assigning new codepoints, as it would break interoperability with existing deployments.. > > > > Section 1 > > > > Should we refer to RFC 8259 by its STD number (90)? > Done > > > > > Section 1.3 > > > > We don't seem to use the "AE" term (just -struct does). > [JLS] I copied over the new definitions from -struct. I would rather have it than not have it. > > > > > Section 2.1.1 > > > > Note: Use of a deterministic signature technique is a good idea even > > when good random number generation exists. Doing so both reduces the > > > > Note the ongoing work in the CFRG on "deterministic signatures with additional > > randomness" (the name has been changing a bit recently), and fault attacks on > > deterministic signatures. > Done - including the reference. > > > > > Section 2.2.1 > > > > How public values are computed is not the same when looking at EdDSA > > and Elliptic Curve Diffie-Hellman (ECDH); for this reason, they > > should not be used with the other algorithm. > > > > Just to check: the claim is that EdDSA and ECDH compute public values > > differently (not EdDSA and ECDSA?), but that EdDSA keys should not be used > > with algorithms other than EdDSA? > [JLS] > > > > If batch signature verification is performed, a well-seeded > > cryptographic random number generator is REQUIRED. Signing and non- > > batch signature verification are deterministic operations and do not > > need random numbers of any kind. > > > > RFC 8032 doesn't talk about "batch" at all, so a reference is probably in order. > [JLS] Section 8.2 of RFC 8032. It looks like they changed the wording a bit from an earlier verion. I see it now (which just serves to indicate the section reference is helpful :) > > > > Section 3.1 > > > > Some recipient algorithms transport the key, while others derive a > > key from secret data. For those algorithms that transport the key > > (such as AES Key Wrap), the size of the HMAC key SHOULD be the same > > size as the underlying hash function. For those algorithms that > > derive the key (such as ECDH), the derived key MUST be the same size > > as the underlying hash function. > > > > "same size as the output of the underlying hash function", please -- hash > > functions can also have an internal block size that is larger. > [JLS] Done. > > > > > Section 3.2.1 > > > > * A single key must only be used for messages of a fixed or known > > length. If this is not the case, an attacker will be able to > > > > What's an example of a known-but-not-fixed length message? Just something > > with internal framing? > [JLS] This is a length extension problem. You need to know that the message you validated is the same length as the message that was MAC-ed by the sender. This is the reason for CMAC coming into existence. Okay. Would "self-describing length" work? > > > > Section 4.1 > > > > The Galois/Counter Mode (GCM) mode is a generic authenticated > > encryption block cipher mode defined in [AES-GCM]. The GCM mode is > > combined with the AES block encryption algorithm to define an AEAD > > cipher. > > > > GCM on its own is merely AE but AES-GCM is AEAD? That doesn't seem to add > > up... > [JLS] Actually, GCM is not an AE algorithm, it is a mode. Ok - it now reads AEAD. > > > > > Section 6.1.2 > > > > If the salt/nonce value is generated randomly, then it is suggested > > that the length of the random value be the same length as the hash > > function underlying HKDF. While there is no way to guarantee that it > > > > "output length of the hash function", please. > [JLS] Done. > > > > > Section 6.2, 6.3, 6.4 > > > > Why does Direct Key [encryption] get its own top-level subsection with > > reference to -struct, but we jump straight into AES Key Wrap without a > > wrapping "Key Wrap" subsection or -struct reference, and likewise for "Direct > > Key Agreement" and "Key Agreement with Key Wrap"? It feels like Section 6.1 > > is the outlier here. > > > > Section 6.3 > > > > be unique for the pair of keys being used. It is acceptable to > > use a global counter that is incremented for every static-static > > operation and use the resulting value. When using static keys, > > > > Perhaps say something strongly worded about storing the updated counter > > value to permanent storage before using the resulting key? > [JLS] Done. > > > > > Section 7.2 > > > > s/X25591/X25519/ > [JLS] Yep > > > > > Section 8 > > > > The algorithm identifier is not part of the capabilities data as it > > should already be part of message structure. There is a presumption > > in the way that this is laid out is that the algorithm identifier > > > > nit: strike the last "is". > > > > itself is not needed to be a part of this as it is specified in a > > different location. > > > > nit(?): "be a part of this" is a little vague/informal. > > > > capabilities. This means that if one wishes to enumerate all of the > > capabilities for a device which implements ECDH, it requires multiple > > pairs of capability structures (algorithm, key) to deal with the > > different key types and curves that are supported. For a key, the > > > > An example of this would be pretty helpful. > > > > Section 8.1 > > > > * OKP, EC2: The list of capabilities is: > > > > - The key type value. (1 for OKP or 2 for EC2.) > > > > - One curve for that key type from the "COSE Elliptic Curve" > > registry. > > > > Am I reading this right that the idea is to use capabilities to lock a key down to > > a single curve? > > > > * Symmetric: The list of capabilities is: > > > > - The key type value (4). > > > > but we're not using this opportunity to indicate whether a symmetric key is for > > encryption vs. HMAC? > > > > Section 8.2 > > > > (from the "COSE Key Types" Registry). It is expected future > > registered algorithms could have zero, one, or multiple elements. > > > > nit: missing "that". > [JLS] Section 8 has been re-written - you are going to need to review again. Okay, I'll wait for the new revision. > > > > Section 10 > > > > Is [this document] going to be added as a reference on these registries? > > Should it replace or augment 8152 in that role? > [JLS] We will see what happens w/ the question I sent to Barry about Jean-Marc's DISCUSS on -struct. It applies to this document as well. Was I supposed to see a question you asked Barry in response to Jean-Marc's response to my Discuss ballot? (I don't.) > > > > I think that the COSE Header Algorithm Parameters Registry updates need to > > be in this document, not -struct. > [JLS] Done. > > > > Section 10.1, 10.2 > > > > Do we want to say anything about the encoded verson of the Capabilities array > > being an array of integers? > [JLS] It isn't. I can be either integers or text strings. > > > > > Section 10.2 > > > > Why is the word "reserved" in the description for the IV-GENERATION > > algorithm? > [JLS] I did reserve this at one point and finally am registering it. - Gone. > > > > > Section 11 > > > > I'm not 100% sure that we want the security considerations to be so close to > > identical between -struct and -algs. > [JLS] I will take another pass at trying to delete things. > > > > > One area that has been starting to get exposure is doing traffic > > analysis of encrypted messages based on the length of the message. > > > > I think this may have graduated from "starting" to be more of a mainstream > > thing :) > [JLS] I guess I should go and see if you had any other comments. > > > > > Section 12.1 > > > > Trying to chase [MAC] gives me a "reference has moved" notice. > > I guess there's a newer version? > [JLS] Why do I feel like I discussed this one already? -- Ah - because it is a Discuss. Oops, I guess I forgot to delete the corresponding COMMENT; sorry. > > > > Section 12.2 > > > > I think RFC 8017 needs to be normative, since we use it for I2OSP > [JLS] Yeah - that makes sense. > > > > > Acknowledgments > > > > Gran could probably get his proper name, now. > [JLS] done. Thanks for the updates; I'll look for the revised I-D. -Ben From nobody Wed Jun 24 19:45:43 2020 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 4261E3A123C; Wed, 24 Jun 2020 19:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 BM4SvaCOthBI; Wed, 24 Jun 2020 19:45:35 -0700 (PDT) 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 6AF7C3A07C5; Wed, 24 Jun 2020 19:45:34 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 24 Jun 2020 19:45:09 -0700 From: Jim Schaad To: 'Benjamin Kaduk' CC: 'The IESG' , , , 'Matthew Miller' , References: <159183990940.7725.14952700358572148848@ietfa.amsl.com> <01b101d64599$56ddaf10$04990d30$@augustcellars.com> <20200621022735.GD11992@kduck.mit.edu> In-Reply-To: <20200621022735.GD11992@kduck.mit.edu> Date: Wed, 24 Jun 2020 19:45:08 -0700 Message-ID: <01b101d64a9a$a5d4bd10$f17e3730$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQLNMCuwZrzKLnHZ+xfW3Sbr0xE1gAGarrJYAogYeMum2YNuAA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-algs-09: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 02:45:37 -0000 > -----Original Message----- > From: Benjamin Kaduk > Sent: Saturday, June 20, 2020 7:28 PM > To: Jim Schaad > Cc: 'The IESG' ; draft-ietf-cose-rfc8152bis-algs@ietf.org; cose- > chairs@ietf.org; 'Matthew Miller' ; > cose@ietf.org > Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis- > algs-09: (with DISCUSS and COMMENT) > > On Thu, Jun 18, 2020 at 10:53:10AM -0700, Jim Schaad wrote: > > > > > > > -----Original Message----- > > > From: Benjamin Kaduk via Datatracker > > > Sent: Wednesday, June 10, 2020 6:45 PM > > > To: The IESG > > > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; > > > cose@ietf.org; Matthew Miller ; > > > linuxwolf+ietf@outer-planes.net > > > Subject: Benjamin Kaduk's Discuss on > > > draft-ietf-cose-rfc8152bis-algs-09: (with DISCUSS and COMMENT) > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-cose-rfc8152bis-algs-09: Discuss > > > > > > When responding, please keep the subject line intact and reply to > > > all email addresses included in the To and CC lines. (Feel free to > > > cut this introductory paragraph, however.) > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > It's interesting that both -struct and -algs make the claim in the > > > Abstract that "this specification describes how to create and > > > process signatures, message authentication codes, and encryption > > > using CBOR for serialization". Shouldn't that only be true for one of them? [JLS] I missed this one - changed. > > > > > > I'd really like to see a reference for the analysis of and > > > validity/safety of the deviations from RFC 5869 HKDF, in Section 5.1. > > [JLS] I am going to assume you are referring to using AES for the PRF. I don't > know if such a thing exists. I can tell you where I got my personal analysis > however. When the TLS 1.3 design group was meeting in Seattle, I spent about > 20 minutes discussion what the required capabilities of the PRF are needed to > get things to work correctly. At least part of the discussion in the group which > occurred around the same time was the ability to break the two halves of HKDF > separated the way that TLS does. > > AES-CBC-MAC as the PRF, but also for sometimes skipping the extract step. > > > Found something: https://eprint.iacr.org/2010/264.pdf look in appendix D > point 4. > > I think this is probably also what Bob Moskowitz came up with when he was > using the analogous CMAC-based KDF for HIP-DEX. Definitely add it as a > reference. > > I do note that "the analytical results in [the CBC-MAC] case are much more > restricted than with HMAC" and also that point 5 discusses a modification of > K(1) that "may be advisable with other PRF modes (such as CBC-MAC)". > I suppose that we cannot safely make that modification at this time, at least > without assigning new codepoints, as it would break interoperability with > existing deployments.. [JLS] I have not seen that before. It is interesting but since it is not in the RFC I am not sure that doing so would be a good idea. I think I would rather just switch to KMAC personally. > > > > > > > > Section 2.2.1 > > > > > > How public values are computed is not the same when looking at EdDSA > > > and Elliptic Curve Diffie-Hellman (ECDH); for this reason, they > > > should not be used with the other algorithm. > > > > > > Just to check: the claim is that EdDSA and ECDH compute public > > > values differently (not EdDSA and ECDSA?), but that EdDSA keys > > > should not be used with algorithms other than EdDSA? > > [JLS] Yes > > > > > > If batch signature verification is performed, a well-seeded > > > cryptographic random number generator is REQUIRED. Signing and non- > > > batch signature verification are deterministic operations and do not > > > need random numbers of any kind. > > > > > > RFC 8032 doesn't talk about "batch" at all, so a reference is probably in > order. > > [JLS] Section 8.2 of RFC 8032. It looks like they changed the wording a bit > from an earlier verion. > > I see it now (which just serves to indicate the section reference is helpful :) > > > > > > > Section 3.2.1 > > > > > > * A single key must only be used for messages of a fixed or known > > > length. If this is not the case, an attacker will be able to > > > > > > What's an example of a known-but-not-fixed length message? Just > > > something with internal framing? > > [JLS] This is a length extension problem. You need to know that the message > you validated is the same length as the message that was MAC-ed by the > sender. This is the reason for CMAC coming into existence. > > Okay. Would "self-describing length" work? [JLS] I think so, but a large part depends on what you mean by "self-describing length". If you started with a two byte value which is the length of the data then yes I think that would work. I would be worried about the ability to do any bit-flipping on this but I think it would kill the extension attack. However, if you are using CBOR and have an array of 4 elements that would not work. > > > Section 6.2, 6.3, 6.4 > > > > > > Why does Direct Key [encryption] get its own top-level subsection > > > with reference to -struct, but we jump straight into AES Key Wrap > > > without a wrapping "Key Wrap" subsection or -struct reference, and > > > likewise for "Direct Key Agreement" and "Key Agreement with Key > > > Wrap"? It feels like Section 6.1 is the outlier here. Cleaned up. > > > > > > > > > capabilities. This means that if one wishes to enumerate all of the > > > capabilities for a device which implements ECDH, it requires multiple > > > pairs of capability structures (algorithm, key) to deal with the > > > different key types and curves that are supported. For a key, > > > the > > > > > > An example of this would be pretty helpful. > > > > > > Section 8.1 > > > > > > * OKP, EC2: The list of capabilities is: > > > > > > - The key type value. (1 for OKP or 2 for EC2.) > > > > > > - One curve for that key type from the "COSE Elliptic Curve" > > > registry. > > > > > > Am I reading this right that the idea is to use capabilities to lock > > > a key down to a single curve? > > > > > > * Symmetric: The list of capabilities is: > > > > > > - The key type value (4). > > > > > > but we're not using this opportunity to indicate whether a symmetric > > > key is for encryption vs. HMAC? > > > > > > Section 8.2 > > > > > > (from the "COSE Key Types" Registry). It is expected future > > > registered algorithms could have zero, one, or multiple elements. > > > > > > nit: missing "that". > > [JLS] Section 8 has been re-written - you are going to need to review again. > > Okay, I'll wait for the new revision. > > > > > > > Section 10 > > > > > > Is [this document] going to be added as a reference on these registries? > > > Should it replace or augment 8152 in that role? > > [JLS] We will see what happens w/ the question I sent to Barry about Jean- > Marc's DISCUSS on -struct. It applies to this document as well. > > Was I supposed to see a question you asked Barry in response to Jean-Marc's > response to my Discuss ballot? (I don't.) [JLS] No it was a private note, and it is going to be done. > > Thanks for the updates; I'll look for the revised I-D. > > -Ben From nobody Thu Jun 25 11:12:44 2020 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 9CDA83A0E6C; Thu, 25 Jun 2020 11:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 D10Y36MJvrAy; Thu, 25 Jun 2020 11:12:37 -0700 (PDT) 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 E44243A0E6A; Thu, 25 Jun 2020 11:12:36 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 25 Jun 2020 11:12:30 -0700 From: Jim Schaad To: "'Rob Wilton (rwilton)'" , 'The IESG' CC: , , , 'Matthew Miller' References: <159172658835.26172.4590101163395195141@ietfa.amsl.com> <00c301d63eb3$9039bf20$b0ad3d60$@augustcellars.com> <01b201d64599$951e92d0$bf5bb870$@augustcellars.com> In-Reply-To: Date: Thu, 25 Jun 2020 11:12:28 -0700 Message-ID: <01ef01d64b1c$31d3f430$957bdc90$@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: AQGt8PvhRubwAU5WHR14eMnKEkUjfwJpSho5AWZicCUBJud4TAIJGYjtqQFWJiA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Robert Wilton's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 18:12:40 -0000 > -----Original Message----- > From: Rob Wilton (rwilton) > Sent: Friday, June 19, 2020 8:08 AM > To: Jim Schaad ; 'The IESG' > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; > cose@ietf.org; 'Matthew Miller' > Subject: RE: Robert Wilton's No Objection on = draft-ietf-cose-rfc8152bis-algs-09: > (with COMMENT) >=20 > Hi Jim, >=20 > Sorry, but I'm still struggling to fully understand the capability = text. That may > be because it is too far out of my domain of expertise, or it may be = because the > text is unclear. It is also worth noting that I've not read the = entire document, > just the diffs. Also note that these are just comments intended to = help the > readability of the document, they don't block the progression of the = document, > so the authors are at liberty to ignore them if they choose. While this is frustrating to me at the moment. I think we are still = making the document better so I am still willing to try and do some = slogging through things. >=20 > From the latest text on github, the things that I don't fully = understand, or > potentially find the text somewhat confusing are: >=20 >=20 > "This means that if one wishes to enumerate all of the capabilities = for a device > which implements ECDH, it requires multiple pairs of capability = structures > (algorithm, key) to deal with the different key types and curves that = are > supported." >=20 > 1. Is the use of a pair of capabilities (algorithm capabilities, key = capabilities) > normative, or just an example usage? I.e. is this one way that this = could be > achieved, or the only way that this would be achieved. This is just and example usage. I am going to reword to talk about = combinations rather than pairs. And point to the cross product = structure for the ECDH element in the last example. >=20 >=20 > "Just an algorithm capability: This is useful if you want to require a = specific > algorithm such as ECDSA, but you are agnostic about which curve is = being used. > See the first example." >=20 > 2. Is the capability actually saying that a specific algorithm is = being used, or is it > that a particular key type is being used for the algorithm? [Given = that the > algorithm capabilities don't encode the choice of algorithm.] ]JLS] It is saying the second statement given that the specific = algorithm is not part of the capability. And yes I am beginning to = really regret that decision. >=20 >=20 > "Just a key type capability: This is useful if you want to require a = specific curve > such as P-256, but will accept any algorithm using that curve (e.g. = both ECDSA > and ECDH). See the second example." >=20 > 3. Presumably this example is also constraining the key type to EC2 as = well as > the curve to P-256? [JLS] Good point - added the text. >=20 >=20 > "Both an algorithm and a key type capability: This is used if one = needs to nail > down all of the options surrounding an algorithm E.g. EdDSA with the = curve > X25519. See the third example which just concatenates the two = capabilities > together." >=20 > 4. Am I right to ensure that a separate specification, where the = capabilities > structures are being used, would specify that the capabilities are = defined as an > array of algorithm capabilities followed by key value capabilities. = [Related to > comment 1 above.] [JLS] That would be one way that it could be used. If you look at how = it is used in draft-ietf-core-oscore-groupcomm, there is an array of = multiple items of which one set each of algorithm and key type = capabilities are but two of them. These are then used as part of a key = derivation process to make sure that everybody is agreeing on what is = being used. However the view you gave does look like what I did in = example 3. >=20 >=20 > Nits: >=20 > I would suggest that it would be better to switch the order of "8.2 = Assignments > for Existing Algorithms" and "8.1 Assignments for Existing Key Types", = since > elsewhere in this section the text always talks about algorithms = before key > types. >=20 > In the examples, you may want to remind that the algorithm type is not > included in the capability data because it should already be known = from > elsewhere. >=20 > Finally, in the examples, you might wish to rephase to avoid second = person > language, such as using "you". [JLS] All of these things are good and done. Thanks for working with me. Jim >=20 > Regards, > Rob >=20 >=20 > > -----Original Message----- > > From: Jim Schaad > > Sent: 18 June 2020 18:55 > > To: Rob Wilton (rwilton) ; 'The IESG' > > > > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; > > cose@ietf.org; 'Matthew Miller' > > Subject: RE: Robert Wilton's No Objection on > > draft-ietf-cose-rfc8152bis- > > algs-09: (with COMMENT) > > > > Rob, > > > > I have spent way too long trying to do edits and re-writes and > > additions and deletions on this. I don't think that I can even read = it anymore. > > However, https://cose-wg.github.io/cose-rfc8152bis/draft-ietf-cose- > > rfc8152bis-algs.html#name-cose-capabilities has an updated version = of > > this that I think will address all of your comments. Please review. > > > > Thanks, Jim > > > > > > > > -----Original Message----- > > From: Rob Wilton (rwilton) > > Sent: Wednesday, June 10, 2020 4:03 AM > > To: Jim Schaad ; 'The IESG' > > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; > > cose@ietf.org; 'Matthew Miller' > > Subject: RE: Robert Wilton's No Objection on > > draft-ietf-cose-rfc8152bis- > > algs-09: (with COMMENT) > > > > Hi Jim, > > > > Please see inline ... > > > > > -----Original Message----- > > > From: Jim Schaad > > > Sent: 10 June 2020 00:13 > > > To: Rob Wilton (rwilton) ; 'The IESG' > > > > > > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; = cose-chairs@ietf.org; > > > cose@ietf.org; 'Matthew Miller' > > > Subject: RE: Robert Wilton's No Objection on > > > draft-ietf-cose-rfc8152bis- > > > algs-09: (with COMMENT) > > > > > > > > > > > > -----Original Message----- > > > From: Robert Wilton via Datatracker > > > Sent: Tuesday, June 9, 2020 11:16 AM > > > To: The IESG > > > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; = cose-chairs@ietf.org; > > > cose@ietf.org; Matthew Miller ; > > > linuxwolf+ietf@outer-planes.net > > > Subject: Robert Wilton's No Objection on > > > draft-ietf-cose-rfc8152bis-algs- > > > 09: (with COMMENT) > > > > > > Robert Wilton has entered the following ballot position for > > > draft-ietf-cose-rfc8152bis-algs-09: No Objection > > > > > > When responding, please keep the subject line intact and reply to > > > all email addresses included in the To and CC lines. (Feel free to > > > cut this introductory paragraph, however.) > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found = here: > > > https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ > > > > > > > > > > > > = -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > = -------------------------------------------------------------------- > > > -- > > > > > > Hi, > > > > > > I've only reviewed the diff against RFC8152. The vast majority = of this > > > document seemed to have only minimal changes and looked fine from > > > what I could see. > > > > > > A few minor comments that may help improve the document: > > > > > > > > > 8. COSE Capabilities > > > > > > Two different types of capabilities are defined: capabilities = for > > > algorithms and capabilities for key structures. Once defined = by > > > registration with IANA, the list of capabilities is immutable. = If it > > > is later found that a new capability is needed for a key type = or an > > > algorithm, it will require that a new code point be assigned to = deal > > > with that. As a general rule, the capabilities are going to = map to > > > algorithm-specific header parameters or key parameters, but = they do > > > not need to do so. An example of this is the HSS-LMS key > > > capabilities defined below where the hash algorithm used is = included. > > > > > > Defining the capabilities list as immutable seemed like a misnomer > > > to me because a new IANA registration would mutate the list. > > > Perhaps this sentence, and the one following it, could be removed? > > > [JLS] The whole object is that once registered with IANA, it will > > > never be changed even by IANA. Thus I believe that the word > > > immutable seems to be correct. If this is changed then existing > > > signatures will fail and key derivation functions will generate = different > results. > > [RW] > > > > I'm still slightly confused, and alas the more I read the text the > > more confused I become ;-) > > > > Hence a clarifying question: Does "the list of capabilities is > > immutable", does it mean that the list of capabilities associated = with > > a given algorithm or key structure is immutable? Or does it mean = that > > the entire list of defined capabilities as a set is immutable? > > [JLS] The intention is to say that it is fixed for a single = algorithm > > or key type and not the entire list. > > > > And in the following paragraph, where is states "The capability > > structure is an array of values" does it mean the capability = structure > > associated with a particular algorithm or key? > > [JLS] Yes > > > > Another question relates to "The capability structure is an array of > > values,", does this mean "The capability structure for a given > > algorithm or key is an ordered array of values, the order ... " > > [JLS] Yes > > > > The paragraph below also mentions multiple pairs of capability = structures. > > Do the capabilities always come as a pair of an algorithm and a key? > > If there are multiple pairs then how are they encoded, presumably as > > an array of pairs? If capabilities do not always come as a pair = then > > you do you differentiate between a capability defining an algorithm > > and one defining a key? > > > > > > > > The capability structure is an array of values, the order being > > > dependent on the specific algorithm or key. For an algorithm, = the > > > first element should always be a key type value, but the items = that > > > are specific to a key should not be included in the algorithm > > > capabilities. This means that if one wishes to enumerate all = of the > > > capabilities for a device which implements ECDH, it requires = multiple > > > pairs of capability structures (algorithm, key) to deal with = the > > > different key types and curves that are supported. For a key, = the > > > first element should also be a key type value. While this = means that > > > this value will be duplicated if both an algorithm and key = capability > > > are used, the key type is needed in order to understand the = rest of > > > the values. > > > > > > Should you be using RFC 2119 language here? And should " key = should > > > not be included" be "MUST NOT"? > > > [JLS] Responded to this point in Roman's comments. > > > > > > For the ECDH case, does that mean that the "algorithm" entry will = be > > > duplicated with different "key" entries? If so, would it help > > > clarify to explicitly state this? > > > [JLS] Would pointing to the second and third examples in section = 8.3 > > > along with some explanatory text? > > [RW] > > > > Perhaps, but I think that it would also be useful to have an example > > of supporting ECDH-ES with both P-256 and X25519 curves, and how = that > > would be encoded (if that makes sense). > > > > I also couldn't convince myself that the numerical values that are > > used in the examples are necessary right, please can you check that = they are. > > E.g., the first two example have the same numeric encoding, and the > > two ECDH-ES have different encodings of the algorithm. But perhaps > > that is just my confusion about how this works. > > > > Regards, > > Rob > > > > > > > > > > Jim > > > > > > Thanks, > > > Rob > > > > > > > > From nobody Fri Jun 26 14:34:17 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B23C23A0CA5; Fri, 26 Jun 2020 14:33:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <159320723847.8997.4224788730329038318@ietfa.amsl.com> Date: Fri, 26 Jun 2020 14:33:58 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-rfc8152bis-algs-10.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 21:33:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption WG of the IETF. Title : CBOR Object Signing and Encryption (COSE): Initial Algorithms Author : Jim Schaad Filename : draft-ietf-cose-rfc8152bis-algs-10.txt Pages : 55 Date : 2020-06-26 Abstract: Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. THis document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol RFC XXXX. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-10 https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-rfc8152bis-algs-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 26 14:39:43 2020 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 7BEA23A0CAF for ; Fri, 26 Jun 2020 14:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 PR20a66l9hfB for ; Fri, 26 Jun 2020 14:39:38 -0700 (PDT) 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 6331C3A0CA9 for ; Fri, 26 Jun 2020 14:39:38 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Jun 2020 14:39:29 -0700 From: Jim Schaad To: CC: 'Barry Leiba' , 'Benjamin Kaduk' References: <159320723949.8997.13938432921374377997@ietfa.amsl.com> In-Reply-To: <159320723949.8997.13938432921374377997@ietfa.amsl.com> Date: Fri, 26 Jun 2020 14:39:27 -0700 Message-ID: <028401d64c02$465aa700$d30ff500$@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: AQFh+mLRL4Ffj+aGKOAye0qJiqFNgKnUDl3A X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] FW: New Version Notification for draft-ietf-cose-rfc8152bis-algs-10.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 21:39:41 -0000 I have just uploaded a new version of the -algs document that I believe = addresses all of the comments that were raised during the IESG review = process. There are two things of note that people should be aware of because = these changes are fairly significant. 1. The section on capabilities has been practically re-written from = scratch. There are no changes in how things are done but the = description is quite different. 2. Based on the comments of Martin Thomson, et al. in for the QUIC = draft the security considerations for all three block encryption = algorithms have been updated as well as an additional paragraph added to = the end of the security considerations. (Oh I just remembered one minor change that I agreed to do so a -11 will = be coming.) Jim -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Friday, June 26, 2020 2:34 PM To: Jim Schaad Subject: New Version Notification for = draft-ietf-cose-rfc8152bis-algs-10.txt A new version of I-D, draft-ietf-cose-rfc8152bis-algs-10.txt has been successfully submitted by Jim Schaad and posted to the IETF = repository. Name: draft-ietf-cose-rfc8152bis-algs Revision: 10 Title: CBOR Object Signing and Encryption (COSE): Initial Algorithms Document date: 2020-06-26 Group: cose Pages: 55 URL: = https://www.ietf.org/internet-drafts/draft-ietf-cose-rfc8152bis-algs-10.t= xt Status: = https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ Htmlized: = https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-10 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-rfc8152bis-algs-10 Abstract: Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. THis document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol RFC XXXX. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Sat Jun 27 00:36:45 2020 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 9FB9D3A0112; Sat, 27 Jun 2020 00:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOi9UTV0ETF8; Sat, 27 Jun 2020 00:36:30 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D98E3A02BE; Sat, 27 Jun 2020 00:36:30 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49v5Cw3B9zzyWX; Sat, 27 Jun 2020 09:36:28 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 614936187.9916019-bef90aaa2d26cc00a43c1ed5be064893 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sat, 27 Jun 2020 09:36:28 +0200 Message-Id: To: Ace Wg , core@ietf.org, cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [COSE] Constrained Node/Network Cluster @ IETF108: DRAFT AGENDA X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 07:36:35 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF108. Remember that there is still quite some potential for changes. Conflicts that meet the eye: LAKE/SUIT (!). ACE/RATS. (I think 6LO/COSE can be ignored.) HACKATHON is on top of CORE, but I don't know what that slot on Friday is supposed to be. All times appear to be in UTC, even though nothing says so; https://datatracker.ietf.org/meeting/agenda-utc gives the same times. Gr=C3=BC=C3=9Fe, Carsten MONDAY, July 27, 2020 1100-1240 Session I Rm 1 ART dispatch Dispatch WG Rm 5 IRTF pearg Privacy Enhancements and Assessments = Research Group Rm 2 SEC *** teep Trusted Execution Environment = Provisioning WG 1300-1350 Session II Rm 4 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Rm 6 INT intarea Internet Area Working Group WG Rm 2 RTG babel Babel routing protocol WG Rm 5 RTG detnet Deterministic Networking WG 1410-1550 Session III Rm 5 ART webtrans WebTransport WG Rm 4 IRTF qirg Quantum Internet Research Group Rm 2 SEC gnap Grant Negotiation and Authorization = Protocol WG TUESDAY, July 28, 2020 1100-1240 Session I Rm 1 ART *** asdf A Semantic Definition Format for Data = and Interactions of Things BOF Rm 2 INT 6man IPv6 Maintenance WG Rm 3 IRTF irtfopen IRTF Open Meeting Rm 8 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG 1300-1350 Session II Rm 4 SEC mls Messaging Layer Security WG Rm 3 SEC *** rats Remote ATtestation ProcedureS WG 1410-1550 Session III Rm 4 SEC *** lake Lightweight Authenticated Key Exchange = WG Rm 3 SEC *** suit Software Updates for Internet of Things = WG Rm 2 TSV loops Local Optimizations on Path Segments BOF WEDNESDAY, July 29, 2020 1100-1240 Session I Rm 5 RTG bier Bit Indexed Explicit Replication WG Rm 4 SEC *** ace Authentication and Authorization for = Constrained Environments WG Rm 3 SEC *** rats Remote ATtestation ProcedureS WG Rm 2 TSV quic QUIC WG 1300-1350 Session II Rm 6 ART webtrans WebTransport WG Rm 2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Rm 4 RTG rift Routing In Fat Trees WG Rm 5 SEC *** cose CBOR Object Signing and Encryption WG Rm 1 TSV tsvarea Transport Area Open Meeting THURSDAY, July 30, 2020 1100-1240 Session I Rm 6 OPS anima Autonomic Networking Integrated Model = and Approach WG Rm 4 RTG raw Reliable and Available Wireless WG Rm 5 SEC secdispatch Security Dispatch WG Rm 2 TSV tsvwg Transport Area Working Group WG 1300-1350 Session II Rm 3 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Rm 2 SEC saag Security Area Open Meeting 1410-1550 Session III Rm 6 INT add Adaptive DNS Discovery WG Rm 7 INT *** drip Drone Remote ID Protocol WG Rm 4 SEC acme Automated Certificate Management = Environment WG FRIDAY, July 31, 2020 1100-1240 Session I Rm 8 ART *** core Constrained RESTful Environments WG Rm 6 GEN hackathon Hackathon Rm 2 SEC tls Transport Layer Security WG Rm 1 TSV tsvwg Transport Area Working Group WG 1300-1350 Session II Rm 3 ART wpack Web Packaging WG Rm 4 INT 6man IPv6 Maintenance WG Rm 6 SEC emu EAP Method Update WG 1410-1550 Session III Rm 1 ART *** core Constrained RESTful Environments WG Rm 7 IRTF coinrg Computing in the Network Research Group Rm 3 SEC privacypass Privacy Pass WG From nobody Sat Jun 27 11:33:59 2020 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 EEFBE3A08A6 for ; Sat, 27 Jun 2020 11:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 FrFHAFrkYFJn for ; Sat, 27 Jun 2020 11:33:56 -0700 (PDT) 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 445823A0891 for ; Sat, 27 Jun 2020 11:33:56 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 27 Jun 2020 11:33:51 -0700 From: Jim Schaad To: Date: Sat, 27 Jun 2020 11:33:49 -0700 Message-ID: <02c601d64cb1$81afc1f0$850f45d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AdZMrzyBq1NhXmPnRT67+TMpyFjFPA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] SHAKE hashing discuss X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 18:33:58 -0000 During the IESG review of the hash algorithms draft, Ben pointed out that I had a big hole in my understanding of how SHAKE worked. Even worse, I should have known this but it went against how I had thought SHAKE was designed so when I read that I was wrong I just did not review it. SHAKE128 does not have the property that prefixes are going to be unique depending on the length requested. In order to fix this there are four different paths that I see: 1. Just make the lengths of the outputs fixed. Thus SHAKE-128 => 128-bits and SHAKE-256 => 256-bits. 2. Switch from using SHAKE to using KMAC with a zero-length key. KMAC does have the property that it is does not generate prefixes. The output is changed by specifying the length of the output. 3. Make the lengths fixed, but define some additional algorithms with different lengths. This is the approach used with SHA-2. 4. Do a combination of either 1 and 2 or 1 and 3. In this case the second half would be deferred to the more-algs draft. If I have not seen any sort of consensus on the list by July 3, I will just do option one and punt on anything else. Jim From nobody Sat Jun 27 12:44:08 2020 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 A15E13A08FF for ; Sat, 27 Jun 2020 12:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuB80V3cvTan for ; Sat, 27 Jun 2020 12:44:06 -0700 (PDT) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 E571C3A0900 for ; Sat, 27 Jun 2020 12:44:05 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id m16so6246595ybf.4 for ; Sat, 27 Jun 2020 12:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kpssCL1O4ULzHNE3gzofa8Z1gU0mdl0RtIY2Rhb+B8g=; b=iBi0ccOuogWO33GBDYVx1DnwyD1eUd5T6YPrRGuH+PI2lnCQxKSDdkSD5rGKLLeFFn dQycvCgosUucM9zdyZ/kP1flF5vdDO9KJWPzWDEfNa8VIf2kqsJmPB5k3z4wDipQ4OSC /oPMOOozCuNqFuw3sKBQIQs0mM2htsEHSipBISCiZ2etRM62NmdDlQHUbUvss9bX6IiQ q1XNSsVS01R1zduMXwvrT0PMubj6p9TBy0ZwJBazYnQCqV6t+2VGHaLIzoabNP3W6HAN uLdPov3QxvBU3QBPXNd/9+UNA9ZN1Wx8DQlIOsoI70pi0tK27BhWB+7q1ULq+7jU7m8k gAhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kpssCL1O4ULzHNE3gzofa8Z1gU0mdl0RtIY2Rhb+B8g=; b=Q0HlZ81gREO273Nf9B/nvOfH8+ylyUIZtM7JGIvVyiC5MpaOChiYUbWH5Rr/JtYdGI JckOynWHzLTinpr1DJxmle7h9ALcwjCXLhmmSkA5wnxwwMjtsPKeCIbxJXNWHKbmOxu4 j27cVF3kuz6TebGxvHHfyRp7LfoNbU0YU4Ss9gpFqd7DVUrtxFQWa1dbA3rIowLI/zWA 4Q0G+pBDhYJ4ojFV9wVYgZM3VKfXBeE3gM59iiJ+HV9GTcOA6T4yaeCGWLk6dHb/N8h6 R1CfyyIEF1PKgVcGovd7MIPqM8X6Mjy/AmobwyvAOxuoZHuW0BDzoy4QBm54HtAN7Hsn DEew== X-Gm-Message-State: AOAM531WVUGIvvH1/MhFKoUz7y7tpaCGahhqKz+ahy0oSF1HCyMu+Vwg JOn0BSz8gqlouKJuL8Sgv2jVaXwGHNTQe9pweerqP+Yl X-Google-Smtp-Source: ABdhPJz54S2Yq31SYgYG00Dl32WRpoNFYicKEo3UPqKHFsiQcQ8X8bf1IAx6Y1XDxw5ifJtHX8r+jJ3UwWXJbzhHXt4= X-Received: by 2002:a05:6902:50c:: with SMTP id x12mr15290260ybs.498.1593287045070; Sat, 27 Jun 2020 12:44:05 -0700 (PDT) MIME-Version: 1.0 References: <02c601d64cb1$81afc1f0$850f45d0$@augustcellars.com> In-Reply-To: <02c601d64cb1$81afc1f0$850f45d0$@augustcellars.com> From: Quynh Dang Date: Sat, 27 Jun 2020 15:43:54 -0400 Message-ID: To: Jim Schaad Cc: cose@ietf.org Content-Type: multipart/alternative; boundary="00000000000058c2b005a9160c67" Archived-At: Subject: Re: [COSE] SHAKE hashing discuss X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 19:44:08 -0000 --00000000000058c2b005a9160c67 Content-Type: text/plain; charset="UTF-8" Hi Jim, You should not hash (process) the same message X twice to produce 2 different outputs (2 different-length outputs). It is the same situation as SHA-512 with output lengths being 512 and 256 (a truncated output of SHA-512). In that situation, you should do SHAKE256 (domain_seperation_i || X, output_length_i) for each different output_i. With SHA3s such as SHA-3/256, if you want a 512-bit output from input X, you will run SHA-3/256 twice such as SHA-3/256 (X) || SHA-3/256 (1|| X). With SHAKE256, you just run SHAKE256 (X, 512). So, the former option destroys the benefit of the sponge construction and it is practically 2 times more expensive than the latter. Regards, Quynh. On Sat, Jun 27, 2020 at 2:34 PM Jim Schaad wrote: > During the IESG review of the hash algorithms draft, Ben pointed out that I > had a big hole in my understanding of how SHAKE worked. Even worse, I > should have known this but it went against how I had thought SHAKE was > designed so when I read that I was wrong I just did not review it. > > SHAKE128 does not have the property that prefixes are going to be unique > depending on the length requested. In order to fix this there are four > different paths that I see: > > 1. Just make the lengths of the outputs fixed. Thus SHAKE-128 => 128-bits > and SHAKE-256 => 256-bits. > > 2. Switch from using SHAKE to using KMAC with a zero-length key. KMAC > does > have the property that it is does not generate prefixes. The output is > changed by specifying the length of the output. > > 3. Make the lengths fixed, but define some additional algorithms with > different lengths. This is the approach used with SHA-2. > > 4. Do a combination of either 1 and 2 or 1 and 3. In this case the second > half would be deferred to the more-algs draft. > > If I have not seen any sort of consensus on the list by July 3, I will just > do option one and punt on anything else. > > Jim > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --00000000000058c2b005a9160c67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jim,

You should not hash (process) t= he same message X twice to produce 2 different outputs (2 different-length = outputs). It is the same situation as SHA-512 with output lengths being 512= and 256 (a truncated output of SHA-512).=C2=A0

In= that situation, you should do SHAKE256 (domain_seperation_i || X, output_l= ength_i) for each different output_i.=C2=A0

With S= HA3s such as SHA-3/256, if you want a 512-bit output from input X, you=C2= =A0will run SHA-3/256 twice such as SHA-3/256 (X) || SHA-3/256 (1|| X).

With SHAKE256, you just run SHAKE256 (X, 512).
<= div>
So, the former option destroys the benefit of the sponge= construction and it is practically 2 times more expensive than the latter.= =C2=A0

Regards,
Quynh.=C2=A0
=
On Sat= , Jun 27, 2020 at 2:34 PM Jim Schaad <ietf@augustcellars.com> wrote:
During the IESG review of the hash algorithms= draft, Ben pointed out that I
had a big hole in my understanding of how SHAKE worked.=C2=A0 Even worse, I=
should have known this but it went against how I had thought SHAKE was
designed so when I read that I was wrong I just did not review it.

SHAKE128 does not have the property that prefixes are going to be unique depending on the length requested.=C2=A0 In order to fix this there are fou= r
different paths that I see:

1.=C2=A0 Just make the lengths of the outputs fixed.=C2=A0 Thus SHAKE-128 = =3D> 128-bits
and SHAKE-256 =3D> 256-bits.

2.=C2=A0 Switch from using SHAKE to using KMAC with a zero-length key.=C2= =A0 KMAC does
have the property that it is does not generate prefixes.=C2=A0 The output i= s
changed by specifying the length of the output.

3.=C2=A0 Make the lengths fixed, but define some additional algorithms with=
different lengths.=C2=A0 This is the approach used with SHA-2.

4.=C2=A0 Do a combination of either 1 and 2 or 1 and 3.=C2=A0 In this case = the second
half would be deferred to the more-algs draft.

If I have not seen any sort of consensus on the list by July 3, I will just=
do option one and punt on anything else.

Jim


_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose
--00000000000058c2b005a9160c67-- From nobody Sat Jun 27 16:21:20 2020 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 A244B3A0840; Sat, 27 Jun 2020 16:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 f69eTfxX-cwx; Sat, 27 Jun 2020 16:21:16 -0700 (PDT) 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 9BE4B3A0839; Sat, 27 Jun 2020 16:21:15 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 27 Jun 2020 16:21:09 -0700 From: Jim Schaad To: 'DESPERRIER Jean-Marc' , 'Benjamin Kaduk' CC: , , 'Matthew Miller' , 'The IESG' , References: <159183984940.7642.3215375794743353401@ietfa.amsl.com> <004c01d64297$360aa310$a21fe930$@augustcellars.com> <20200615230443.GO11992@kduck.mit.edu> <00af01d6437f$9f30ee60$dd92cb20$@augustcellars.com> <20200617030230.GB11992@kduck.mit.edu> <011201d64459$41f2af10$c5d80d30$@augustcellars.com> In-Reply-To: Date: Sat, 27 Jun 2020 16:21:08 -0700 Message-ID: <02d101d64cd9$a5743940$f05cabc0$@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: AQLLhK51vaVhQCr2j2FaHM+f5QWv3gIn/U8/AYBLdn4B16I9JQI/MdrVAU8knnoCIOUgJaanssEA X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-struct-10: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 23:21:19 -0000 Jean-Marc, I think that you have a deep misunderstanding about this and we need to = find what the text is that is both confusing and how to get = clarifications. > -----Original Message----- > From: DESPERRIER Jean-Marc > Sent: Thursday, June 18, 2020 10:22 AM > To: Jim Schaad ; 'Benjamin Kaduk' = > Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org; cose-chairs@ietf.org; = 'Matthew > Miller' ; 'The IESG' ; > cose@ietf.org > Subject: RE: [COSE] Benjamin Kaduk's Discuss on = draft-ietf-cose-rfc8152bis- > struct-10: (with DISCUSS and COMMENT) >=20 > Hi, >=20 > Sorry this is a comment coming very late, but I'm afraid I have = identified a very > serious issue with counter signatures that I wish to rise here as it = seems to me > to be important. > I would be really happy to be totally wrong about it, but that would = require a > very deep misunderstanding about them that would in any case require = some > clarifications in the text. >=20 > I have seen this actually some weeks ago, but until now some of the = text about > countersignatures got me so confused I wasn't sure I didn't wrongly = interpret > major parts of it. >=20 > So here's my reading step by step of the specifications about = countersignature, > and why I have an issue with it of a contradiction between what it = says is > intended to and what is really achieved, and also for me deep = unclarity about > what the payload of a countersignature consists of : >=20 > --------- > 3.1. Common COSE Header Parameters > The counter signature header > parameter can occur as an unprotected attribute in any of the > following structures: COSE_Sign1, COSE_Signature, COSE_Encrypt, > COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0. These > structures all have the same beginning elements, so that a > consistent calculation of the counter signature can be computed. > Details on counter signatures are found in Section 5 >=20 > Nonetheless, they are differences between those formats that at least = impact > the payload, and the text doesn't clarify explicitly how they impact = counter- > signatures So the first three elements are: * Protected headers * Unprotected headers * Payload of the object In section 5 there is text which says "that the countersignature = operation needs to be treated as a separate operation from the initial = operation". The purpose of this text was to state that all of the = cryptographic operations on the target of the countersignature need to = be completed prior to starting the countersignature operation. This = means that looking at that array of items above there is a binary = string, a map, and a binary string. The countersignature operation is = totally agnostic to how that last byte string is created. It has to be = or else a third party would not be able to apply a countersignature. >=20 > --------- > 5. Counter Signatures >=20 > A counter signature is normally defined as a second signature that > confirms a primary signature. A normal example of a counter > signature is the signature that a notary public places on a = document > as witnessing that you have signed the document. Thus applying a > counter signature to either the COSE_Signature or COSE_Sign1 = objects > match this traditional definition. >=20 > This will only be true if the payload of the counter signature = incorporates the > byte string representing the primary signature value. > If this not the case for COSE counter signature, this text MUST be = removed and > clarification otherwise MUST be brought to the standard. > The use of the term counter signature will then be misleading, and = should be > considered to be removed. [JLS] As noted above that is exactly what the payload is >=20 > When done on a COSE_Signature, the normal counter signature = semantics > are preserved. That is the counter signature makes a statement = about > the existence of a signature and, when used as a timestamp, a time > point at which the signature exists >=20 > This will only be true if the payload of the counter signature = incorporates the > byte string representing the primary signature value. > If this not the case for COSE counter signature, this text MUST be = removed and > clarification otherwise MUST be brought to the standard. > The use of the term counter signature will then be misleading, and = should be > considered to be removed. [JLS] As noted above, this is true for applying to a COSE_Signature. >=20 > When done on a COSE_Mac or a > COSE_Mac0, one effectively upgrades the MAC operation to a = signature > operation. >=20 > This will be true even when the payload of the counter signature only > incorporates the mac 'payload', and not its 'tag'. [JLS] As noted above, only the first three elements of the COSE_Mac and = COSE_Mac0 structures are used when computing the countersignature. This = means that the tag, which is the fourth element is not included. >=20 > When done on a COSE_Encrypt or COSE_Encrypt0, the > existence of the encrypted data is attested to. >=20 > This will be true even when only 'ciphertext' is included in the = countersignature > payload. [JLS] As noted above, the ciphertext is what is used. >=20 > --------- > 5.1. Full Counter Signatures > The process of creating and validating abbreviated > counter signatures is defined in Section 4.4. >=20 > 1) abbreviated here seems be a typo [JLS] My dictionary tells me that this is correctly spelt. >=20 > 2) The process in Section 4.4 doesn't specify explicitly how to = populate the > payload element of the Sig_structure in the case of a counter = signature > Clarification about that is absolutely required either here in section = 5.1 or in > section 4.4 [JLS] I will add clarification in the text that the COSE_Signature = structure is what is referred to when it says that the details of the = fields of a countersignature are found in section 4.1. >=20 > --------- > 4.4. Signing and Verification Process > 5. The payload to be signed encoded in a bstr type. The payload = is > placed here independent of how it is transported. >=20 > 1) For counter signature of a signature, the simplest interpretation = of this text > is that the payload is the 'payload' element of the initial signature. > They are however major issues if interpreted like that. > If I have read its source correctly, the COSE-JAVA implementation does = do > counter-signatures of signatures this way. >=20 > If this is what's intended, then COSE counter signatures aren't = counter > signatures in the classical meaning, they are in fact basically fully = equivalent to > cosignatures, given that what they include is only the primary = payload, and > doesn't include the primary signature. > So all text suggesting otherwise should be removed from the standard. > New text should be added to make it extremely clear that those = signatures > can't function as actual counter-signatures. > I would actually be in favor of removing use of the term = counter-signature > given how misleading it would be then. >=20 > If the intent is for counter signature in this standard to be real = counter > signatures, then an explicit clarification is required about how = 'payload' is > populated. > The simplest solution is probably to say that it includes all of the = primary > signature structure, except that all of the 'unprotected' headers = shall be > removed first (there would be recursion problems otherwise) This = specifically > solves the issue of specifying which of the initial signature is = countersigned in > case they are multiple signers. > Solution to include less of the initial structure in the counter = signature seem to > be more complex, and would need anyway to include all of the initial = signers, > except if designing a way to specify only one of them (maybe when the = counter > signature is inserted inside the 'unprotected' element of his specific = signature > ?). [JLS] Yes I can see how this is confusing. I will add a paragraph on = how to determine what the payload is for a countersignature operation. >=20 > 2) For counter signature of a mac, the simplest interpretation of this = text is that > the payload is the 'payload' element of the initial signature and = 'tag' isn't > included in the countersignature. > There's not a major issue if interpreted like that, as I didn't see a = claim that this > would contradict. >=20 > 3) For encrypted content, the simplest interpretation of this text is = that the > payload is the 'ciphertext' element . > There's not a major issue if interpreted like that, nonetheless it = would be made > clearer by specifying it explicitly >=20 > --------- > 5.2. Abbreviated Counter Signatures > Instead, the parameters for computing or verifying the > abbreviated counter signature are inferred from the same context = used > to describe the encryption, signature, or MAC processing >=20 > 1) This appears to mean that if a signature with a single signer is = counter- > signed this way, the content + the protected headers + the signer are = the same > as the initial signature ? > If so, it doesn't seem to have much value, since it resigns = exactly the same > thing (except the signer protected header if applicable), so it should = be made > even more explicit If they are multiple signers of the initial = signature, is it > intended that the signer must be the first of the list ? > For mac and encryption, it's unclear how the signer public key will be > identified, as we have only the information for the mac/encryption = key. >=20 > If what is actually intended that the identification of the = counter-signer is > through an out-of-band mechanism and doesn't need to have a relation = with > the counter signed element signature, encryption or mac, this should = be > specified. [JLS] I will start by saying that I have never liked the abbreviated = countersignature, but it is useful in some circumstances. The easiest = document to look at where both an encryption key and signature key are = associated draft-ietf-core-oscore-groupcomm. In this case while each = person in the group has a unique key, that key is also known by = everybody else in the group so that key cannot be used for the purpose = of determining who encrypted and sent the message. This information is = added by the addition of an abbreviated countersignature to the end of = the encrypted message. This, combined with a large amount of externally = supplied authenticated data to both the encryption and signature = process, allows for proper identification of the entity which sent the = message. There is only one set of key identification material however = and that is to identify the encryption key which was used. The same = identifiers used for the encryption key can then be used to figure out = which signature key(s) would make sense to check. [JLS] In the case that you suggested above, that of an abbreviated = countersignature on a signature, when you went to retrieve the key = information on the signing key, I would expect that you would get back = an array of two signing keys. The first for the signature and the = second for the countersignature. I would really wonder at a case where = this is being done however. Why are you sufficiently worried about size = that you are using an abbreviated countersignature in this situation, = but you are not just going to replace the original signature with one of = your own. >=20 > 2) To function as an actual counter-signature for signatures, the same = issue > with the payload is present as for full counter signatures >=20 > 3) There is no sample of an abbreviated counter signature [JLS] I have these and can put one or two into the appendixes. Jim > --------------- From nobody Sun Jun 28 11:48:33 2020 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 6E8AC3A0E96 for ; Sun, 28 Jun 2020 11:48:32 -0700 (PDT) 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=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Sok--c9PIsm2 for ; Sun, 28 Jun 2020 11:48:31 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BF93A0E95 for ; Sun, 28 Jun 2020 11:48:30 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05SImNQq028152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Jun 2020 14:48:25 -0400 Date: Sun, 28 Jun 2020 11:48:22 -0700 From: Benjamin Kaduk To: Jim Schaad Cc: cose@ietf.org Message-ID: <20200628184822.GQ58278@kduck.mit.edu> References: <02c601d64cb1$81afc1f0$850f45d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02c601d64cb1$81afc1f0$850f45d0$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] SHAKE hashing discuss X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 18:48:32 -0000 On Sat, Jun 27, 2020 at 11:33:49AM -0700, Jim Schaad wrote: > During the IESG review of the hash algorithms draft, Ben pointed out that I > had a big hole in my understanding of how SHAKE worked. Even worse, I > should have known this but it went against how I had thought SHAKE was > designed so when I read that I was wrong I just did not review it. > > SHAKE128 does not have the property that prefixes are going to be unique > depending on the length requested. In order to fix this there are four > different paths that I see: > > 1. Just make the lengths of the outputs fixed. Thus SHAKE-128 => 128-bits > and SHAKE-256 => 256-bits. > > 2. Switch from using SHAKE to using KMAC with a zero-length key. KMAC does > have the property that it is does not generate prefixes. The output is > changed by specifying the length of the output. > > 3. Make the lengths fixed, but define some additional algorithms with > different lengths. This is the approach used with SHA-2. > > 4. Do a combination of either 1 and 2 or 1 and 3. In this case the second > half would be deferred to the more-algs draft. > > If I have not seen any sort of consensus on the list by July 3, I will just > do option one and punt on anything else. FWIW, my expectation was (IIUC) similar to what Quynh described, just prepending an encoding of the requested output length to the digest input, to provide domain separation. -Ben From nobody Sun Jun 28 20:58:49 2020 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 4CB803A07C0 for ; Sun, 28 Jun 2020 20:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 f-mpBqSwiUHQ for ; Sun, 28 Jun 2020 20:58:46 -0700 (PDT) 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 561FF3A07BB for ; Sun, 28 Jun 2020 20:58:46 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 28 Jun 2020 20:58:20 -0700 From: Jim Schaad To: 'Benjamin Kaduk' CC: References: <02c601d64cb1$81afc1f0$850f45d0$@augustcellars.com> <20200628184822.GQ58278@kduck.mit.edu> In-Reply-To: <20200628184822.GQ58278@kduck.mit.edu> Date: Sun, 28 Jun 2020 20:58:18 -0700 Message-ID: <032201d64dc9$87d707f0$978517d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQHVngIZMiowq/V6yso6p0TRujRkBwKOiWqRqNvibtA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] SHAKE hashing discuss X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 03:58:48 -0000 > -----Original Message----- > From: Benjamin Kaduk > Sent: Sunday, June 28, 2020 11:48 AM > To: Jim Schaad > Cc: cose@ietf.org > Subject: Re: [COSE] SHAKE hashing discuss > > On Sat, Jun 27, 2020 at 11:33:49AM -0700, Jim Schaad wrote: > > During the IESG review of the hash algorithms draft, Ben pointed out > > that I had a big hole in my understanding of how SHAKE worked. Even > > worse, I should have known this but it went against how I had thought > > SHAKE was designed so when I read that I was wrong I just did not review it. > > > > SHAKE128 does not have the property that prefixes are going to be > > unique depending on the length requested. In order to fix this there > > are four different paths that I see: > > > > 1. Just make the lengths of the outputs fixed. Thus SHAKE-128 => > > 128-bits and SHAKE-256 => 256-bits. > > > > 2. Switch from using SHAKE to using KMAC with a zero-length key. > > KMAC does have the property that it is does not generate prefixes. > > The output is changed by specifying the length of the output. > > > > 3. Make the lengths fixed, but define some additional algorithms with > > different lengths. This is the approach used with SHA-2. > > > > 4. Do a combination of either 1 and 2 or 1 and 3. In this case the > > second half would be deferred to the more-algs draft. > > > > If I have not seen any sort of consensus on the list by July 3, I will > > just do option one and punt on anything else. > > FWIW, my expectation was (IIUC) similar to what Quynh described, just > prepending an encoding of the requested output length to the digest input, to > provide domain separation. I don't know that I would really want to add a step to just this one hash function. Using KMAC appends the requested output length and has the domain separator. The only issue would be that it is not the same function call. Jim > > -Ben From nobody Mon Jun 29 21:54:43 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 685993A0813; Mon, 29 Jun 2020 21:54:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller , linuxwolf+ietf@outer-planes.net X-Test-IDTracker: no X-IETF-IDTracker: 7.6.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159349286740.8898.3808862759962563320@ietfa.amsl.com> Date: Mon, 29 Jun 2020 21:54:27 -0700 Archived-At: Subject: [COSE] Benjamin Kaduk's No Objection on draft-ietf-cose-rfc8152bis-algs-10: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 04:54:28 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-cose-rfc8152bis-algs-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss point. I guess I was expecting a little more text as well as the [HKDF] reference in Section 5.1, though I confess I am not entirely sure what I was expecting such text to actually say... From nobody Mon Jun 29 21:58:22 2020 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 034AA3A0813; Mon, 29 Jun 2020 21:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 s1CvMIH9oqrT; Mon, 29 Jun 2020 21:58:13 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7FF3A07F0; Mon, 29 Jun 2020 21:58:12 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05U4w21T000703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jun 2020 00:58:05 -0400 Date: Mon, 29 Jun 2020 21:58:02 -0700 From: Benjamin Kaduk To: Jim Schaad Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org, cose-chairs@ietf.org, "'Matthew Miller'" , "'The IESG'" , cose@ietf.org Message-ID: <20200630045802.GK58278@kduck.mit.edu> References: <159183990940.7725.14952700358572148848@ietfa.amsl.com> <01b101d64599$56ddaf10$04990d30$@augustcellars.com> <20200621022735.GD11992@kduck.mit.edu> <01b101d64a9a$a5d4bd10$f17e3730$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <01b101d64a9a$a5d4bd10$f17e3730$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-algs-09: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 04:58:17 -0000 On Wed, Jun 24, 2020 at 07:45:08PM -0700, Jim Schaad wrote: > > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Saturday, June 20, 2020 7:28 PM > > To: Jim Schaad > > Cc: 'The IESG' ; draft-ietf-cose-rfc8152bis-algs@ietf.org; > cose- > > chairs@ietf.org; 'Matthew Miller' ; > > cose@ietf.org > > Subject: Re: [COSE] Benjamin Kaduk's Discuss on > draft-ietf-cose-rfc8152bis- > > algs-09: (with DISCUSS and COMMENT) > > > > On Thu, Jun 18, 2020 at 10:53:10AM -0700, Jim Schaad wrote: > > > > > > > > > > -----Original Message----- > > > > From: Benjamin Kaduk via Datatracker > > > > Sent: Wednesday, June 10, 2020 6:45 PM > > > > To: The IESG > > > > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; > > > > cose@ietf.org; Matthew Miller ; > > > > linuxwolf+ietf@outer-planes.net > > > > Subject: Benjamin Kaduk's Discuss on > > > > draft-ietf-cose-rfc8152bis-algs-09: (with DISCUSS and COMMENT) > > > > [...] > > > > > > > > I'd really like to see a reference for the analysis of and > > > > validity/safety of the deviations from RFC 5869 HKDF, in Section 5.1. > > > [JLS] I am going to assume you are referring to using AES for the PRF. > I don't > > know if such a thing exists. I can tell you where I got my personal > analysis > > however. When the TLS 1.3 design group was meeting in Seattle, I spent > about > > 20 minutes discussion what the required capabilities of the PRF are needed > to > > get things to work correctly. At least part of the discussion in the > group which > > occurred around the same time was the ability to break the two halves of > HKDF > > separated the way that TLS does. > > > > AES-CBC-MAC as the PRF, but also for sometimes skipping the extract step. > > > > > Found something: https://eprint.iacr.org/2010/264.pdf look in appendix > D > > point 4. > > > > I think this is probably also what Bob Moskowitz came up with when he was > > using the analogous CMAC-based KDF for HIP-DEX. Definitely add it as a > > reference. > > > > I do note that "the analytical results in [the CBC-MAC] case are much more > > restricted than with HMAC" and also that point 5 discusses a modification > of > > K(1) that "may be advisable with other PRF modes (such as CBC-MAC)". > > I suppose that we cannot safely make that modification at this time, at > least > > without assigning new codepoints, as it would break interoperability with > > existing deployments.. > > [JLS] I have not seen that before. It is interesting but since it is not in > the RFC I am not sure that doing so would be a good idea. I think I would > rather just switch to KMAC personally. Fair enough; the existing construction feels just "weird" enough to make me not entirely comfortable... [...] > > > > Section 3.2.1 > > > > > > > > * A single key must only be used for messages of a fixed or known > > > > length. If this is not the case, an attacker will be able to > > > > > > > > What's an example of a known-but-not-fixed length message? Just > > > > something with internal framing? > > > [JLS] This is a length extension problem. You need to know that the > message > > you validated is the same length as the message that was MAC-ed by the > > sender. This is the reason for CMAC coming into existence. > > > > Okay. Would "self-describing length" work? > [JLS] I think so, but a large part depends on what you mean by > "self-describing length". If you started with a two byte value which is > the length of the data then yes I think that would work. I would be worried > about the ability to do any bit-flipping on this but I think it would kill > the extension attack. However, if you are using CBOR and have an array of 4 > elements that would not work. To be clear: I'm not advocating a change to the text here. But I'm not sure I understand why a CBOR array of 4 elements would not work -- the individual elements within the array are themselves self-describing, so in toto the overall length is "self-describing", isn't it? [...] > > > > Section 8.2 > > > > > > > > (from the "COSE Key Types" Registry). It is expected future > > > > registered algorithms could have zero, one, or multiple elements. > > > > > > > > nit: missing "that". > > > [JLS] Section 8 has been re-written - you are going to need to review > again. > > > > Okay, I'll wait for the new revision. (This still seems to apply to the -10, now in 8.1) > > > > > > > > Section 10 > > > > > > > > Is [this document] going to be added as a reference on these > registries? > > > > Should it replace or augment 8152 in that role? > > > [JLS] We will see what happens w/ the question I sent to Barry about > Jean- > > Marc's DISCUSS on -struct. It applies to this document as well. > > > > Was I supposed to see a question you asked Barry in response to > Jean-Marc's > > response to my Discuss ballot? (I don't.) > [JLS] No it was a private note, and it is going to be done. Okay, thanks for confirming. (And for the updates!) -Ben From nobody Tue Jun 30 10:07:34 2020 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 85F023A0C73; Tue, 30 Jun 2020 10:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 8-nvU3ybn7eq; Tue, 30 Jun 2020 10:07:30 -0700 (PDT) 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 DE1BA3A0C53; Tue, 30 Jun 2020 10:07:29 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Jun 2020 10:07:21 -0700 From: Jim Schaad To: 'Benjamin Kaduk' CC: , , 'Matthew Miller' , 'The IESG' , References: <159183990940.7725.14952700358572148848@ietfa.amsl.com> <01b101d64599$56ddaf10$04990d30$@augustcellars.com> <20200621022735.GD11992@kduck.mit.edu> <01b101d64a9a$a5d4bd10$f17e3730$@augustcellars.com> <20200630045802.GK58278@kduck.mit.edu> In-Reply-To: <20200630045802.GK58278@kduck.mit.edu> Date: Tue, 30 Jun 2020 10:07:20 -0700 Message-ID: <03a301d64f00$ecd03270$c6709750$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQLNMCuwZrzKLnHZ+xfW3Sbr0xE1gAGarrJYAogYeMsBy7vs6QIAK1WppsQovMA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis-algs-09: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 17:07:33 -0000 > -----Original Message----- > From: Benjamin Kaduk > Sent: Monday, June 29, 2020 9:58 PM > To: Jim Schaad > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; cose-chairs@ietf.org; 'Matthew > Miller' ; 'The IESG' ; > cose@ietf.org > Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-rfc8152bis- > algs-09: (with DISCUSS and COMMENT) >=20 > On Wed, Jun 24, 2020 at 07:45:08PM -0700, Jim Schaad wrote: > > > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Saturday, June 20, 2020 7:28 PM > > > To: Jim Schaad > > > Cc: 'The IESG' ; > > > draft-ietf-cose-rfc8152bis-algs@ietf.org; > > cose- > > > chairs@ietf.org; 'Matthew Miller' = ; > > > cose@ietf.org > > > Subject: Re: [COSE] Benjamin Kaduk's Discuss on > > draft-ietf-cose-rfc8152bis- > > > algs-09: (with DISCUSS and COMMENT) > > > > > > On Thu, Jun 18, 2020 at 10:53:10AM -0700, Jim Schaad wrote: > > > > > > > > > > > > > -----Original Message----- > > > > > From: Benjamin Kaduk via Datatracker > > > > > Sent: Wednesday, June 10, 2020 6:45 PM > > > > > To: The IESG > > > > > Cc: draft-ietf-cose-rfc8152bis-algs@ietf.org; > > > > > cose-chairs@ietf.org; cose@ietf.org; Matthew Miller > > > > > ; > > > > > linuxwolf+ietf@outer-planes.net > > > > > Subject: Benjamin Kaduk's Discuss on > > > > > draft-ietf-cose-rfc8152bis-algs-09: (with DISCUSS and COMMENT) > > > > > > [...] > > > > > > > > > > I'd really like to see a reference for the analysis of and > > > > > validity/safety of the deviations from RFC 5869 HKDF, in = Section 5.1. > > > > [JLS] I am going to assume you are referring to using AES for = the PRF. > > I don't > > > know if such a thing exists. I can tell you where I got my = personal > > analysis > > > however. When the TLS 1.3 design group was meeting in Seattle, I > > > spent > > about > > > 20 minutes discussion what the required capabilities of the PRF = are > > > needed > > to > > > get things to work correctly. At least part of the discussion in > > > the > > group which > > > occurred around the same time was the ability to break the two > > > halves of > > HKDF > > > separated the way that TLS does. > > > > > > AES-CBC-MAC as the PRF, but also for sometimes skipping the = extract step. > > > > > > > Found something: https://eprint.iacr.org/2010/264.pdf look in > > > > appendix > > D > > > point 4. > > > > > > I think this is probably also what Bob Moskowitz came up with when > > > he was using the analogous CMAC-based KDF for HIP-DEX. Definitely > > > add it as a reference. > > > > > > I do note that "the analytical results in [the CBC-MAC] case are > > > much more restricted than with HMAC" and also that point 5 = discusses > > > a modification > > of > > > K(1) that "may be advisable with other PRF modes (such as = CBC-MAC)". > > > I suppose that we cannot safely make that modification at this = time, > > > at > > least > > > without assigning new codepoints, as it would break = interoperability > > > with existing deployments.. > > > > [JLS] I have not seen that before. It is interesting but since it = is > > not in the RFC I am not sure that doing so would be a good idea. I > > think I would rather just switch to KMAC personally. >=20 > Fair enough; the existing construction feels just "weird" enough to = make me not > entirely comfortable... >=20 > [...] > > > > > Section 3.2.1 > > > > > > > > > > * A single key must only be used for messages of a fixed = or known > > > > > length. If this is not the case, an attacker will be = able > > > > > to > > > > > > > > > > What's an example of a known-but-not-fixed length message? = Just > > > > > something with internal framing? > > > > [JLS] This is a length extension problem. You need to know that > > > > the > > message > > > you validated is the same length as the message that was MAC-ed by > > > the sender. This is the reason for CMAC coming into existence. > > > > > > Okay. Would "self-describing length" work? > > [JLS] I think so, but a large part depends on what you mean by > > "self-describing length". If you started with a two byte value = which is > > the length of the data then yes I think that would work. I would be > > worried about the ability to do any bit-flipping on this but I think > > it would kill the extension attack. However, if you are using CBOR = and > > have an array of 4 elements that would not work. >=20 > To be clear: I'm not advocating a change to the text here. > But I'm not sure I understand why a CBOR array of 4 elements would not work > -- the individual elements within the array are themselves self-describing, so in > toto the overall length is "self-describing", isn't it? [JLS] In the construction that is being used in COSE, I think that it = would be just fine as the CBOR array is being built by the validator and thus cannot be directly attacked. More generally, I think this construct is = much more susceptible to the bit twiddling attacks on CBC that just having = the length prefixed would be. This is be more true if the length is = prefixed by the validator rather than carried over the wire. I could be completely wrong. >=20 > [...] > > > > > Section 8.2 > > > > > > > > > > (from the "COSE Key Types" Registry). It is expected = future > > > > > registered algorithms could have zero, one, or multiple elements. > > > > > > > > > > nit: missing "that". > > > > [JLS] Section 8 has been re-written - you are going to need to > > > > review > > again. > > > > > > Okay, I'll wait for the new revision. >=20 > (This still seems to apply to the -10, now in =A78.1) [JLS] Fixed. >=20 > > > > > > > > > > Section 10 > > > > > > > > > > Is [this document] going to be added as a reference on these > > registries? > > > > > Should it replace or augment 8152 in that role? > > > > [JLS] We will see what happens w/ the question I sent to Barry > > > > about > > Jean- > > > Marc's DISCUSS on -struct. It applies to this document as well. > > > > > > Was I supposed to see a question you asked Barry in response to > > Jean-Marc's > > > response to my Discuss ballot? (I don't.) > > [JLS] No it was a private note, and it is going to be done. >=20 > Okay, thanks for confirming. (And for the updates!) >=20 > -Ben