From nobody Wed Jul 1 20:50:36 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 6A3533A0AFA; Wed, 1 Jul 2020 20:50:35 -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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <159366183536.10518.4421250272249428201@ietfa.amsl.com> Date: Wed, 01 Jul 2020 20:50:35 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-rfc8152bis-algs-11.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, 02 Jul 2020 03:50:36 -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-11.txt Pages : 55 Date : 2020-07-01 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-11 https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-rfc8152bis-algs-11 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 Jul 1 20:52: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 224BF3A0BFE; Wed, 1 Jul 2020 20:52:24 -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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <159366194410.14187.17168228733536350561@ietfa.amsl.com> Date: Wed, 01 Jul 2020 20:52:24 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-rfc8152bis-struct-11.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, 02 Jul 2020 03:52:24 -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-11.txt Pages : 88 Date : 2020-07-01 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-11 https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-struct-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-rfc8152bis-struct-11 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 Jul 1 21: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 5D0F23A0C3E for ; Wed, 1 Jul 2020 21:12: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 pMnqdJJVOmFH for ; Wed, 1 Jul 2020 21:12:44 -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 766DC3A0C3C for ; Wed, 1 Jul 2020 21:12: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; Wed, 1 Jul 2020 21:12:40 -0700 From: Jim Schaad To: References: <159366183572.10518.6789265806803324337@ietfa.amsl.com> In-Reply-To: <159366183572.10518.6789265806803324337@ietfa.amsl.com> Date: Wed, 1 Jul 2020 21:12:38 -0700 Message-ID: <048001d65027$07424ae0$15c6e0a0$@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: AQIC5G/WgjCGMSxWw+4FmG2aSiVYIqiahQig X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] FW: New Version Notification for draft-ietf-cose-rfc8152bis-algs-11.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: Thu, 02 Jul 2020 04:12:46 -0000 I think that these two documents address the comments from the IESG. -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Wednesday, July 1, 2020 8:51 PM To: Jim Schaad Subject: New Version Notification for = draft-ietf-cose-rfc8152bis-algs-11.txt A new version of I-D, draft-ietf-cose-rfc8152bis-algs-11.txt has been successfully submitted by Jim Schaad and posted to the IETF = repository. Name: draft-ietf-cose-rfc8152bis-algs Revision: 11 Title: CBOR Object Signing and Encryption (COSE): Initial Algorithms Document date: 2020-07-01 Group: cose Pages: 55 URL: = https://www.ietf.org/internet-drafts/draft-ietf-cose-rfc8152bis-algs-11.t= xt Status: = https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ Htmlized: = https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-11 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-rfc8152bis-algs-11 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 Thu Jul 2 17:24:41 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 2926E3A0B39; Thu, 2 Jul 2020 17:21:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: cose@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373570314.29538.17193487995372863363@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:21:43 -0700 Archived-At: Subject: [COSE] cose - Requested session has been scheduled 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, 03 Jul 2020 00:21:54 -0000 Dear Ivaylo Petrov, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. cose Session 1 (0:50 requested) Wednesday, 29 July 2020, Session II 1300-1350 Room Name: Room 5 size: 5 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/sessions/cose.ics Request Information: --------------------------------------------------------- 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: teep rats cfrg suit Key Participant Conflict: cbor ace lake People who must be present: Matthew A. Miller Benjamin Kaduk Ivaylo Petrov Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jul 2 22:29: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 E5B253A0CA9; Thu, 2 Jul 2020 22:28: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 hGdR2K-CrVCs; Thu, 2 Jul 2020 22:28:41 -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 6C22D3A0CA6; Thu, 2 Jul 2020 22:28:40 -0700 (PDT) Received: from [172.16.42.112] (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 49yk5f24r0zyTZ; Fri, 3 Jul 2020 07:28:38 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 615446917.9053921-b5c3f4f63088f5577dd523c75f704e63 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 3 Jul 2020 07:28:37 +0200 Message-Id: <46C68869-C5F5-4AB0-A605-4E5224352D0F@tzi.org> To: Ace Wg , core , 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: FINAL 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: Fri, 03 Jul 2020 05:28:44 -0000 Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF108. Remember that, occasionally, further agenda changes do happen. There has been no change from the DRAFT AGENDA in the Conflicts I noted: LAKE/SUIT (!). ACE/RATS. (I think 6LO/COSE can be ignored.) The only significant change is that LAKE/SUIT/LOOPS has been exchanged with CORE/TLS/TSVWG (Tuesday 1410Z vs. Friday 1100Z). Also, the mysterious HACKATHON has vanished. All times appear to be in UTC, even though nothing says so in the text agenda; https://datatracker.ietf.org/meeting/agenda-utc gives the same times. This time, I have focused on the events in Week 31; please see the original agenda for Week 30 preliminaries. Gr=C3=BC=C3=9Fe, Carsten MONDAY, July 27, 2020 1100-1240 Session I Rm 1 ART dispatch Dispatch WG - Joint with ARTAREA Rm 2 IRTF pearg Privacy Enhancements and Assessments Research = Group Rm 5 SEC *** teep Trusted Execution Environment Provisioning WG 1300-1350 Session II Rm 2 ART *** cbor Concise Binary Object Representation Maintenance = and Extensions WG Rm 3 INT intarea Internet Area Working Group WG Rm 6 RTG babel Babel routing protocol WG Rm 7 RTG detnet Deterministic Networking WG 1410-1550 Session III Rm 1 ART webtrans WebTransport WG Rm 3 IRTF qirg Quantum Internet Research Group Rm 7 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 7 SEC mls Messaging Layer Security WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG 1410-1550 Session III Rm 1 ART *** core Constrained RESTful Environments WG Rm 6 SEC tls Transport Layer Security WG Rm 7 TSV tsvwg Transport Area Working Group WG WEDNESDAY, July 29, 2020 1100-1240 Session I Rm 4 RTG bier Bit Indexed Explicit Replication WG Rm 5 SEC *** ace Authentication and Authorization for Constrained = Environments WG Rm 6 SEC *** rats Remote ATtestation ProcedureS WG Rm 7 TSV quic QUIC WG 1300-1350 Session II Rm 1 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 6 TSV tsvarea Transport Area Open Meeting 1410-1550 IETF Plenary - Plenary THURSDAY, July 30, 2020 1100-1240 Session I Rm 3 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 6 TSV tsvwg Transport Area Working Group WG 1300-1350 Session II Rm 4 INT *** lpwan IPv6 over Low Power Wide-Area Networks WG Rm 7 SEC saag Security Area Open Meeting 1410-1550 Session III Rm 2 INT add Adaptive DNS Discovery WG Rm 3 INT *** drip Drone Remote ID Protocol WG Rm 6 SEC acme Automated Certificate Management Environment WG FRIDAY, July 31, 2020 1100-1240 Session I Rm 5 SEC *** lake Lightweight Authenticated Key Exchange WG Rm 6 SEC *** suit Software Updates for Internet of Things WG Rm 7 TSV loops Local Optimizations on Path Segments BOF 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 4 IRTF coinrg Computing in the Network Research Group Rm 7 SEC privacypass Privacy Pass WG From nobody Mon Jul 6 10:12:14 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 617553A1788; Mon, 6 Jul 2020 10:11:48 -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, 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, URIBL_BLOCKED=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 e-A7kqAtqoDg; Mon, 6 Jul 2020 10:11:46 -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 81B783A1797; Mon, 6 Jul 2020 10:11:45 -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 066HAp9F030821; Mon, 6 Jul 2020 17:11:33 GMT Received: from eur05-vi1-obe.outbound.protection.outlook.com (mail-vi1eur05lp2174.outbound.protection.outlook.com [104.47.17.174]) by mx08-0018b601.pphosted.com with ESMTP id 322jfxujrd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 06 Jul 2020 17:11:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dgmRh4XFdQ5EDx9YkYRtTkhV8DiGL7XhnKqKdtQLRKuMpjaKweA7G20H4Cl6FZy5k8H/1PR4Lfndm0vGLOzKq/lu7+bhwsyEd52GbdOgp9TWtsCl6MrZgJ+IPpJemjYT03f40nTwLk15K+mmSd6eAI5r31A30c64DU5msbZgaCBPgLyxWoxnYrzn6nmUAf2aMH7WcYyyxeLmaiJud5sdcQ8ID9kjq9yCaXkBPN+3Z17znKiqafzlZ8uMCewd7z540nGXQll+HIJEVuFbCQAeXfqRfqgaD0h4Zqfnh+BIE+sWQ+2sQDpbmU5cEXNkC6uMreiaBSNj8wzFY2GuM4+F0g== 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=xcvI61q7QWdubwDxjN7JiJTIC+i/jxMZ6WOgFspNNkY=; b=Oc6XSGf+yMQPBH1B5ARN/3n5/d2WwVTU2aR0X7X8Okr2AgBHx3yXFYmdNVcnkCVxKihwGUBoDhsi4eA+kNxSBh7GEZyr4mOUPbXNdSuFB4B1V/H8K3eqAtv0+omLy7OlKdGS/eLwekbBUbj/0vb2REozCHdsHiqY1ymnu4wqcmKQbq3FX1mI4bauVUA+uN7lW+trE/hnqeA/fRIB+/oyZgHE3ZFZ3DULyrsswNdoDPnU5xHg3qdTW+/KzocNr56MYFiwNYyVDFTXqWWHGs7rQxkBseBnqNRlmVpD0zksCo461eRGAA8QQxTGSsa3/juFeEZigYAoeLH4FCJfkCr60w== 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=xcvI61q7QWdubwDxjN7JiJTIC+i/jxMZ6WOgFspNNkY=; b=HiT/YvalLgrytzxu7FMXdc3WWY1ZlzI2fdM9iJtW6OKDJGugPJ4Cxfd+8CFu3zBFRccRfM1Q7G3ThRH8AFa/21vKjxjjQWq6GMrVoVi6uH7O8MU8NgvJZcfRTD+GbdjddaZ7Xe1w9dEZ/0T7FNPZUwEFZv/pICnZ9tRS/V6pqys= Received: from PR3P189MB0972.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:4e::24) by PR3P189MB1098.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:43::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.24; Mon, 6 Jul 2020 17:11:32 +0000 Received: from PR3P189MB0972.EURP189.PROD.OUTLOOK.COM ([fe80::9934:17c3:c389:9ab1]) by PR3P189MB0972.EURP189.PROD.OUTLOOK.COM ([fe80::9934:17c3:c389:9ab1%8]) with mapi id 15.20.3153.029; Mon, 6 Jul 2020 17:11:32 +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: AQHWP5HWYMx0dsxxqkKUJSenlcfm0ajYr0OAgAGkT4CAACyDAIABqEEAgAALBQCAAk6dUIAOsioAgA2gY0A= Date: Mon, 6 Jul 2020 17:11:31 +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> <02d101d64cd9$a5743940$f05cabc0$@augustcellars.com> In-Reply-To: <02d101d64cd9$a5743940$f05cabc0$@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: 33db44e9-b9e5-46a3-20c6-08d821cfa14d x-ms-traffictypediagnostic: PR3P189MB1098: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04569283F9 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FQ6z3nDTulbHxxYA7X323Xkq9CiBVmudmJ5cZ3CSZH9k73WHEvHEG66MY4wKjfi1+1h7mlLgjnKs+cyJvGfXqL1x4Rc3c6LpnsBDqTXbdlwMhWvOqN/GjLVHqWpbCK2m1vVxqwX2q45KPFN5iy26ikbsvdPujbwCF0QZKlvRI9yJYFtzOzCJp8rUbhR4y8zMKRG7HBod7RzUcvI/SmjZU2mL0ZV62A+bZtugjLP37KvTrfc5sDx6DjZk08/sk+qr9c8KCyTt4vDtYy8BpsuTrvjL01+5qy1h0R5uF0hts5PmuIGm2puYmo+ZHODs52rAvKiHdgGA1s1eqjVUwuMXeQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3P189MB0972.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(366004)(376002)(346002)(136003)(478600001)(71200400001)(7696005)(64756008)(186003)(76116006)(5660300002)(110136005)(316002)(66946007)(2906002)(66556008)(52536014)(66446008)(66476007)(54906003)(6506007)(8936002)(55236004)(8676002)(83380400001)(30864003)(26005)(86362001)(33656002)(9686003)(4326008)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: wtzybbeK96LSOGU3NKfRAwnLytk9uBq6NOzQM1a30zkhT7dPNeXpXsx+uiTpBT3ShwnG3oyCWNKmshJZ5jsBo2OR7IxWxfvU6zrXQaKgQNeNr2xB/NeByW2nvlIr3CmB359Tb9XQSaCxVMmf+k1LOCWHiqV6td4GLr8YAvRzPLIKDcnT0A+8ITQXs8XqjE1yS9rbUbsU6xFLUHSjLi68G1w11CR0OMOjwjugBrEZVz8c2GTlVWkmeiAEjn1GauEpWh8Dc5PLLd6vUU5ONSs9aVUPsY1KAfjKvWTm0hi+gad+UJsV3gcjv98BM/sqDKIoxJnlKYrX4TbcUoSQqWi+WrnGATGt5v/XvgOKjNAGkeWjxPd5vZ48fas9lrY3nrmmVK8jCu9yMSdK8aT9pS0fOwxJZTp6YpVkX5qv3GIl++sSAwhAWIsSULpMd+FWNdlhJkCfZ68TFd/S61fj+UG1ocSMkfsBeKH03w+3T74orT4= 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PR3P189MB0972.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 33db44e9-b9e5-46a3-20c6-08d821cfa14d X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2020 17:11:32.0431 (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: AVQZG+oKh5pDDtmU3p8EVwx/ZSDNGfpH6oVljxHIh2h5CTYFKKOG5mpuBh3eXK3BtGvAFQlH2/Lxz2fFK84cdw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P189MB1098 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9673 signatures=668680 X-Proofpoint-Spam-Details: rule=outbound_idemia_notspam policy=outbound_idemia score=0 bulkscore=0 cotscore=-2147483648 spamscore=0 clxscore=1015 lowpriorityscore=0 phishscore=0 malwarescore=0 suspectscore=0 adultscore=0 impostorscore=0 mlxlogscore=999 mlxscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007060122 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, 06 Jul 2020 17:11:49 -0000 SGksDQoNClNvcnJ5IGZpcnN0IHRoYXQgSSBkaWRuJ3QgcmVhY3QgcXVpY2tlciwgYXQgdGhlIG1v bWVudCBJIGhhdmUgb3RoZXIgcHJpb3JpdGllcywgc28gSSBoYXZlIHRpbWUgdG8gY2hlY2sgdGhl IGxhdGVzdCBDT1NFIE1MIG1lc3NhZ2VzIG9ubHkgZnJvbSB0aW1lIHRvIHRpbWUuDQoNCi0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxs YXJzLmNvbT4gDQo+IEplYW4tTWFyYywNCj4gSSB0aGluayB0aGF0IHlvdSBoYXZlIGEgZGVlcCBt aXN1bmRlcnN0YW5kaW5nIGFib3V0IHRoaXMgYW5kIHdlIG5lZWQgdG8gZmluZCB3aGF0IHRoZSB0 ZXh0IGlzIHRoYXQgaXMgYm90aCBjb25mdXNpbmcgYW5kIGhvdyB0byBnZXQgY2xhcmlmaWNhdGlv bnMuDQoNCkkgaG9wZSB0aGlzIHRpbWUgd2UgY2FuIG1ha2UgZGVjaXNpdmUgcHJvZ3Jlc3Mgb24g dGhpcy4NCkxldCBtZSBqdXN0IGZvcmV3YXJuIHlvdSB0aGF0IEknbSBub3cgbW9yZSBjb252aW5j ZWQgdGhlcmUncyBhIHJlYWwgaXNzdWUgdG8gc29sdmUuIA0KQnV0IG1heWJlLCBqdXN0IGJ5IHNh eWluZyB0aGF0IHdoZW4gYXBwbGllZCB0byBzaWduYXR1cmUgdGhpcyBmb3JtYXQgZG9lc24ndCBo YXZlIG1hbnkgb2YgdGhlIHByb3BlcnRpZXMgdXN1YWxseSBhc3NvY2lhdGVkIHRvIGEgY291bnRl cnNpZ25hdHVyZS4NCg0KPiAtLS0tLS0tLS0NCj4+IDMuMS4gIENvbW1vbiBDT1NFIEhlYWRlciBQ YXJhbWV0ZXJzDQo+PiAgICAgICBUaGUgY291bnRlciBzaWduYXR1cmUgaGVhZGVyDQo+PiAgICAg ICBwYXJhbWV0ZXIgY2FuIG9jY3VyIGFzIGFuIHVucHJvdGVjdGVkIGF0dHJpYnV0ZSBpbiBhbnkg b2YgdGhlDQo+PiAgICAgICBmb2xsb3dpbmcgc3RydWN0dXJlczogQ09TRV9TaWduMSwgQ09TRV9T aWduYXR1cmUsIENPU0VfRW5jcnlwdCwNCj4+ICAgICAgIENPU0VfcmVjaXBpZW50LCBDT1NFX0Vu Y3J5cHQwLCBDT1NFX01hYywgYW5kIENPU0VfTWFjMC4gVGhlc2UNCj4+ICAgICAgIHN0cnVjdHVy ZXMgYWxsIGhhdmUgdGhlIHNhbWUgYmVnaW5uaW5nIGVsZW1lbnRzLCBzbyB0aGF0IGENCj4+ICAg ICAgIGNvbnNpc3RlbnQgY2FsY3VsYXRpb24gb2YgdGhlIGNvdW50ZXIgc2lnbmF0dXJlIGNhbiBi ZSBjb21wdXRlZC4NCj4+ICAgICAgIERldGFpbHMgb24gY291bnRlciBzaWduYXR1cmVzIGFyZSBm b3VuZCBpbiBTZWN0aW9uIDUNCj4+DQo+PiBOb25ldGhlbGVzcywgdGhleSBhcmUgZGlmZmVyZW5j ZXMgYmV0d2VlbiB0aG9zZSBmb3JtYXRzIHRoYXQgYXQgbGVhc3QgDQo+PiBpbXBhY3QgdGhlIHBh eWxvYWQsIGFuZCB0aGUgdGV4dCBkb2Vzbid0IGNsYXJpZnkgZXhwbGljaXRseSBob3cgdGhleSAN Cj4+IGltcGFjdCBjb3VudGVyLSBzaWduYXR1cmVzDQo+IFNvIHRoZSBmaXJzdCB0aHJlZSBlbGVt ZW50cyBhcmU6DQo+KiBQcm90ZWN0ZWQgaGVhZGVycw0KPiogVW5wcm90ZWN0ZWQgaGVhZGVycw0K PiogUGF5bG9hZCBvZiB0aGUgb2JqZWN0DQoNCltKTFNdDQpJbiBzZWN0aW9uIDUgdGhlcmUgaXMg dGV4dCB3aGljaCBzYXlzICJ0aGF0IHRoZSBjb3VudGVyc2lnbmF0dXJlIG9wZXJhdGlvbiBuZWVk cyB0byBiZSB0cmVhdGVkIGFzIGEgc2VwYXJhdGUgb3BlcmF0aW9uIGZyb20gdGhlIGluaXRpYWwg b3BlcmF0aW9uIi4gIFRoZSBwdXJwb3NlIG9mIHRoaXMgdGV4dCB3YXMgdG8gc3RhdGUgdGhhdCBh bGwgb2YgdGhlIGNyeXB0b2dyYXBoaWMgb3BlcmF0aW9ucyBvbiB0aGUgdGFyZ2V0IG9mIHRoZSBj b3VudGVyc2lnbmF0dXJlIG5lZWQgdG8gYmUgY29tcGxldGVkIHByaW9yIHRvIHN0YXJ0aW5nIHRo ZSBjb3VudGVyc2lnbmF0dXJlIG9wZXJhdGlvbi4gIFRoaXMgbWVhbnMgdGhhdCBsb29raW5nIGF0 IHRoYXQgYXJyYXkgb2YgaXRlbXMgYWJvdmUgdGhlcmUgaXMgYSBiaW5hcnkgc3RyaW5nLCBhIG1h cCwgYW5kIGEgYmluYXJ5IHN0cmluZy4gIFRoZSBjb3VudGVyc2lnbmF0dXJlIG9wZXJhdGlvbiBp cyB0b3RhbGx5IGFnbm9zdGljIHRvIGhvdyB0aGF0IGxhc3QgYnl0ZSBzdHJpbmcgaXMgY3JlYXRl ZC4gIEl0IGhhcyB0byBiZSBvciBlbHNlIGEgdGhpcmQgcGFydHkgd291bGQgbm90IGJlIGFibGUg dG8gYXBwbHkgYSBjb3VudGVyc2lnbmF0dXJlLg0KDQpbSk1EXQ0KV2VsbCwgdGhlIGZpcnN0IHR3 byBhcmUgaWRlbnRpY2FsLCBidXQgdGhlIHRoaXJkIGlzIHZlcnkgZGlmZmVyZW50IChldmVuIGlm IHlvdSBkaXNhZ3JlZSBvbiB0aGF0LCBtYXliZSBpdCdkIGJlIHVzZWZ1bCB0byBzcGVjaWZ5ICIn dGhlIHNhbWUgMyBiZWdpbm5pbmcgZWxlbWVudCIpLg0KLSBmb3IgZW5jcnlwdGlvbiwgdGhlIHRo aXJkICgnY2lwaGVydGV4dCcpIGlzIHRoZSBvdXRwdXQgb2YgdGhlIGVuY3J5cHRpb24gb3BlcmF0 aW9uLiBUaGUgY2xlYXJ0ZXh0IGlzIHByb2Nlc3NlZCwgYW5kIHRoZSByZXN1bHQgaXMgdGhlIGNv bnRlbnQgb2YgdGhlIGVsZW1lbnQgJ2NpcGhlcnRleHQnLiANClNvIEkgYWdyZWUgaXQgd29ya3Mg YXMgeW91IGRlc2NyaWJlLg0KLSBmb3Igc2lnbmF0dXJlIGFuZCBtYWMsIHRoZSB0aGlyZCAoJ3Bh eWxvYWQnKSBpcyB0aGUgKmlucHV0KiBvZiB0aGUgc2lnbmF0dXJlL21hYyBvcGVyYXRpb24uDQpX aGVuIHRoaXMgaW5wdXQgaXMgcHJvY2Vzc2VkLCB0aGUgb3V0cHV0IGlzIHRoZSBjb250ZW50IG9m ICd0YWcnIGZvciBtYWMgYW5kICdzaWduYXR1cmUnIGZvciBzaWduYXR1cmUuIA0KQnV0IHRob3Nl IGFyZSBwbGFjZWQgaW5zaWRlIHRoZSBmb3VydGggYW5kIGxhc3QgZWxlbWVudCBvZiB0aGUgc3Ry dWN0dXJlDQpUaGUgdGhpcmQgaXMgbGVmdCB1bm1vZGlmaWVkIGJ5IHRoZSBjYWxjdWxhdGlvbiBv ZiB0aGUgc2lnbmF0dXJlLg0KKG1vcmUgcHJlY2lzZWx5LCB0aGV5IHdpbGwgYmUgZGlyZWN0bHkg dGhlIGZvdXJ0aCBlbGVtZW50IGZvciBtYWMgYW5kIFNpZ24xLCBidXQgZm9yIENPU0VfU2lnbiBp bnN0ZWFkIGl0IHdpbGwgYmUgb25lIG9mIHRoZSAnc2lnbmF0dXJlJyBlbGVtZW50IGluc2lkZSB0 aGUgbGlzdCBvZiBDT1NFX1NpZ25hdHVyZSB0aGF0IGNvbnN0aXR1dGVzIHRoZSBmb3VydGggZWxl bWVudCkuDQpTbyAqaWYqIG9ubHkgdGhpcyAzIGVsZW1lbnRzIGFyZSB1c2VkIHRvIGNhbGN1bGF0 ZSBhIENPU0UgY291bnRlci1zaWduYXR1cmUsIHRoZW4gaXQgZG9lc24ndCBoYXZlIGFueSBpbXBh Y3QgaWYgdGhlIGNyeXB0b2dyYXBoaWMgb3BlcmF0aW9ucyBvZiB0aGUgaW5pdGlhbCBzaWduYXR1 cmUgYXJlIG5vdCBkb25lIHdoZW4gY2FsY3VsYXRpbmcgdGhlIGNvdW50ZXItc2lnbmF0dXJlLiBC ZWNhdXNlIHRoZWlyIG91dHB1dCBpc24ndCB1c2VkIHRvIGNhbGN1bGF0ZSBpdCwgb25seSB0aGVp ciBpbnB1dC4NCkFuZCB0aGF0J3MgZXhhY3RseSB3aHkgZm9yIG1lLCB0aGlzIGZvcm1hdCB0aGVu IGlzbid0IGEgcmVhbCBjb3VudGVyIHNpZ25hdHVyZS4NCg0KPiAtLS0tLS0tLS0NCj4gNS4gIENv dW50ZXIgU2lnbmF0dXJlcw0KPg0KPiAgICBBIGNvdW50ZXIgc2lnbmF0dXJlIGlzIG5vcm1hbGx5 IGRlZmluZWQgYXMgYSBzZWNvbmQgc2lnbmF0dXJlIHRoYXQNCj4gICAgY29uZmlybXMgYSBwcmlt YXJ5IHNpZ25hdHVyZS4gIEEgbm9ybWFsIGV4YW1wbGUgb2YgYSBjb3VudGVyDQo+ICAgIHNpZ25h dHVyZSBpcyB0aGUgc2lnbmF0dXJlIHRoYXQgYSBub3RhcnkgcHVibGljIHBsYWNlcyBvbiBhIGRv Y3VtZW50DQo+ICAgIGFzIHdpdG5lc3NpbmcgdGhhdCB5b3UgaGF2ZSBzaWduZWQgdGhlIGRvY3Vt ZW50LiAgVGh1cyBhcHBseWluZyBhDQo+ICAgIGNvdW50ZXIgc2lnbmF0dXJlIHRvIGVpdGhlciB0 aGUgQ09TRV9TaWduYXR1cmUgb3IgQ09TRV9TaWduMSBvYmplY3RzDQo+ICAgIG1hdGNoIHRoaXMg dHJhZGl0aW9uYWwgZGVmaW5pdGlvbi4NCj4NCj4gVGhpcyB3aWxsIG9ubHkgYmUgdHJ1ZSBpZiB0 aGUgcGF5bG9hZCBvZiB0aGUgY291bnRlciBzaWduYXR1cmUgDQo+IGluY29ycG9yYXRlcyB0aGUg Ynl0ZSBzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSBwcmltYXJ5IHNpZ25hdHVyZSB2YWx1ZS4NCj4g SWYgdGhpcyBub3QgdGhlIGNhc2UgZm9yIENPU0UgY291bnRlciBzaWduYXR1cmUsIHRoaXMgdGV4 dCBNVVNUIGJlIA0KPiByZW1vdmVkIGFuZCBjbGFyaWZpY2F0aW9uIG90aGVyd2lzZSBNVVNUIGJl IGJyb3VnaHQgdG8gdGhlIHN0YW5kYXJkLg0KPiBUaGUgdXNlIG9mIHRoZSB0ZXJtIGNvdW50ZXIg c2lnbmF0dXJlIHdpbGwgdGhlbiBiZSBtaXNsZWFkaW5nLCBhbmQgDQo+IHNob3VsZCBiZSBjb25z aWRlcmVkIHRvIGJlIHJlbW92ZWQuDQoNCltKTFNdIEFzIG5vdGVkIGFib3ZlIHRoYXQgaXMgZXhh Y3RseSB3aGF0IHRoZSBwYXlsb2FkIGlzDQpbSk1EXSBNYXliZSBteSBhZGRlZCBjbGFyaWZpY2F0 aW9uIGFib3ZlIG5vdyBtYWtlcyBpdCBjbGVhciB3aGVyZSBleGFjdGx5IHdlIGRpdmVyZ2UgaW4g dGhlIGNvbXByZWhlbnNpb24gb2YgdGhpcy4NCg0KPiAgICBXaGVuIGRvbmUgb24gYSBDT1NFX1Np Z25hdHVyZSwgdGhlIG5vcm1hbCBjb3VudGVyIHNpZ25hdHVyZSBzZW1hbnRpY3MNCj4gICAgYXJl IHByZXNlcnZlZC4gIFRoYXQgaXMgdGhlIGNvdW50ZXIgc2lnbmF0dXJlIG1ha2VzIGEgc3RhdGVt ZW50IGFib3V0DQo+ICAgIHRoZSBleGlzdGVuY2Ugb2YgYSBzaWduYXR1cmUgYW5kLCB3aGVuIHVz ZWQgYXMgYSB0aW1lc3RhbXAsIGEgdGltZQ0KPiAgICBwb2ludCBhdCB3aGljaCB0aGUgc2lnbmF0 dXJlIGV4aXN0cw0KPg0KPiBUaGlzIHdpbGwgb25seSBiZSB0cnVlIGlmIHRoZSBwYXlsb2FkIG9m IHRoZSBjb3VudGVyIHNpZ25hdHVyZSANCj4gaW5jb3Jwb3JhdGVzIHRoZSBieXRlIHN0cmluZyBy ZXByZXNlbnRpbmcgdGhlIHByaW1hcnkgc2lnbmF0dXJlIHZhbHVlLg0KPiBJZiB0aGlzIG5vdCB0 aGUgY2FzZSBmb3IgQ09TRSBjb3VudGVyIHNpZ25hdHVyZSwgdGhpcyB0ZXh0IE1VU1QgYmUgDQo+ IHJlbW92ZWQgYW5kIGNsYXJpZmljYXRpb24gb3RoZXJ3aXNlIE1VU1QgYmUgYnJvdWdodCB0byB0 aGUgc3RhbmRhcmQuDQo+IFRoZSB1c2Ugb2YgdGhlIHRlcm0gY291bnRlciBzaWduYXR1cmUgd2ls bCB0aGVuIGJlIG1pc2xlYWRpbmcsIGFuZCANCj4gc2hvdWxkIGJlIGNvbnNpZGVyZWQgdG8gYmUg cmVtb3ZlZC4NCg0KW0pMU10gQXMgbm90ZWQgYWJvdmUsIHRoaXMgaXMgdHJ1ZSBmb3IgYXBwbHlp bmcgdG8gYSBDT1NFX1NpZ25hdHVyZS4NCltKTURdIFNhbWUgYXMgYWJvdmUsIGhvcGluZyBteSB0 ZXh0IDIgY29tbWVudHMgYWJvdmUgY2xhcmlmaWVzIHRoZSBkaXZlcmdlbmNlLg0KDQo+ICAgIFdo ZW4gZG9uZSBvbiBhIENPU0VfTWFjIG9yIGENCj4gICAgQ09TRV9NYWMwLCBvbmUgZWZmZWN0aXZl bHkgdXBncmFkZXMgdGhlIE1BQyBvcGVyYXRpb24gdG8gYSBzaWduYXR1cmUNCj4gICAgb3BlcmF0 aW9uLg0KPg0KPiBUaGlzIHdpbGwgYmUgdHJ1ZSBldmVuIHdoZW4gdGhlIHBheWxvYWQgb2YgdGhl IGNvdW50ZXIgc2lnbmF0dXJlIG9ubHkgDQo+IGluY29ycG9yYXRlcyB0aGUgbWFjICdwYXlsb2Fk JywgYW5kIG5vdCBpdHMgJ3RhZycuDQoNCltKTFNdIEFzIG5vdGVkIGFib3ZlLCBvbmx5IHRoZSBm aXJzdCB0aHJlZSBlbGVtZW50cyBvZiB0aGUgQ09TRV9NYWMgYW5kIENPU0VfTWFjMCBzdHJ1Y3R1 cmVzIGFyZSB1c2VkIHdoZW4gY29tcHV0aW5nIHRoZSBjb3VudGVyc2lnbmF0dXJlLiAgVGhpcyBt ZWFucyB0aGF0IHRoZSB0YWcsIHdoaWNoIGlzIHRoZSBmb3VydGggZWxlbWVudCBpcyBub3QgaW5j bHVkZWQuDQpbSk1EXSBTbyBhcyBJIHdyb3RlLCB5b3VyIHRleHQgaXMgY29ycmVjdCBhcyBpdCBq dXN0IHNheXMgInVwZ3JhZGVzIHRvIGEgc2lnbmF0dXJlIG9wZXJhdGlvbiIuDQpCdXQgd2hlbiBh cHBsaWVkIG9uIGNvdW50ZXIgc2lnbmF0dXJlLCB0aGUgZm91cnRoIGVsZW1lbnQgKm11c3QqIHNv bWVob3cgYmUgaW5jbHVkZWQgdG8gY3JlYXRlIGEgcmVhbCBjb3VudGVyc2lnbmF0dXJlLg0KDQo+ ICAgIFdoZW4gZG9uZSBvbiBhIENPU0VfRW5jcnlwdCBvciBDT1NFX0VuY3J5cHQwLCB0aGUNCj4g ICAgZXhpc3RlbmNlIG9mIHRoZSBlbmNyeXB0ZWQgZGF0YSBpcyBhdHRlc3RlZCB0by4NCj4NCj4g VGhpcyB3aWxsIGJlIHRydWUgZXZlbiB3aGVuIG9ubHkgJ2NpcGhlcnRleHQnIGlzIGluY2x1ZGVk IGluIHRoZSANCj4gY291bnRlcnNpZ25hdHVyZSBwYXlsb2FkLg0KW0pMU10gQXMgbm90ZWQgYWJv dmUsIHRoZSBjaXBoZXJ0ZXh0IGlzIHdoYXQgaXMgdXNlZC4NCltKTURdIEl0IHdvdWxkIGJlIGdv b2QgdG8gaGF2ZSBzb21ld2hlcmUgaW4gdGhlIHRleHQgZXhwbGljaXRseSB0aGUgY2xhcmlmaWNh dGlvbiB0aGF0IGl0J3MgdGhlIGZpcnN0IDMgZWxlbWVudCB0aGF0IGFyZSB1c2VkLCB0aGUgdGhp cmQgYmVpbmcgJ3BheWxvYWQnIGZvciBzaWduYXR1cmUgYW5kIG1hYywgYW5kICdjaXBoZXJ0ZXh0 JyBmb3IgZW5jcnlwdGlvbi4NCg0KPiAtLS0tLS0tLS0NCj4gNS4xLiAgRnVsbCBDb3VudGVyIFNp Z25hdHVyZXMNCj4gICAgIFRoZSBwcm9jZXNzIG9mIGNyZWF0aW5nIGFuZCB2YWxpZGF0aW5nIGFi YnJldmlhdGVkDQo+ICAgIGNvdW50ZXIgc2lnbmF0dXJlcyBpcyBkZWZpbmVkIGluIFNlY3Rpb24g NC40Lg0KPg0KPiAxKSBhYmJyZXZpYXRlZCBoZXJlIHNlZW1zIGJlIGEgdHlwbw0KW0pMU10gTXkg ZGljdGlvbmFyeSB0ZWxscyBtZSB0aGF0IHRoaXMgaXMgY29ycmVjdGx5IHNwZWx0Lg0KW0pNRF0g SSBtZWFudCBlZGl0b3JpYWwgbWlzdGFrZS4gVGhlIHBhcmFncmFwaCBpcyAiRnVsbCBDb3VudGVy IFNpZ25hdHVyZXMiLCBzbyB0aGUgd2hvbGUgd29yZCBuZWVkcyB0byBiZSByZW1vdmVkICgicHJv Y2VzcyBvZiBjcmVhdGluZyBhbmQgdmFsaWRhdGluZyBjb3VudGVyIHNpZ25hdHVyZXMiKS4NCg0K PiAyKSBUaGUgcHJvY2VzcyBpbiBTZWN0aW9uIDQuNCBkb2Vzbid0IHNwZWNpZnkgZXhwbGljaXRs eSBob3cgdG8gDQo+IHBvcHVsYXRlIHRoZSBwYXlsb2FkIGVsZW1lbnQgb2YgdGhlIFNpZ19zdHJ1 Y3R1cmUgaW4gdGhlIGNhc2Ugb2YgYSANCj4gY291bnRlciBzaWduYXR1cmUgQ2xhcmlmaWNhdGlv biBhYm91dCB0aGF0IGlzIGFic29sdXRlbHkgcmVxdWlyZWQgDQo+IGVpdGhlciBoZXJlIGluIHNl Y3Rpb24gNS4xIG9yIGluIHNlY3Rpb24gNC40DQoNCltKTFNdICBJIHdpbGwgYWRkIGNsYXJpZmlj YXRpb24gaW4gdGhlIHRleHQgdGhhdCB0aGUgQ09TRV9TaWduYXR1cmUgc3RydWN0dXJlIGlzIHdo YXQgaXMgcmVmZXJyZWQgdG8gd2hlbiBpdCBzYXlzIHRoYXQgdGhlIGRldGFpbHMgb2YgdGhlIGZp ZWxkcyBvZiBhIGNvdW50ZXJzaWduYXR1cmUgYXJlIGZvdW5kIGluIHNlY3Rpb24gNC4xLg0KDQo+ IC0tLS0tLS0tLQ0KPiA0LjQuICBTaWduaW5nIGFuZCBWZXJpZmljYXRpb24gUHJvY2Vzcw0KPiAg ICA1LiAgVGhlIHBheWxvYWQgdG8gYmUgc2lnbmVkIGVuY29kZWQgaW4gYSBic3RyIHR5cGUuICBU aGUgcGF5bG9hZCBpcw0KPiAgICAgICAgcGxhY2VkIGhlcmUgaW5kZXBlbmRlbnQgb2YgaG93IGl0 IGlzIHRyYW5zcG9ydGVkLg0KPg0KPiAxKSBGb3IgY291bnRlciBzaWduYXR1cmUgb2YgYSBzaWdu YXR1cmUsIHRoZSBzaW1wbGVzdCBpbnRlcnByZXRhdGlvbiANCj4gb2YgdGhpcyB0ZXh0IGlzIHRo YXQgdGhlIHBheWxvYWQgaXMgdGhlICdwYXlsb2FkJyBlbGVtZW50IG9mIHRoZSBpbml0aWFsIHNp Z25hdHVyZS4NCj4gVGhleSBhcmUgaG93ZXZlciBtYWpvciBpc3N1ZXMgaWYgaW50ZXJwcmV0ZWQg bGlrZSB0aGF0Lg0KPiBJZiBJIGhhdmUgcmVhZCBpdHMgc291cmNlIGNvcnJlY3RseSwgdGhlIENP U0UtSkFWQSBpbXBsZW1lbnRhdGlvbiBkb2VzIA0KPiBkbyBjb3VudGVyLXNpZ25hdHVyZXMgb2Yg c2lnbmF0dXJlcyB0aGlzIHdheS4NCj4NCj4gSWYgdGhpcyBpcyB3aGF0J3MgaW50ZW5kZWQsIHRo ZW4gQ09TRSBjb3VudGVyIHNpZ25hdHVyZXMgYXJlbid0IA0KPiBjb3VudGVyIHNpZ25hdHVyZXMg aW4gdGhlIGNsYXNzaWNhbCBtZWFuaW5nLCB0aGV5IGFyZSBpbiBmYWN0IA0KPiBiYXNpY2FsbHkg ZnVsbHkgZXF1aXZhbGVudCB0byBjb3NpZ25hdHVyZXMsIGdpdmVuIHRoYXQgd2hhdCB0aGV5IA0K PiBpbmNsdWRlIGlzIG9ubHkgdGhlIHByaW1hcnkgcGF5bG9hZCwgYW5kIGRvZXNuJ3QgaW5jbHVk ZSB0aGUgcHJpbWFyeSBzaWduYXR1cmUuDQo+IFNvIGFsbCB0ZXh0IHN1Z2dlc3Rpbmcgb3RoZXJ3 aXNlIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIHN0YW5kYXJkLg0KPiBOZXcgdGV4dCBzaG91 bGQgYmUgYWRkZWQgdG8gbWFrZSBpdCBleHRyZW1lbHkgY2xlYXIgdGhhdCB0aG9zZSANCj4gc2ln bmF0dXJlcyBjYW4ndCBmdW5jdGlvbiBhcyBhY3R1YWwgY291bnRlci1zaWduYXR1cmVzLg0KPiBJ IHdvdWxkIGFjdHVhbGx5IGJlIGluIGZhdm9yIG9mIHJlbW92aW5nIHVzZSBvZiB0aGUgdGVybSAN Cj4gY291bnRlci1zaWduYXR1cmUgZ2l2ZW4gaG93IG1pc2xlYWRpbmcgaXQgd291bGQgYmUgdGhl bi4NCj4NCj4gSWYgdGhlIGludGVudCBpcyBmb3IgY291bnRlciBzaWduYXR1cmUgaW4gdGhpcyBz dGFuZGFyZCB0byBiZSByZWFsIA0KPiBjb3VudGVyIHNpZ25hdHVyZXMsIHRoZW4gYW4gZXhwbGlj aXQgY2xhcmlmaWNhdGlvbiBpcyByZXF1aXJlZCBhYm91dCANCj4gaG93ICdwYXlsb2FkJyBpcyBw b3B1bGF0ZWQuDQo+IFRoZSBzaW1wbGVzdCBzb2x1dGlvbiBpcyBwcm9iYWJseSB0byBzYXkgdGhh dCBpdCBpbmNsdWRlcyBhbGwgb2YgdGhlIA0KPiBwcmltYXJ5IHNpZ25hdHVyZSBzdHJ1Y3R1cmUs IGV4Y2VwdCB0aGF0IGFsbCBvZiB0aGUgJ3VucHJvdGVjdGVkJyANCj4gaGVhZGVycyBzaGFsbCBi ZSByZW1vdmVkIGZpcnN0ICh0aGVyZSB3b3VsZCBiZSByZWN1cnNpb24gcHJvYmxlbXMgDQo+IG90 aGVyd2lzZSkgVGhpcyBzcGVjaWZpY2FsbHkgc29sdmVzIHRoZSBpc3N1ZSBvZiBzcGVjaWZ5aW5n IHdoaWNoIG9mIA0KPiB0aGUgaW5pdGlhbCBzaWduYXR1cmUgaXMgY291bnRlcnNpZ25lZCBpbiBj YXNlIHRoZXkgYXJlIG11bHRpcGxlIHNpZ25lcnMuDQo+IFNvbHV0aW9uIHRvIGluY2x1ZGUgbGVz cyBvZiB0aGUgaW5pdGlhbCBzdHJ1Y3R1cmUgaW4gdGhlIGNvdW50ZXIgDQo+IHNpZ25hdHVyZSBz ZWVtIHRvIGJlIG1vcmUgY29tcGxleCwgYW5kIHdvdWxkIG5lZWQgYW55d2F5IHRvIGluY2x1ZGUg DQo+IGFsbCBvZiB0aGUgaW5pdGlhbCBzaWduZXJzLCBleGNlcHQgaWYgZGVzaWduaW5nIGEgd2F5 IHRvIHNwZWNpZnkgb25seSANCj4gb25lIG9mIHRoZW0gKG1heWJlIHdoZW4gdGhlIGNvdW50ZXIg c2lnbmF0dXJlIGlzIGluc2VydGVkIGluc2lkZSB0aGUgDQo+ICd1bnByb3RlY3RlZCcgZWxlbWVu dCBvZiBoaXMgc3BlY2lmaWMgc2lnbmF0dXJlID8pLg0KDQpbSkxTXSBZZXMgSSBjYW4gc2VlIGhv dyB0aGlzIGlzIGNvbmZ1c2luZy4gIEkgd2lsbCBhZGQgYSBwYXJhZ3JhcGggb24gaG93IHRvIGRl dGVybWluZSB3aGF0IHRoZSBwYXlsb2FkIGlzIGZvciBhIGNvdW50ZXJzaWduYXR1cmUgb3BlcmF0 aW9uLg0KW0pNRF0gT0suIElmIGluZGVlZCBvbmx5IHRoZSBmaXJzdCB0aHJlZSBlbGVtZW50cyBh cmUgdXNlZCwgdGhlbiB0aGUgY2xhcmlmaWNhdGlvbnMgYWxzbyBuZWVkIHRvIGdvIHRocm91Z2gg dGhlIHdob2xlIGRvY3VtZW50IHRvIHJlbW92ZSB0aGUgdGV4dCBpbXBseWluZyB0aGUgY291bnRl ci1zaWduYXR1cmUgaGFzIHByb3BlcnRpZXMgdGhhdCByZXF1aXJlIGJlaW5nIGFibGUgdG8gcHJv dGVjdCBhZ2FpbnN0IG1vZGlmaWNhdGlvbnMgb2YgdGhlIGluaXRpYWwgc2lnbmF0dXJlIHRoYXQn cyBpbnNpZGUgdGhlIGZvdXJ0aCBlbGVtZW50Lg0KDQo+IDIpIEZvciBjb3VudGVyIHNpZ25hdHVy ZSBvZiBhIG1hYywgdGhlIHNpbXBsZXN0IGludGVycHJldGF0aW9uIG9mIHRoaXMgDQo+IHRleHQg aXMgdGhhdCB0aGUgcGF5bG9hZCBpcyB0aGUgJ3BheWxvYWQnIGVsZW1lbnQgb2YgdGhlIGluaXRp YWwgDQo+IHNpZ25hdHVyZSBhbmQgJ3RhZycgaXNuJ3QgaW5jbHVkZWQgaW4gdGhlIGNvdW50ZXJz aWduYXR1cmUuDQo+IFRoZXJlJ3Mgbm90IGEgbWFqb3IgaXNzdWUgaWYgaW50ZXJwcmV0ZWQgbGlr ZSB0aGF0LCBhcyBJIGRpZG4ndCBzZWUgYSANCj4gY2xhaW0gdGhhdCB0aGlzIHdvdWxkIGNvbnRy YWRpY3QuDQo+DQo+IDMpIEZvciBlbmNyeXB0ZWQgY29udGVudCwgdGhlIHNpbXBsZXN0IGludGVy cHJldGF0aW9uIG9mIHRoaXMgdGV4dCBpcyANCj4gdGhhdCB0aGUgcGF5bG9hZCBpcyB0aGUgJ2Np cGhlcnRleHQnIGVsZW1lbnQgLg0KPiBUaGVyZSdzIG5vdCBhIG1ham9yIGlzc3VlIGlmIGludGVy cHJldGVkIGxpa2UgdGhhdCwgbm9uZXRoZWxlc3MgaXQgDQo+IHdvdWxkIGJlIG1hZGUgY2xlYXJl ciBieSBzcGVjaWZ5aW5nIGl0IGV4cGxpY2l0bHkNCj4NCj4gLS0tLS0tLS0tDQo+IDUuMi4gIEFi YnJldmlhdGVkIENvdW50ZXIgU2lnbmF0dXJlcw0KPiAgICBJbnN0ZWFkLCB0aGUgcGFyYW1ldGVy cyBmb3IgY29tcHV0aW5nIG9yIHZlcmlmeWluZyB0aGUNCj4gICAgYWJicmV2aWF0ZWQgY291bnRl ciBzaWduYXR1cmUgYXJlIGluZmVycmVkIGZyb20gdGhlIHNhbWUgY29udGV4dCB1c2VkDQo+ICAg IHRvIGRlc2NyaWJlIHRoZSBlbmNyeXB0aW9uLCBzaWduYXR1cmUsIG9yIE1BQyBwcm9jZXNzaW5n DQo+DQo+IDEpIFRoaXMgYXBwZWFycyB0byBtZWFuIHRoYXQgaWYgYSBzaWduYXR1cmUgd2l0aCBh IHNpbmdsZSBzaWduZXIgaXMgDQo+IGNvdW50ZXItIHNpZ25lZCB0aGlzIHdheSwgdGhlIGNvbnRl bnQgKyB0aGUgcHJvdGVjdGVkIGhlYWRlcnMgKyB0aGUgDQo+IHNpZ25lciBhcmUgdGhlIHNhbWUg YXMgdGhlIGluaXRpYWwgc2lnbmF0dXJlID8NCj4gICAgIElmIHNvLCBpdCBkb2Vzbid0IHNlZW0g dG8gaGF2ZSBtdWNoIHZhbHVlLCBzaW5jZSBpdCByZXNpZ25zIA0KPiBleGFjdGx5IHRoZSBzYW1l IHRoaW5nIChleGNlcHQgdGhlIHNpZ25lciBwcm90ZWN0ZWQgaGVhZGVyIGlmIA0KPiBhcHBsaWNh YmxlKSwgc28gaXQgc2hvdWxkIGJlIG1hZGUgZXZlbiBtb3JlIGV4cGxpY2l0IElmIHRoZXkgYXJl IA0KPiBtdWx0aXBsZSBzaWduZXJzIG9mIHRoZSBpbml0aWFsIHNpZ25hdHVyZSwgaXMgaXQgaW50 ZW5kZWQgdGhhdCB0aGUgc2lnbmVyIG11c3QgYmUgdGhlIGZpcnN0IG9mIHRoZSBsaXN0ID8NCj4g Rm9yIG1hYyBhbmQgZW5jcnlwdGlvbiwgaXQncyB1bmNsZWFyIGhvdyB0aGUgc2lnbmVyIHB1Ymxp YyBrZXkgd2lsbCBiZSANCj4gaWRlbnRpZmllZCwgYXMgd2UgaGF2ZSBvbmx5IHRoZSBpbmZvcm1h dGlvbiBmb3IgdGhlIG1hYy9lbmNyeXB0aW9uIGtleS4NCj4NCj4gSWYgd2hhdCBpcyBhY3R1YWxs eSBpbnRlbmRlZCB0aGF0IHRoZSBpZGVudGlmaWNhdGlvbiBvZiB0aGUgDQo+IGNvdW50ZXItc2ln bmVyIGlzIHRocm91Z2ggYW4gb3V0LW9mLWJhbmQgbWVjaGFuaXNtIGFuZCBkb2Vzbid0IG5lZWQg dG8gDQo+IGhhdmUgYSByZWxhdGlvbiB3aXRoIHRoZSBjb3VudGVyIHNpZ25lZCBlbGVtZW50IHNp Z25hdHVyZSwgZW5jcnlwdGlvbiANCj4gb3IgbWFjLCB0aGlzIHNob3VsZCBiZSBzcGVjaWZpZWQu DQoNCltKTFNdIEkgd2lsbCBzdGFydCBieSBzYXlpbmcgdGhhdCBJIGhhdmUgbmV2ZXIgbGlrZWQg dGhlIGFiYnJldmlhdGVkIGNvdW50ZXJzaWduYXR1cmUsIGJ1dCBpdCBpcyB1c2VmdWwgaW4gc29t ZSBjaXJjdW1zdGFuY2VzLiAgVGhlIGVhc2llc3QgZG9jdW1lbnQgdG8gbG9vayBhdCB3aGVyZSBi b3RoIGFuIGVuY3J5cHRpb24ga2V5IGFuZCBzaWduYXR1cmUga2V5IGFyZSBhc3NvY2lhdGVkIGRy YWZ0LWlldGYtY29yZS1vc2NvcmUtZ3JvdXBjb21tLiAgSW4gdGhpcyBjYXNlIHdoaWxlIGVhY2gg cGVyc29uIGluIHRoZSBncm91cCBoYXMgYSB1bmlxdWUga2V5LCB0aGF0IGtleSBpcyBhbHNvIGtu b3duIGJ5IGV2ZXJ5Ym9keSBlbHNlIGluIHRoZSBncm91cCBzbyB0aGF0IGtleSBjYW5ub3QgYmUg dXNlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgZGV0ZXJtaW5pbmcgd2hvIGVuY3J5cHRlZCBhbmQgc2Vu dCB0aGUgbWVzc2FnZS4gIFRoaXMgaW5mb3JtYXRpb24gaXMgYWRkZWQgYnkgdGhlIGFkZGl0aW9u IG9mIGFuIGFiYnJldmlhdGVkIGNvdW50ZXJzaWduYXR1cmUgdG8gdGhlIGVuZCBvZiB0aGUgZW5j cnlwdGVkIG1lc3NhZ2UuICBUaGlzLCBjb21iaW5lZCB3aXRoIGEgbGFyZ2UgYW1vdW50IG9mIGV4 dGVybmFsbHkgc3VwcGxpZWQgYXV0aGVudGljYXRlZCBkYXRhIHRvIGJvdGggdGhlIGVuY3J5cHRp b24gYW5kIHNpZ25hdHVyZSBwcm9jZXNzLCBhbGxvd3MgZm9yIHByb3BlciBpZGVudGlmaWNhdGlv biBvZiB0aGUgZW50aXR5IHdoaWNoIHNlbnQgdGhlIG1lc3NhZ2UuICBUaGVyZSBpcyBvbmx5IG9u ZSBzZXQgb2Yga2V5IGlkZW50aWZpY2F0aW9uIG1hdGVyaWFsIGhvd2V2ZXIgYW5kIHRoYXQgaXMg dG8gaWRlbnRpZnkgdGhlIGVuY3J5cHRpb24ga2V5IHdoaWNoIHdhcyB1c2VkLiAgVGhlIHNhbWUg aWRlbnRpZmllcnMgdXNlZCBmb3IgdGhlIGVuY3J5cHRpb24ga2V5IGNhbiB0aGVuIGJlIHVzZWQg dG8gZmlndXJlIG91dCB3aGljaCBzaWduYXR1cmUga2V5KHMpIHdvdWxkIG1ha2Ugc2Vuc2UgdG8g Y2hlY2suDQoNCltKTURdIEkgaGFkIGEgcXVpY2sgbG9vaywgZnJvbSA0LjEgaW4gZHJhZnQtaWV0 Zi1jb3JlLW9zY29yZS1ncm91cGNvbW0sIGl0IGFwcGVhcnMgdGhhdCB0aGUgZGV0ZXJtaW5hdGlv biBvZiB0aGUgY291bnRlcnNpZ25hdHVyZSBrZXkgaXMgYW4gb3V0LW9mLWJhbmQgbWVjaGFuaXNt LiBTbyBJIHdvdWxkIGFkZCB0aGUgcHJlY2lzaW9uIHRoYXQgYW4gb3V0LW9mLWJhbmQgbWVjaGFu aXNtIG9yIGEgc3RhbmRhcmRpemVkIHByb2NlZHVyZSBpcyByZXF1aXJlZCB0byBkZXRlcm1pbmUg dGhlIHNpZ25hdHVyZSBrZXkgb2YgYW4gYWJicmV2aWF0ZWQgY291bnRlcnNpZ25hdHVyZS4NCg0K W0pMU10gIEluIHRoZSBjYXNlIHRoYXQgeW91IHN1Z2dlc3RlZCBhYm92ZSwgdGhhdCBvZiBhbiBh YmJyZXZpYXRlZCBjb3VudGVyc2lnbmF0dXJlIG9uIGEgc2lnbmF0dXJlLCB3aGVuIHlvdSB3ZW50 IHRvIHJldHJpZXZlIHRoZSBrZXkgaW5mb3JtYXRpb24gb24gdGhlIHNpZ25pbmcga2V5LCBJIHdv dWxkIGV4cGVjdCB0aGF0IHlvdSB3b3VsZCBnZXQgYmFjayBhbiBhcnJheSBvZiB0d28gc2lnbmlu ZyBrZXlzLiAgVGhlIGZpcnN0IGZvciB0aGUgc2lnbmF0dXJlIGFuZCB0aGUgc2Vjb25kIGZvciB0 aGUgY291bnRlcnNpZ25hdHVyZS4gIEkgd291bGQgcmVhbGx5IHdvbmRlciBhdCBhIGNhc2Ugd2hl cmUgdGhpcyBpcyBiZWluZyBkb25lIGhvd2V2ZXIuICBXaHkgYXJlIHlvdSBzdWZmaWNpZW50bHkg d29ycmllZCBhYm91dCBzaXplIHRoYXQgeW91IGFyZSB1c2luZyBhbiBhYmJyZXZpYXRlZCBjb3Vu dGVyc2lnbmF0dXJlIGluIHRoaXMgc2l0dWF0aW9uLCBidXQgeW91IGFyZSBub3QganVzdCBnb2lu ZyB0byByZXBsYWNlIHRoZSBvcmlnaW5hbCBzaWduYXR1cmUgd2l0aCBvbmUgb2YgeW91ciBvd24u DQoNCltKTURdIE1heWJlIGEgbm90ZSB0aGF0IGFiYnJldmlhdGVkIGNvdW50ZXJzaWduYXR1cmUg b24gYSBzaWduYXR1cmUgYXJlIHRlY2huaWNhbGx5IGFsbG93ZWQsIGJ1dCBwcm9iYWJseSBkb24n dCBoYXZlIGEgdXNlZnVsIHVzZSBjYXNlIGluIHByYWN0aWNlIHdvdWxkIGJlIG5pY2UuDQpMaWtl IHRoaXMgOg0KIk5vdGUgOiBBYmJyZXZpYXRlZCBjb3VudGVyc2lnbmF0dXJlIG9uIGEgc2lnbmF0 dXJlIGFyZSB0ZWNobmljYWxseSBwb3NzaWJsZSwgYnV0IGFyZSB1bmxpa2VseSB0byBzZXJ2ZSBh IHVzZWZ1bCBwcmFjdGljYWwgcHVycG9zZS4iDQoNCj4gMikgVG8gZnVuY3Rpb24gYXMgYW4gYWN0 dWFsIGNvdW50ZXItc2lnbmF0dXJlIGZvciBzaWduYXR1cmVzLCB0aGUgc2FtZSANCj4gaXNzdWUg d2l0aCB0aGUgcGF5bG9hZCBpcyBwcmVzZW50IGFzIGZvciBmdWxsIGNvdW50ZXIgc2lnbmF0dXJl cw0KPg0KPiAzKSBUaGVyZSBpcyBubyBzYW1wbGUgb2YgYW4gYWJicmV2aWF0ZWQgY291bnRlciBz aWduYXR1cmUNCltKTFNdIEkgaGF2ZSB0aGVzZSBhbmQgY2FuIHB1dCBvbmUgb3IgdHdvIGludG8g dGhlIGFwcGVuZGl4ZXMuDQoNCg0KQnIsIA0KSmVhbi1NYXJjDQo= From nobody Mon Jul 6 12:15:31 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 5CAB23A09CF; Mon, 6 Jul 2020 12:15: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 FwCOP2-JKvO3; Mon, 6 Jul 2020 12:15: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 618AA3A09DE; Mon, 6 Jul 2020 12:15: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; Mon, 6 Jul 2020 12:15:13 -0700 From: Jim Schaad To: 'Benjamin Kaduk' , 'The IESG' CC: , , , References: <159185494077.19612.5376022702223451135@ietfa.amsl.com> In-Reply-To: <159185494077.19612.5376022702223451135@ietfa.amsl.com> Date: Mon, 6 Jul 2020 12:15:11 -0700 Message-ID: <007e01d653c9$c766bfe0$56343fa0$@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: AQK9qhuM+9aDl+pzxFUAFO2OgpmQbqcsK9TQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [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 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 19:15:25 -0000 > -----Original Message----- > From: COSE On Behalf Of Benjamin Kaduk via > Datatracker > Sent: Wednesday, June 10, 2020 10:56 PM > To: The IESG > Cc: ivaylo@ackl.io; cose-chairs@ietf.org; draft-ietf-cose-hash-algs@ietf.org; > cose@ietf.org > Subject: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-hash-algs-04: (with > DISCUSS and COMMENT) > > 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? [JLS] This was a conflict between what I "knew to be true", even though I had read the opposite several times, and what is "really true". I kept forgetting this because of the fact that I knew there was no need for HMAC to be used because the length extension attack did not exist. I have chosen to restrict to two items with fixed lengths. There was discussion on the mailing list about using a form with a length prefixed as that variant would provide the desired behavior of changing the output for every different length. In the end I decided that this was not a good way to go because I expect things such as certificate databases to be indexed by the hash value and I would not expect that the modified version of the hash function that was suggested would be the same as the version used for that index. The fact that this value may be computed externally and included from that source leads me to decide that that would not currently be wise. > > > ---------------------------------------------------------------------- > 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.) [JLS] I think the next paragraph flows out of the "additionally" bits. I think it is better to keep it. For me this reads as an additional reason for the omission, but I agree that I don't think this needs to be clearer. > > 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. [JLS] I have changed the paragraph to read 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 an identifier for 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. Rather the signature can be validated on all of the hash values and pointers to the associated contents, then those associated parts can be downloaded, the hash value of that part computed, and then compared to the hash value in the signed content. 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. An example of how this is used can be found in . The third and last sentences are new. The third sentence provides a script for how validation would be done and the last sentence points to a place where this is being done. > > 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? [JLS] s/for secure/in a secure/ > > 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"? [JLS] Done. > > 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 :) [JLS] Yes it would. > > 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". [JLS] I took part of this. > > 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"?) [JLS] Yeah, I guess it should. > > 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". [JLS] Identified as payload and switch from cannot to could have been. > > hashed be included. (Encoding as a CBOR array accomplished this > requirement.) > > nit: s/accomplished/accomplishes/ [JLS] Fixed > > 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. [JLS] What you think as the chair of the CBOR working group I should know this? > > 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. [JLS] I think I cleaned it up. > > 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"? [JLS] No - > > Because of the known issues for SHA-1 and the fact that is should no > > nit: s/is/it/ [JLS] Already fixed. > > 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. [JLS] I think it is fine. Yes the proportion is to the exponent but I think this does not need to be explicit. > > need either to analysis the potential problems with having a > > nit: s/analysis/analyze/ [JLS] Fixed. > > 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. [JLS] I changed it and dropped a note to the RFC editor. > > 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"? [JLS] Yes that makes sense. > > 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.) [JLS] > > 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. [JLS] With fixed lengths - I have changed this. > > Also, I think we should consider having some "minimum output length" > that has to be used in order to qualify for the "Recommended:Yes". [JLS] But that is now gone. > > 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"? [JLS] Yes I believe that to be true. The interesting question is when to make those jumps. I think that generally Filter Only is almost the same as deprecated for hash algorithms. > > 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. [JLS] I am not sure that this is true. All of the properties are cryptographically bound into the overall signature. So all that leaves would be to say - Do what is there and not something else - which does not really sound like a security consideration to me. > > 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. [JLS] Think it got it. > > 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) [JLS] But much easier to do a second time. > > 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. [JLS] I agree. Done. > > 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.) [JLS] Yuck - An informative reference on something we say you shouldn't do. > > 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.) [JLS] I would expect that the RFC editor would remove the paragraph because it is an instruction that does not need to be kept long term. I will so note in the xml. Jim > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon Jul 6 12:19:34 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 25DDD3A09E3; Mon, 6 Jul 2020 12:18:03 -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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <159406308307.1799.10654236604477233664@ietfa.amsl.com> Date: Mon, 06 Jul 2020 12:18:03 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-hash-algs-05.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: Mon, 06 Jul 2020 19:18:03 -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): Hash Algorithms Author : Jim Schaad Filename : draft-ietf-cose-hash-algs-05.txt Pages : 12 Date : 2020-07-06 Abstract: The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods for using hash algorithms. 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. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-hash-algs-05 https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-hash-algs-05 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 Mon Jul 6 13:36: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 59BA03A0A80 for ; Mon, 6 Jul 2020 13:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=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 nmzAjQEFufLA for ; Mon, 6 Jul 2020 13:36:45 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4b.welho.com [83.102.41.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80B43A0A7E for ; Mon, 6 Jul 2020 13:36:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id EE86F67A6E for ; Mon, 6 Jul 2020 23:36:41 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id kly6ajkmdrX8 for ; Mon, 6 Jul 2020 23:36:40 +0300 (EEST) Received: from LK-Perkele-VII (84-253-234-84.bb.dnainternet.fi [84.253.234.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id B957772 for ; Mon, 6 Jul 2020 23:36:39 +0300 (EEST) Date: Mon, 6 Jul 2020 23:36:39 +0300 From: Ilari Liusvaara To: cose@ietf.org Message-ID: <20200706203639.GA150162@LK-Perkele-VII> References: <159406308307.1799.10654236604477233664@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <159406308307.1799.10654236604477233664@ietfa.amsl.com> Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [COSE] I-D Action: draft-ietf-cose-hash-algs-05.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: Mon, 06 Jul 2020 20:36:46 -0000 On Mon, Jul 06, 2020 at 12:18:03PM -0700, internet-drafts@ietf.org wrote: > > 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): Hash Algorithms > Author : Jim Schaad > Filename : draft-ietf-cose-hash-algs-05.txt > Pages : 12 > Date : 2020-07-06 > > Abstract: > The CBOR Object Signing and Encryption (COSE) syntax > [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods > for using hash algorithms. 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. This document > defines a set of hash algorithms that are identified by COSE > Algorithm Identifiers. > > "Unlike the SHA-2 hash functions, no algorithm identifier is created > for shorter lengths. The length of the hash value stored is 128-bits > for SHAKE-128 and 256-bits for SHAKE-256." 128-bits seems rather short, given that 128-bit collisions can be generated with ~2^64 work using generic methods. And these are adverised as cryptographic hashes, not just checksums/filters. SHAKE-128 (SHAKE-256) itself maxes out at 128 (256) bit collision and preimage resistance, so to get all out of it, one needs at least 256 (512) bit output. -Ilari From nobody Mon Jul 6 14:41:41 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 D99D93A0B4B for ; Mon, 6 Jul 2020 14:41: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 EMUGHiMlG0Ph for ; Mon, 6 Jul 2020 14:41: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 E971B3A0B3E for ; Mon, 6 Jul 2020 14:41: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; Mon, 6 Jul 2020 14:41:31 -0700 From: Jim Schaad To: CC: 'Murray Kucherawy' References: <159406308341.1799.2288978635467852841@ietfa.amsl.com> In-Reply-To: <159406308341.1799.2288978635467852841@ietfa.amsl.com> Date: Mon, 6 Jul 2020 14:41:29 -0700 Message-ID: <008601d653de$371a6490$a54f2db0$@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: AQJxz/eRV5fyos8juh/Vh4qa962NxafEHFEg Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] FW: New Version Notification for draft-ietf-cose-hash-algs-05.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: Mon, 06 Jul 2020 21:41:40 -0000 I believe that I have addressed all of the concerns from the IESG in = this version of the document. Jim -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Monday, July 6, 2020 12:18 PM To: Jim Schaad Subject: New Version Notification for draft-ietf-cose-hash-algs-05.txt A new version of I-D, draft-ietf-cose-hash-algs-05.txt has been = successfully submitted by Jim Schaad and posted to the IETF repository. Name: draft-ietf-cose-hash-algs Revision: 05 Title: CBOR Object Signing and Encryption (COSE): Hash Algorithms Document date: 2020-07-06 Group: cose Pages: 12 URL: = https://www.ietf.org/internet-drafts/draft-ietf-cose-hash-algs-05.txt Status: = https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ Htmlized: https://tools.ietf.org/html/draft-ietf-cose-hash-algs-05 Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-hash-algs-05 Abstract: The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods for using hash algorithms. 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. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. = =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 Mon Jul 6 14:43:15 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 934C03A0B56 for ; Mon, 6 Jul 2020 14:43:12 -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 WLhESF72IrdL for ; Mon, 6 Jul 2020 14:43:11 -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 AEE543A0B4B for ; Mon, 6 Jul 2020 14:43:10 -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, 6 Jul 2020 14:43:03 -0700 From: Jim Schaad To: 'Ilari Liusvaara' , References: <159406308307.1799.10654236604477233664@ietfa.amsl.com> <20200706203639.GA150162@LK-Perkele-VII> In-Reply-To: <20200706203639.GA150162@LK-Perkele-VII> Date: Mon, 6 Jul 2020 14:43:01 -0700 Message-ID: <008701d653de$6dfc1350$49f439f0$@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: AQDw83eybVb0sNnjTXKrV3IBdFG3NAKZZ/HiqrEKnVA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] I-D Action: draft-ietf-cose-hash-algs-05.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: Mon, 06 Jul 2020 21:43:13 -0000 > -----Original Message----- > From: COSE On Behalf Of Ilari Liusvaara > Sent: Monday, July 6, 2020 1:37 PM > To: cose@ietf.org > Subject: Re: [COSE] I-D Action: draft-ietf-cose-hash-algs-05.txt > > On Mon, Jul 06, 2020 at 12:18:03PM -0700, internet-drafts@ietf.org wrote: > > > > 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): Hash > Algorithms > > Author : Jim Schaad > > Filename : draft-ietf-cose-hash-algs-05.txt > > Pages : 12 > > Date : 2020-07-06 > > > > Abstract: > > The CBOR Object Signing and Encryption (COSE) syntax > > [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods > > for using hash algorithms. 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. This document > > defines a set of hash algorithms that are identified by COSE > > Algorithm Identifiers. > > > > > > "Unlike the SHA-2 hash functions, no algorithm identifier is created > > for shorter lengths. The length of the hash value stored is 128-bits > > for SHAKE-128 and 256-bits for SHAKE-256." > > 128-bits seems rather short, given that 128-bit collisions can be generated with > ~2^64 work using generic methods. And these are adverised as cryptographic > hashes, not just checksums/filters. > > SHAKE-128 (SHAKE-256) itself maxes out at 128 (256) bit collision and preimage > resistance, so to get all out of it, one needs at least 256 > (512) bit output. That makes sense. Jim > > > > -Ilari > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon Jul 6 14:47: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 191EF3A0B55; Mon, 6 Jul 2020 14:47:16 -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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <159407203602.2317.5164885991537821304@ietfa.amsl.com> Date: Mon, 06 Jul 2020 14:47:16 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-hash-algs-06.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: Mon, 06 Jul 2020 21:47:16 -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): Hash Algorithms Author : Jim Schaad Filename : draft-ietf-cose-hash-algs-06.txt Pages : 12 Date : 2020-07-06 Abstract: The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods for using hash algorithms. 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. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-hash-algs-06 https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-hash-algs-06 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 Mon Jul 6 18:05:17 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 0833B3A0819 for ; Mon, 6 Jul 2020 18:05:15 -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 3Go2NTnXmKlE for ; Mon, 6 Jul 2020 18:05:13 -0700 (PDT) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 6DA913A0815 for ; Mon, 6 Jul 2020 18:05:13 -0700 (PDT) Received: by mail-vk1-xa35.google.com with SMTP id t187so772187vke.5 for ; Mon, 06 Jul 2020 18:05:13 -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=bEk4xfnGPbrTleU/royltPrWsUTdqKCVU/4u6alN4L0=; b=KcJu4VJgsKHw2Gn6Sd8ILEnWuxBoL6h1qB2H2pfNiZ+0jpGnEpdRdEAmtCWoj5QYNy wQZHQFry+tOR5fdTQnLmZPQQmM0KWCWzvpUL3SgcU4Hfn++A8WJu2RMmtcNAwgL/8hta 85hvrZHFdj5b4Ry88rpbgnx1PfxtL/L9wj/bijU/jfVyutrIzp4RMjmeE9AaH/iWN2lm 9vrdIRxhylESI2vqr+ljqKxWY9yRcpNz4xG0u/Q664OJmAOFY5TIqWKLb6lDFmLQmVI8 dm0Okfpv6t6YmJplob+3roYvjMaRQ+qUGf3M9Uk4xeUbzP6USfU6ZbCXKISYXzxEWoB8 ENzw== 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=bEk4xfnGPbrTleU/royltPrWsUTdqKCVU/4u6alN4L0=; b=WuLCc8fNLpkDHnW5OTvLIiN4DsKyXcQEd8EOQjW3i8KDkb2K5K96Ln3Lr09ai8TqAy +4HZGa7COvpel88lrE+TyxJr+Cvbu6Vzixl/fG6TGIjyOnFbshGr+4SvZswAbSQo/zeB EEXuZy96gEoNI3pS9RmBA5lxNI61iEn2XOeWrUSf3vERaniA4/yP4TM1euMKc2T+xd6o lIbl6QRiLfZ9CzzsQAWVAp8J8aGLGdnoI4ua3MXlo2WX62RQ4VPmrr9qfY8ewXYYuRYD lDAqCB/NknCTaLH1GQbjhrqQ6PrdJQpHRQ2N54hPBpbUUYV3SD0c6znka29xEXBvFIhH kWGA== X-Gm-Message-State: AOAM533iYO3BHY6pQfYE3hRlocojSplqB+BGwA5AJgSmUBwbkFeucnxo cwezUbwsxvz9Q5RAvFOwidg0g4Fqg85lnYmFptqB/Q== X-Google-Smtp-Source: ABdhPJx8YZgvRK/lvIKCZustWXqFLRFeyl1lhaRGyqkaMGX80MhFu5/+0VfyWnJfsnXzQSF9kbkT983FuKdz4JdJEWs= X-Received: by 2002:a1f:9a85:: with SMTP id c127mr34989241vke.8.1594083912417; Mon, 06 Jul 2020 18:05:12 -0700 (PDT) MIME-Version: 1.0 References: <159406308341.1799.2288978635467852841@ietfa.amsl.com> <008601d653de$371a6490$a54f2db0$@augustcellars.com> In-Reply-To: <008601d653de$371a6490$a54f2db0$@augustcellars.com> From: "Murray S. Kucherawy" Date: Mon, 6 Jul 2020 18:04:58 -0700 Message-ID: To: Jim Schaad Cc: cose@ietf.org Content-Type: multipart/alternative; boundary="00000000000057854a05a9cf950f" Archived-At: Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-hash-algs-05.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, 07 Jul 2020 01:05:15 -0000 --00000000000057854a05a9cf950f Content-Type: text/plain; charset="UTF-8" Ack, will give Benjamin a bit of time to notice and respond before I nag him. -MSK On Mon, Jul 6, 2020 at 2:41 PM Jim Schaad wrote: > I believe that I have addressed all of the concerns from the IESG in this > version of the document. > > Jim > > > -----Original Message----- > From: internet-drafts@ietf.org > Sent: Monday, July 6, 2020 12:18 PM > To: Jim Schaad > Subject: New Version Notification for draft-ietf-cose-hash-algs-05.txt > > > A new version of I-D, draft-ietf-cose-hash-algs-05.txt has been > successfully submitted by Jim Schaad and posted to the IETF repository. > > Name: draft-ietf-cose-hash-algs > Revision: 05 > Title: CBOR Object Signing and Encryption (COSE): Hash Algorithms > Document date: 2020-07-06 > Group: cose > Pages: 12 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-cose-hash-algs-05.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ > Htmlized: https://tools.ietf.org/html/draft-ietf-cose-hash-algs-05 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-hash-algs-05 > > Abstract: > The CBOR Object Signing and Encryption (COSE) syntax > [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods > for using hash algorithms. 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. This document > defines a set of hash algorithms that are identified by COSE > Algorithm Identifiers. > > > > > 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 > > > --00000000000057854a05a9cf950f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ack, will give Benjamin a bit of time to notice and r= espond before I nag him.

-MSK

<= div class=3D"gmail_quote">
On Mon, Jul= 6, 2020 at 2:41 PM Jim Schaad <ietf@augustcellars.com> wrote:
I believe that I have addressed all of the concerns= from the IESG in this version of the document.

Jim


-----Original Message-----
From: interne= t-drafts@ietf.org <internet-drafts@ietf.org>
Sent: Monday, July 6, 2020 12:18 PM
To: Jim Schaad <ietf@augustcellars.com>
Subject: New Version Notification for draft-ietf-cose-hash-algs-05.txt


A new version of I-D, draft-ietf-cose-hash-algs-05.txt has been successfull= y submitted by Jim Schaad and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-cose-hash-algs
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CBOR Object Signing and Encryption= (COSE): Hash Algorithms
Document date:=C2=A0 2020-07-06
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cose
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-cose-hash-al= gs-05.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://= tools.ietf.org/html/draft-ietf-cose-hash-algs-05
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-hash-algs-0= 5

Abstract:
=C2=A0 =C2=A0The CBOR Object Signing and Encryption (COSE) syntax
=C2=A0 =C2=A0[I-D.ietf-cose-rfc8152bis-struct] does not define any direct m= ethods
=C2=A0 =C2=A0for using hash algorithms.=C2=A0 There are, however, circumsta= nces where
=C2=A0 =C2=A0hash algorithms are used, such as indirect signatures where th= e hash
=C2=A0 =C2=A0of one or more contents are signed, and X.509 certificate or o= ther
=C2=A0 =C2=A0object identification by the use of a fingerprint.=C2=A0 This = document
=C2=A0 =C2=A0defines a set of hash algorithms that are identified by COSE =C2=A0 =C2=A0Algorithm Identifiers.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--00000000000057854a05a9cf950f-- From nobody Mon Jul 6 19:53:09 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 18B273A0963; Mon, 6 Jul 2020 19:53:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Brian Weis via Datatracker To: Cc: last-call@ietf.org, draft-ietf-cose-hash-algs.all@ietf.org, cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159409038799.11728.3735557601340694961@ietfa.amsl.com> Reply-To: Brian Weis Date: Mon, 06 Jul 2020 19:53:08 -0700 Archived-At: Subject: [COSE] Secdir last call review of draft-ietf-cose-hash-algs-06 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, 07 Jul 2020 02:53:08 -0000 Reviewer: Brian Weis Review result: Ready This is a very tardy security considerations review; many apologies to the ADs and the author. After reviewing draft-ietf-cose-hash-algs-06 I have only two minor wording suggestions, which Jim can choose to implement or not. (1) Referencing BCP 201 in the second paragraph of Section 2 was a good addition to this sentence: 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 [BCP201]. But reading the BCP does point out that perhaps the current wording is not precise. I have always considered “cryptographic advances” as the strengthening of algorithms or development of new stronger algorithms rather than increased success of attacks on algorithms. The BCP uses the wording "advances in computing power or advances in cryptoanalytic techniques” to describe this phenomenon. Maybe “cryptographic advances” could be replaced with that phrase from the BCP, or at least change “cryptographic” to “cryptanalytic”. (2) Security Considerations describes two properties of a hash function. By the time the reader gets to this section they should well understand what is collision resistance. But then second pre-image resistance is mentioned offhand without any explanation. Adding a parenthetical definition for second pre-image resistance would be helpful to the reader. For example, by adding “(i.e., where it is computationally infeasible to find any second input which has the same output as that of a specified input)” to the end of the sentence. (This text was lifted from the Wikipedia “Preimage attack” article.) From nobody Tue Jul 7 07:15: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 C0B6A3A0E04 for ; Tue, 7 Jul 2020 07:15:33 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 hdsd8mqSDLDU for ; Tue, 7 Jul 2020 07:15:30 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0793A0CF0 for ; Tue, 7 Jul 2020 07:14:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 08E4C300B5B for ; Tue, 7 Jul 2020 10:14:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fQEWVt3sSn_R for ; Tue, 7 Jul 2020 10:14:55 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 284C4300A4B; Tue, 7 Jul 2020 10:14:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <159407203602.2317.5164885991537821304@ietfa.amsl.com> Date: Tue, 7 Jul 2020 10:14:56 -0400 Cc: cose Content-Transfer-Encoding: quoted-printable Message-Id: <53ECDCF3-46A2-49BD-88B8-18E24162B8A4@vigilsec.com> References: <159407203602.2317.5164885991537821304@ietfa.amsl.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [COSE] I-D Action: draft-ietf-cose-hash-algs-06.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, 07 Jul 2020 14:15:40 -0000 Jim: The paragraph before the table needs to be updated to match the table. Russ > On Jul 6, 2020, at 5:47 PM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : CBOR Object Signing and Encryption (COSE): = Hash Algorithms > Author : Jim Schaad > Filename : draft-ietf-cose-hash-algs-06.txt > Pages : 12 > Date : 2020-07-06 >=20 > Abstract: > The CBOR Object Signing and Encryption (COSE) syntax > [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods > for using hash algorithms. 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. This document > defines a set of hash algorithms that are identified by COSE > Algorithm Identifiers. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-cose-hash-algs-06 > https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-hash-algs-06 >=20 >=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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Tue Jul 7 09:06: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 C394F3A0F3D for ; Tue, 7 Jul 2020 09:06: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 l59jzcXGH_Nu for ; Tue, 7 Jul 2020 09:06: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 D85903A0F3C for ; Tue, 7 Jul 2020 09:06: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; Tue, 7 Jul 2020 09:06:38 -0700 From: Jim Schaad To: 'Russ Housley' CC: 'cose' References: <159407203602.2317.5164885991537821304@ietfa.amsl.com> <53ECDCF3-46A2-49BD-88B8-18E24162B8A4@vigilsec.com> In-Reply-To: <53ECDCF3-46A2-49BD-88B8-18E24162B8A4@vigilsec.com> Date: Tue, 7 Jul 2020 09:06:36 -0700 Message-ID: <00ba01d65478$98cb3030$ca619090$@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: AQGjiJR8Pi2NlQVijvn/6IAMhhjhyQH8C2ZoqVH/kIA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] I-D Action: draft-ietf-cose-hash-algs-06.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, 07 Jul 2020 16:06:47 -0000 Yeah, I remembered that in the middle of the night. I'll get that up today. > -----Original Message----- > From: COSE On Behalf Of Russ Housley > Sent: Tuesday, July 7, 2020 7:15 AM > To: Jim Schaad > Cc: cose > Subject: Re: [COSE] I-D Action: draft-ietf-cose-hash-algs-06.txt > > Jim: > > The paragraph before the table needs to be updated to match the table. > > Russ > > > > On Jul 6, 2020, at 5:47 PM, internet-drafts@ietf.org wrote: > > > > > > 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): Hash > Algorithms > > Author : Jim Schaad > > Filename : draft-ietf-cose-hash-algs-06.txt > > Pages : 12 > > Date : 2020-07-06 > > > > Abstract: > > The CBOR Object Signing and Encryption (COSE) syntax > > [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods > > for using hash algorithms. 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. This document > > defines a set of hash algorithms that are identified by COSE > > Algorithm Identifiers. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-cose-hash-algs-06 > > https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs-06 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-hash-algs-06 > > > > > > 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/ > > > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Thu Jul 9 03:26:28 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 37FB33A0815; Thu, 9 Jul 2020 03:26:26 -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 mRx5K_ytCjGz; Thu, 9 Jul 2020 03:26:23 -0700 (PDT) Received: from mail-edgeDD24.fraunhofer.de (mail-edgeDD24.fraunhofer.de [192.102.167.24]) (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 A232D3A0817; Thu, 9 Jul 2020 03:26:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GODQBkpYde/xwBYJldCYQ5MWxYLzS?= =?us-ascii?q?EEZBdCJswPAoBAQEBAQEBAQEGAQEjCgIEAQECgU6CdIJJJDgTAhABAQYBAQE?= =?us-ascii?q?BAQUEAgJphVYMgnZdfgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBEgINVGoEJA8?= =?us-ascii?q?BBUEFFBwCJgJJFg0BBwEBF4MLAYJcHwEEC5M/m3mBMoRKQEGDZ4E4BoEOKow?= =?us-ascii?q?xD4FMP4ERJwwDhX8CgTmDPoJeBI43gkigEweBSXcEeASGb4VciVQjjzUFjEa?= =?us-ascii?q?YVY1HhTMCBAIJAhWBaSOBV00kT4JqTxgNiySDAgMXg1CKV4IbjRkBgQ8BAQ?= X-IPAS-Result: =?us-ascii?q?A2GODQBkpYde/xwBYJldCYQ5MWxYLzSEEZBdCJswPAoBA?= =?us-ascii?q?QEBAQEBAQEGAQEjCgIEAQECgU6CdIJJJDgTAhABAQYBAQEBAQUEAgJphVYMg?= =?us-ascii?q?nZdfgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBEgINVGoEJA8BBUEFFBwCJgJJF?= =?us-ascii?q?g0BBwEBF4MLAYJcHwEEC5M/m3mBMoRKQEGDZ4E4BoEOKowxD4FMP4ERJwwDh?= =?us-ascii?q?X8CgTmDPoJeBI43gkigEweBSXcEeASGb4VciVQjjzUFjEaYVY1HhTMCBAIJA?= =?us-ascii?q?hWBaSOBV00kT4JqTxgNiySDAgMXg1CKV4IbjRkBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.72,341,1580770800"; d="scan'208";a="32928947" Received: from mail-mtaka28.fraunhofer.de ([153.96.1.28]) by mail-edgeDD24.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2020 12:26:18 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYCgBQ8AZf/1lIDI1XCYEJgUyBczV?= =?us-ascii?q?vVzA2hCmQcpwrCwEDAQEBAQEGAQEjCgIEAQGBVoJ3ghcCJDgTAhABAQUBAQE?= =?us-ascii?q?CAQYEbYVbDEMBEAGFHAQkDwEFQQUUHAImAkkWDQEHAQEXgwsBglwgBAuPNpt?= =?us-ascii?q?6gTKET0BCg0qBOgaBDioBjG4PgUw/gREnDAOFdAKBM4NCgmAEj1eCZKIwKAe?= =?us-ascii?q?BWYEIBIEDBAuHOIYvikcFCh2RHAaOApt9jliFcgIEAgkCFYFqI4FXTSRPgmp?= =?us-ascii?q?PFwINjicDF4NOilhBaAIGAQcBAQMJfIFSjEIBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,331,1589234400"; d="scan'208";a="30419285" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA28.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jul 2020 12:26:16 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 069AQFBv018661 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Thu, 9 Jul 2020 12:26:16 +0200 Received: from [134.102.153.177] (134.102.153.177) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 9 Jul 2020 12:26:10 +0200 From: Henk Birkholz To: CC: Message-ID: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> Date: Thu, 9 Jul 2020 12:26:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [134.102.153.177] Archived-At: Subject: [COSE] Structure of CBOR certificates 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, 09 Jul 2020 10:26:26 -0000 Hi all, TL;DR moving the CBOR X.509 Profile forward + comments on native CBOR certificates After some dialog with the authors, I created a PR on a few topics we think should be discussed on-list. > https://github.com/EricssonResearch/CBOR-certificates/pull/24 Some context: The CBOR profile for X.509 certs is based on requirements coming from the (D)TLS profiles for IoT as defined in RFC7925. Section 4.4 in RFC7925 is about certificates and the most relevant part of that RFC for this work. Most of the requirements defined help to reduce the complexity of how to use X.509 pub-key identity documents. This helps with the complexity of a corresponding canonical de-composition and re-composition of "CBOR certificates" - and ultimately to safe bytes during conveyance. It is also important to highlight here that not only saving bytes is important, but also the applicability of the solution. The more certificates can be processed/compressed via the defined approach, the more it will be useful in the field. The PR highlighted above includes a proposal how a full CDDL specification can looks like. It also adds some complexity to the CBOR structure that we may or may not want. And that is what we would like to find out with the help of the list. As a result that PR is intended to be a basis for discussion. In order to kick-off the discussion, I would like to highlight a few topics we started to discuss via the PR here on the list. 1.) While the use of Subject is significantly simplified in RFC7925, the same is not true for Issuer. The PR provides an example of how to present "not-RFC7925-optimized" hierarchical names. And you can see the increased complexity quite well. String types like the options from directoryString or AI5 have to be retained in order to allow for canonical re-construction of Issuer. But maybe - effectively - strings type are used in a very deterministic manner. Would that be naive assumption? Or might it be feasible to reuse the Subject constraints from RFC7925 for Issuer? 2.) In order to steer the use algorithms, algorithm parameters can be included next to the algorithm identifiers. If they are included in a certificate, these have to be represented in this profile, too. Or can assumption be made that they are not used or somehow deterministic? If in doubt, the small amount of complexity as found in the CDDL might be warranted. In the end, it would be unfortunate to exclude a subset of certs, because they include alg parameters. 3.) How relevant is the inclusion of generic extensions via oid for the application of the CBOR profile for X.509? The PR includes a relative straight forward approach how to map oid, but is that necessary? Is it safe to assume that there will be a core set of extensions that warrants a mapping to a set of integers that would significantly reduce the size of a CBOR cert? These are three prominent topics today and there will be other. I hope to get feedback on the topics elaborated on here and of course the PR. The diff for the PR to see the changes side by side can be found here: > https://github.com/EricssonResearch/CBOR-certificates/pull/24/files Looking at the current and proposed CDDL structure, I'd like to note as a separate topic that with only a few minimal tweaks to the current specification it already resembles a solution viable for native CBOR certificates, too. The only effective difference is the scope of the signature, which would not require a dual stack implementation on constrained devices (that sometimes might want to check a signature). In general, native CBOR certificates would be quite useful in applications, such as SUIT Workflow Models, trustworthy time synchronization in swarms of things, lightweight remote-attestation, Concise Software Identities or the emerging SBOM efforts of NTIA/CICP. If you think of the IoT as an initial scope, there is also no pressing need for public CAs to embrace a native format ad-hoc. Viele Grüße, Henk From nobody Thu Jul 9 13:02: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 F3D263A043D; Thu, 9 Jul 2020 13:02:31 -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 nfwgQ7l9udPD; Thu, 9 Jul 2020 13:02:29 -0700 (PDT) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 46D013A040F; Thu, 9 Jul 2020 13:02:29 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id a6so3659161wrm.4; Thu, 09 Jul 2020 13:02:29 -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=VPQG8mlUcGkLcYoZquaefhTgPRi4mY6XXU3KIajjND0=; b=Sb5i4WWPhT+VubblYFabKzknZydgUTAdexv13gHZF6DhkgxKPN62fVUhwGVTJTnu7p 0VqYG/ya400nTOYNYw9kRyB78UUsrvyumY6lU6N1FVigTBsmAcvmsr1nnSvMUDGIwD14 c2p0iVhbt1OvV8+f3DX0nifVS48seOLI3lLJ3ESL+jSYg237F6e5SFbXo/YyIKlUL8S6 faLwnYZ0oHC9XiYGveV05AHzqjTKcPnhmz2Yweq6aQrXKTO7Ygrp436EbODVNt4B48J6 +kZQCsmKXUrnR0bdMAxDS5WMTZnB51M52go/LtJjn2wI6K1xp+xVIKYc4RFVHyKvNXk1 zqCg== 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=VPQG8mlUcGkLcYoZquaefhTgPRi4mY6XXU3KIajjND0=; b=Yp7GqkHwco9LpA0IbqDpLMz45Mqx97NGp3v2hD83oui9uT1dBG6Z+qIICac0t6TwUF PNTJE6QnTIsXDgc00Iw85NGVNBf6ZkeyGhc3Zei2ErPFZp7dchVNlYAbquWq7/4xv0LC qGgrc2Gc6GnOL5pzPVaoyRmaCu60LWdiZS7JgDXXxVryik3IbeiOyoiBXb2vtvN4KZ2Y AFRjH+DQY21eKYDlNKfjmjlTV7d8eg9NToRK6wH67nd/IScwvK+8OzF6MXndJwJ1qOlt qtA6CIxa/ZyOhjlq/Py28vOAUF5pJaahnut7/aMOojHAyVSFoePKE/jRgbdbvXpi9Xn5 Kqfw== X-Gm-Message-State: AOAM5329PQPHs9UgQsDcBhEdrM+c/cbvx4GgF4Fa5RHdwKfjsJXaOQVw 2XoQe7ijpCj4kDJF7bFM9DE554O96A6xVBaqtsXMjDkUsKE= X-Google-Smtp-Source: ABdhPJxVrwEoFBIPM2RlhQnEtCnoWPZoRkV1XsAQ17xv1yn9+mS7Ql9SfDnMux/4CjgbQTymhQspEjNNdL0KJyAeDnM= X-Received: by 2002:adf:e901:: with SMTP id f1mr64978206wrm.80.1594324947152; Thu, 09 Jul 2020 13:02:27 -0700 (PDT) MIME-Version: 1.0 References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> In-Reply-To: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> From: =?UTF-8?Q?Joel_H=C3=B6glund?= Date: Thu, 9 Jul 2020 22:02:15 +0200 Message-ID: To: cose@ietf.org Cc: draft-raza-ace-cbor-certificates@ietf.org Content-Type: multipart/alternative; boundary="00000000000021b82705aa07b4f4" Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 09 Jul 2020 20:02:32 -0000 --00000000000021b82705aa07b4f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Henk and all! Thank you for your comments and update proposals! In brief, there is definitely a need to clarify the assumptions about existing x509 data structures we want to encode, and probably in some cases make the proposal more general to allow more valid rfc7925 certificates. Some further comments to the highlighted issues follows. 1. About Issuer-field encodings: We would like to have more discussions on if for instance your directoryString proposal is necessary, or if the string types can be assumed -- hopefully with input from others with experience of how Issuer-fields normally are encoded. 2. About algorithm parameters: Our current assumption is that for our target certificates, all needed algorithm info can be represented using only the subjectPublicKeyInfo_algorithm field. 3. About a general extension oid-mapping: We believe the four extensions mandated by rfc7925 should suffice, but are open for hearing about IoT requirements that go beyond those four. Looking forward to further discussions, and Best Regards Joel H=C3=B6glund On Thu, 9 Jul 2020 at 12:26, Henk Birkholz wrote: > Hi all, > > TL;DR moving the CBOR X.509 Profile forward + comments on native CBOR > certificates > > > After some dialog with the authors, I created a PR on a few topics we > think should be discussed on-list. > > > https://github.com/EricssonResearch/CBOR-certificates/pull/24 > > Some context: The CBOR profile for X.509 certs is based on requirements > coming from the (D)TLS profiles for IoT as defined in RFC7925. > > Section 4.4 in RFC7925 is about certificates and the most relevant part > of that RFC for this work. Most of the requirements defined help to > reduce the complexity of how to use X.509 pub-key identity documents. > This helps with the complexity of a corresponding canonical > de-composition and re-composition of "CBOR certificates" - and > ultimately to safe bytes during conveyance. It is also important to > highlight here that not only saving bytes is important, but also the > applicability of the solution. The more certificates can be > processed/compressed via the defined approach, the more it will be > useful in the field. > > The PR highlighted above includes a proposal how a full CDDL > specification can looks like. It also adds some complexity to the CBOR > structure that we may or may not want. And that is what we would like > to find out with the help of the list. As a result that PR is intended > to be a basis for discussion. > > In order to kick-off the discussion, I would like to highlight a few > topics we started to discuss via the PR here on the list. > > 1.) While the use of Subject is significantly simplified in RFC7925, the > same is not true for Issuer. The PR provides an example of how to > present "not-RFC7925-optimized" hierarchical names. And you can see the > increased complexity quite well. String types like the options from > directoryString or AI5 have to be retained in order to allow for > canonical re-construction of Issuer. But maybe - effectively - strings > type are used in a very deterministic manner. Would that be naive > assumption? Or might it be feasible to reuse the Subject constraints > from RFC7925 for Issuer? > > 2.) In order to steer the use algorithms, algorithm parameters can be > included next to the algorithm identifiers. If they are included in a > certificate, these have to be represented in this profile, too. Or can > assumption be made that they are not used or somehow deterministic? If > in doubt, the small amount of complexity as found in the CDDL might be > warranted. In the end, it would be unfortunate to exclude a subset of > certs, because they include alg parameters. > > 3.) How relevant is the inclusion of generic extensions via oid for the > application of the CBOR profile for X.509? The PR includes a relative > straight forward approach how to map oid, but is that necessary? Is it > safe to assume that there will be a core set of extensions that warrants > a mapping to a set of integers that would significantly reduce the size > of a CBOR cert? > > These are three prominent topics today and there will be other. I hope > to get feedback on the topics elaborated on here and of course the PR. > The diff for the PR to see the changes side by side can be found here: > > > https://github.com/EricssonResearch/CBOR-certificates/pull/24/files > > > Looking at the current and proposed CDDL structure, I'd like to note as > a separate topic that with only a few minimal tweaks to the current > specification it already resembles a solution viable for native CBOR > certificates, too. The only effective difference is the scope of the > signature, which would not require a dual stack implementation on > constrained devices (that sometimes might want to check a signature). > > In general, native CBOR certificates would be quite useful in > applications, such as SUIT Workflow Models, trustworthy time > synchronization in swarms of things, lightweight remote-attestation, > Concise Software Identities or the emerging SBOM efforts of NTIA/CICP. > If you think of the IoT as an initial scope, there is also no pressing > need for public CAs to embrace a native format ad-hoc. > > Viele Gr=C3=BC=C3=9Fe, > > Henk > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --00000000000021b82705aa07b4f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= Hi Henk and all!


Thank = you for your comments and update proposals!=C2=A0=C2=A0


In brief, there is definitely a need to clarify the assumptions abou= t existing x509 data structures we want to encode, and probably in some cas= es make the proposal more general to allow more valid rfc7925 certificates.= Some further comments to the highlighted issues follows.


1. About Issuer-field encodings: We woul= d like to have more discussions on if for instance your directoryString pro= posal is necessary, or if the string types can be assumed -- hopefully with= input from others with experience of how Issuer-fields normally are encode= d.=C2=A0


2. About algor= ithm parameters: Our current assumption is that for our target certificates= , all needed algorithm info can be represented using only the subjectPublic= KeyInfo_algorithm field.


3. About a general extension oid-mapping: We believe the four extensions = mandated by rfc7925 should suffice, but are open for hearing about IoT requ= irements that go beyond those four.


Looking forward to further discussions, and


Best Regards


Joel H=C3=B6glund




On Thu, 9 Jul 2020 at 12:26, Henk Birkholz <henk.birkholz@sit.fraunhofer.de&= gt; wrote:
Hi al= l,

TL;DR moving the CBOR X.509 Profile forward + comments on native CBOR
certificates


After some dialog with the authors, I created a PR on a few topics we
think should be discussed on-list.

> https://github.com/EricssonResearc= h/CBOR-certificates/pull/24

Some context: The CBOR profile for X.509 certs is based on requirements coming from the (D)TLS profiles for IoT as defined in RFC7925.

Section 4.4 in RFC7925 is about certificates and the most relevant part of that RFC for this work.=C2=A0 Most of the requirements defined help to <= br> reduce the complexity of how to use X.509 pub-key identity documents.
This helps with the complexity of a corresponding canonical
de-composition and re-composition of "CBOR certificates" - and ultimately to safe bytes during conveyance.=C2=A0 It is also important to <= br> highlight here that not only saving bytes is important, but also the
applicability of the solution.=C2=A0 The more certificates can be
processed/compressed via the defined approach, the more it will be
useful in the field.

The PR highlighted above includes a proposal how a full CDDL
specification can looks like.=C2=A0 It also adds some complexity to the CBO= R
structure that we may or may not want.=C2=A0 And that is what we would like=
to find out with the help of the list.=C2=A0 As a result that PR is intende= d
to be a basis for discussion.

In order to kick-off the discussion, I would like to highlight a few
topics we started to discuss via the PR here on the list.

1.) While the use of Subject is significantly simplified in RFC7925, the same is not true for Issuer.=C2=A0 The PR provides an example of how to present "not-RFC7925-optimized" hierarchical names.=C2=A0 And you= can see the
increased complexity quite well.=C2=A0 String types like the options from <= br> directoryString or AI5 have to be retained in order to allow for
canonical re-construction of Issuer.=C2=A0 But maybe - effectively - string= s
type are used in a very deterministic manner.=C2=A0 Would that be naive assumption?=C2=A0 Or might it be feasible to reuse the Subject constraints =
from RFC7925 for Issuer?

2.) In order to steer the use algorithms, algorithm parameters can be
included next to the algorithm identifiers.=C2=A0 If they are included in a=
certificate, these have to be represented in this profile, too.=C2=A0 Or ca= n
assumption be made that they are not used or somehow deterministic?=C2=A0 I= f
in doubt, the small amount of complexity as found in the CDDL might be
warranted.=C2=A0 In the end, it would be unfortunate to exclude a subset of=
certs, because they include alg parameters.

3.) How relevant is the inclusion of generic extensions via oid for the application of the CBOR profile for X.509?=C2=A0 The PR includes a relative=
straight forward approach how to map oid, but is that necessary?=C2=A0 Is i= t
safe to assume that there will be a core set of extensions that warrants a mapping to a set of integers that would significantly reduce the size of a CBOR cert?

These are three prominent topics today and there will be other.=C2=A0 I hop= e
to get feedback on the topics elaborated on here and of course the PR.
The diff for the PR to see the changes side by side can be found here:

> https://github.com/EricssonR= esearch/CBOR-certificates/pull/24/files


Looking at the current and proposed CDDL structure, I'd like to note as=
=C2=A0 =C2=A0 a separate topic that with only a few minimal tweaks to the c= urrent
specification it already resembles a solution viable for native CBOR
certificates, too. The only effective difference is the scope of the
signature, which would not require a dual stack implementation on
constrained devices (that sometimes might want to check a signature).

In general, native CBOR certificates would be quite useful in
applications, such as SUIT Workflow Models, trustworthy time
synchronization in swarms of things, lightweight remote-attestation,
Concise Software Identities or the emerging SBOM efforts of NTIA/CICP.
If you think of the IoT as an initial scope, there is also no pressing
need for public CAs to embrace a native format ad-hoc.

Viele Gr=C3=BC=C3=9Fe,

Henk

_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose
--00000000000021b82705aa07b4f4-- From nobody Fri Jul 10 03:08:15 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 ED0893A07C3 for ; Fri, 10 Jul 2020 03:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RCVD_IN_MSPIKE_H2=-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=ericsson.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 4VGxRS3zjChG for ; Fri, 10 Jul 2020 03:08:10 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140088.outbound.protection.outlook.com [40.107.14.88]) (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 A1A7C3A07C5 for ; Fri, 10 Jul 2020 03:08:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=clCHhN7J5ZfQ93+Vya+zUzd8bcItH3tsg8kkDReHUulb4AXR6aORTo7DSTk3F1Moz9q86821D25JLm8PDTJQM/lKYcUS4nzuWa1eM/9uPY6rVje6Q6gXV06+RaPCo2AH+P8qiu42kKWC8wTZhINT0b89QGHWUT8va4t698rWo0Z2hi2n1Jor48ry5S4FpFbsooEVV/sv7TGaZuNzZ7KMtltOxvTEaJVtDVB29leePkvuoQcx01bufLpXmn6hhHqpG7cnA26NWVJp7xbuFXBcWtGffcpCYD0/A+Hp5MENWD4kFyO6v/rWViA0AOIt0EFegZOucMC4OrOy5waztQCWhQ== 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=k8HdiyEsAR0xk4TzOd1MJ0MlfXOo402SBnHNDUSBglE=; b=OTNHbDGCqtYxfDhRQhcjjmrzzpfkaQFtery/hiIq7SG+TFcXqoe93pwQNnEo4dzbRjuaiOLHGe4lf8AcTdk5vjU7MbP5rwVMaeACEHqL6S/aB7UM/Iqe9jjUfx34cxC7BunmYcQ8Yotbrjh756d4uNwkazcQaK3+Zfw0D3g8K/GJQBRZkQqOTbN3MTiqrxPdFK0Qd2/6kswO1vxz0Y4s2Yn4EYNpEzS7REFx9zxWZKNZAnbAnugtsxdCakVcSHdM9gfDPcQUrl/z8/2Ym2zMP9wIHOk+ZIV+oVZ+TQM9//rHPNDc9qcp8RFeQRlc3GzG5tNSuksVCPN4q+e0OFyHdA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k8HdiyEsAR0xk4TzOd1MJ0MlfXOo402SBnHNDUSBglE=; b=KYRAyM1AhPiemo6PGfv+F+7CMgUoJOpMvJcDpFiF2jfSO8XXXuIHe5ky+HepZ0569idh0pgM8OadPxzHMQGM9bxhGb1aOijmOMzUrGU0CL84ae1w3a3M4KliOQwyERXZSezUi+rhLVqANDpfVucupi54LIlB9at5biIeAB0niq4= Received: from AM0PR0702MB3665.eurprd07.prod.outlook.com (2603:10a6:208:1e::21) by AM4PR0701MB2164.eurprd07.prod.outlook.com (2603:10a6:200:4a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.9; Fri, 10 Jul 2020 10:08:06 +0000 Received: from AM0PR0702MB3665.eurprd07.prod.outlook.com ([fe80::75ea:232a:4132:452e]) by AM0PR0702MB3665.eurprd07.prod.outlook.com ([fe80::75ea:232a:4132:452e%4]) with mapi id 15.20.3195.009; Fri, 10 Jul 2020 10:08:06 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Henk Birkholz , "cose@ietf.org" Thread-Topic: [COSE] Structure of CBOR certificates Thread-Index: AQHWVdtqmNOSgAbKkUeKPEjyndKwSqj/q/eAgAEN2oA= Date: Fri, 10 Jul 2020 10:08:06 +0000 Message-ID: <3BB91C08-EA7E-4388-8CB9-78275E1CBDF4@ericsson.com> References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 authentication-results: sit.fraunhofer.de; dkim=none (message not signed) header.d=none;sit.fraunhofer.de; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [83.251.145.232] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a2839791-487c-4fc5-5930-08d824b92418 x-ms-traffictypediagnostic: AM4PR0701MB2164: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dCzm9EPoKVhOGoiWXkGCEycmPQdrP/1NlwzQBcKeqG/iz7cG5MeGD3qmqKH4qIvAZRuk1uyh4wyn3sUfGHBoZZgmr/2jtmjym4ws1rmufwm+3c8eyPXYG3J/4O7SO9OB5R0lyeHXSVbudBBIkHSCia1lsvFcyj30Th3yRAMM9pDIC18qmlkVbPNb0CIc5W3VEfGNooFxJ71hBL+R7UOaPjbDtBwLEKuCDsLtHaDKZpJjx6+0jc6iviyT1WEiTDWEUFTEQgT0aIZZN2SX6VV7PAuYi2/uA9kyHXJvk8A8V5I6/QJgbkEMSgSHo+14V85PEip4YiTw/+Z7Yq1rBvNmydicxCttIXWY/2ZbwXsbShk7O939Yv9o2Sq3zv/82J8lBSzn/C8HYgm49Ue7apda7Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0702MB3665.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(346002)(366004)(39860400002)(136003)(2906002)(83380400001)(66574015)(2616005)(316002)(110136005)(6512007)(85202003)(64756008)(66476007)(86362001)(66946007)(5660300002)(71200400001)(66556008)(85182001)(8936002)(8676002)(33656002)(66446008)(91956017)(6486002)(36756003)(76116006)(53546011)(6506007)(166002)(186003)(26005)(966005)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: y3yKNacciCWpV1TqIjEE5nGRFvBR3DJH9ZtCbpxz0rqEPpfz6pW7GwbUSLfVlVdhSMtqkYP+2//t2R+XAl+HqEZ2XjuSUkeF/shxLjxubpY84g8hZZw25w6EvlinwMdhRP3oIWsmqq1CVptCyRsrEg3PyzLhPNhQApzoxq7lhRWNc9lsvWuAZidwbVby5o0vC1SEbMV5h4J0eIqhBugdgRvgS1gajmdEZznUmq3BtGOhouMEYYPZcS5Me51ewTR4yHa+yttFffCv+/pg5u41JGNoZzd5JK92vrs/qZ+0LYwcR7q66GAZOviJWRKKB28baNgQ04LGyxQ9ga8n7xr6kvcvIhlencIcjms/i/NXaETxn67veZSsSkP/w7wgLv+D3EMESgqsznGhrYY3ZIJnlZV4T0NtnNieunAdszug/0eQrsajjq6pcSZETf8s4/7xgtAZPUnGlas6Op61/KK1bQToYdJh9dDWpT/NfuB09jggluYmBKvbtgKVZupopNOg x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3BB91C08EA7E43888CB978275E1CBDF4ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR0702MB3665.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a2839791-487c-4fc5-5930-08d824b92418 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2020 10:08:06.3971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: o2YNchcDP6p41k/34YMIg8d8xUDlJi9yCXqv8FpbD+P4E+TElqpE/9dW6MuE5PpNU3SOeXycERgyXy5rI/dmFkEW+HDnZZMunMBnCSNoDek= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0701MB2164 Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 10 Jul 2020 10:08:13 -0000 --_000_3BB91C08EA7E43888CB978275E1CBDF4ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGVuaywNCg0KVGhhbmtzIGZvciB0aGUgaW5wdXQuIEdyZWF0IHRvIGFsc28gc2VlIHlvdXIg bm90ZSBhYm91dCB1c2VmdWxuZXNzIG9mIG5hdGl2ZSBDQk9SIGNlcnRpZmljYXRlcyEgVGhpcyBh ZGRzIHRvIExhdXJlbmNlIHByZXZpb3VzIGNvbW1lbnRzIG9uIHRoZSBsaXN0Lg0KDQpGb3IgeW91 ciBpbmZvcm1hdGlvbiwgd2UgYXJlIG5vdyB3b3JraW5nIG9uIGEgbWVyZ2Ugb2YgdGhlIGZvbGxv d2luZyBkcmFmdHM6DQoNCmRyYWZ0LXJhemEtYWNlLWNib3ItY2VydGlmaWNhdGVzDQpkcmFmdC1t YXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNvbXByZXNzDQpkcmFmdC1tYXR0c3Nvbi1jb3NlLWNib3It Y2VydC1jb21wcmVzcw0KDQpUaGUgdW5pb24gb2YgdGhlIGNvbnRlbnRzIHdpbGwgYmVjb21lIGEg bmV3IHZlcnNpb24gb2YgZHJhZnQtbWF0dHNzb24tY29zZS1jYm9yLWNlcnQtY29tcHJlc3MgKGJl aW5nIHRoZSBkcmFmdCBoYXZpbmcgdGhlIHJpZ2h0IFdHIGRlc2lnbmF0aW9uKS4gV2Ugd2lsbCBu b3QgYmUgYWJsZSB0byB0YWtlIHlvdXIgY29tbWVudHMgaW50byBhY2NvdW50IGJlZm9yZSB0aGUg Y3V0b2ZmIG9uIHRoZSAxM3RoLCBidXQgdGhpcyBpcyBleGNlbGxlbnQgaW5wdXQgZm9yIGRpc2N1 c3Npb24gYmVmb3JlIGFuZCBhdCB0aGUgIUVURiAxMDggV0cgbWVldGluZy4NCg0KVGhhbmtzDQpH w7ZyYW4NCg0KDQpGcm9tOiBKb2VsIEjDtmdsdW5kIDxqb2VsLmhvZ2x1bmRAZ21haWwuY29tPg0K RGF0ZTogVGh1cnNkYXksIDkgSnVseSAyMDIwIGF0IDIyOjAyDQpUbzogImNvc2VAaWV0Zi5vcmci IDxjb3NlQGlldGYub3JnPg0KQ2M6ICJkcmFmdC1yYXphLWFjZS1jYm9yLWNlcnRpZmljYXRlc0Bp ZXRmLm9yZyIgPGRyYWZ0LXJhemEtYWNlLWNib3ItY2VydGlmaWNhdGVzQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtDT1NFXSBTdHJ1Y3R1cmUgb2YgQ0JPUiBjZXJ0aWZpY2F0ZXMNClJlc2VudCBm cm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4NClJlc2VudCB0bzogPHNoYWhpZC5yYXphQHJp LnNlPiwgPGpvZWwuaG9nbHVuZEByaS5zZT4sIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+ LCBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4sIDxtYXJ0aW4uZnVy dWhlZEBuZXh1c2dyb3VwLmNvbT4NClJlc2VudCBkYXRlOiBUaHVyc2RheSwgOSBKdWx5IDIwMjAg YXQgMjI6MDINCg0KDQpIaSBIZW5rIGFuZCBhbGwhDQoNCg0KVGhhbmsgeW91IGZvciB5b3VyIGNv bW1lbnRzIGFuZCB1cGRhdGUgcHJvcG9zYWxzIQ0KDQoNCg0KSW4gYnJpZWYsIHRoZXJlIGlzIGRl ZmluaXRlbHkgYSBuZWVkIHRvIGNsYXJpZnkgdGhlIGFzc3VtcHRpb25zIGFib3V0IGV4aXN0aW5n IHg1MDkgZGF0YSBzdHJ1Y3R1cmVzIHdlIHdhbnQgdG8gZW5jb2RlLCBhbmQgcHJvYmFibHkgaW4g c29tZSBjYXNlcyBtYWtlIHRoZSBwcm9wb3NhbCBtb3JlIGdlbmVyYWwgdG8gYWxsb3cgbW9yZSB2 YWxpZCByZmM3OTI1IGNlcnRpZmljYXRlcy4gU29tZSBmdXJ0aGVyIGNvbW1lbnRzIHRvIHRoZSBo aWdobGlnaHRlZCBpc3N1ZXMgZm9sbG93cy4NCg0KDQoxLiBBYm91dCBJc3N1ZXItZmllbGQgZW5j b2RpbmdzOiBXZSB3b3VsZCBsaWtlIHRvIGhhdmUgbW9yZSBkaXNjdXNzaW9ucyBvbiBpZiBmb3Ig aW5zdGFuY2UgeW91ciBkaXJlY3RvcnlTdHJpbmcgcHJvcG9zYWwgaXMgbmVjZXNzYXJ5LCBvciBp ZiB0aGUgc3RyaW5nIHR5cGVzIGNhbiBiZSBhc3N1bWVkIC0tIGhvcGVmdWxseSB3aXRoIGlucHV0 IGZyb20gb3RoZXJzIHdpdGggZXhwZXJpZW5jZSBvZiBob3cgSXNzdWVyLWZpZWxkcyBub3JtYWxs eSBhcmUgZW5jb2RlZC4NCg0KDQoyLiBBYm91dCBhbGdvcml0aG0gcGFyYW1ldGVyczogT3VyIGN1 cnJlbnQgYXNzdW1wdGlvbiBpcyB0aGF0IGZvciBvdXIgdGFyZ2V0IGNlcnRpZmljYXRlcywgYWxs IG5lZWRlZCBhbGdvcml0aG0gaW5mbyBjYW4gYmUgcmVwcmVzZW50ZWQgdXNpbmcgb25seSB0aGUg c3ViamVjdFB1YmxpY0tleUluZm9fYWxnb3JpdGhtIGZpZWxkLg0KDQoNCjMuIEFib3V0IGEgZ2Vu ZXJhbCBleHRlbnNpb24gb2lkLW1hcHBpbmc6IFdlIGJlbGlldmUgdGhlIGZvdXIgZXh0ZW5zaW9u cyBtYW5kYXRlZCBieSByZmM3OTI1IHNob3VsZCBzdWZmaWNlLCBidXQgYXJlIG9wZW4gZm9yIGhl YXJpbmcgYWJvdXQgSW9UIHJlcXVpcmVtZW50cyB0aGF0IGdvIGJleW9uZCB0aG9zZSBmb3VyLg0K DQoNCkxvb2tpbmcgZm9yd2FyZCB0byBmdXJ0aGVyIGRpc2N1c3Npb25zLCBhbmQNCg0KDQpCZXN0 IFJlZ2FyZHMNCg0KDQpKb2VsIEjDtmdsdW5kDQoNCg0KDQoNCg0KT24gVGh1LCA5IEp1bCAyMDIw IGF0IDEyOjI2LCBIZW5rIEJpcmtob2x6IDxoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRl PG1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPj4gd3JvdGU6DQpIaSBhbGws DQoNClRMO0RSIG1vdmluZyB0aGUgQ0JPUiBYLjUwOSBQcm9maWxlIGZvcndhcmQgKyBjb21tZW50 cyBvbiBuYXRpdmUgQ0JPUg0KY2VydGlmaWNhdGVzDQoNCg0KQWZ0ZXIgc29tZSBkaWFsb2cgd2l0 aCB0aGUgYXV0aG9ycywgSSBjcmVhdGVkIGEgUFIgb24gYSBmZXcgdG9waWNzIHdlDQp0aGluayBz aG91bGQgYmUgZGlzY3Vzc2VkIG9uLWxpc3QuDQoNCj4gaHR0cHM6Ly9naXRodWIuY29tL0VyaWNz c29uUmVzZWFyY2gvQ0JPUi1jZXJ0aWZpY2F0ZXMvcHVsbC8yNDxodHRwczovL3Byb3RlY3QyLmZp cmVleWUuY29tL3YxL3VybD9rPTU1OTQ4ZTQ2LTBiMzQ2ZWQ4LTU1OTRjZWRkLTg2ZWU4NmJkNTEw Ny1mYWY2ZTYwMmY4YTE3NGRkJnE9MSZlPTRiMjkyYmFlLTQ5NjItNGE4Ni05ZGUwLTBjMDEyN2U3 NDFmZSZ1PWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRkVyaWNzc29uUmVzZWFyY2glMkZDQk9S LWNlcnRpZmljYXRlcyUyRnB1bGwlMkYyND4NCg0KU29tZSBjb250ZXh0OiBUaGUgQ0JPUiBwcm9m aWxlIGZvciBYLjUwOSBjZXJ0cyBpcyBiYXNlZCBvbiByZXF1aXJlbWVudHMNCmNvbWluZyBmcm9t IHRoZSAoRClUTFMgcHJvZmlsZXMgZm9yIElvVCBhcyBkZWZpbmVkIGluIFJGQzc5MjUuDQoNClNl Y3Rpb24gNC40IGluIFJGQzc5MjUgaXMgYWJvdXQgY2VydGlmaWNhdGVzIGFuZCB0aGUgbW9zdCBy ZWxldmFudCBwYXJ0DQpvZiB0aGF0IFJGQyBmb3IgdGhpcyB3b3JrLiAgTW9zdCBvZiB0aGUgcmVx dWlyZW1lbnRzIGRlZmluZWQgaGVscCB0bw0KcmVkdWNlIHRoZSBjb21wbGV4aXR5IG9mIGhvdyB0 byB1c2UgWC41MDkgcHViLWtleSBpZGVudGl0eSBkb2N1bWVudHMuDQpUaGlzIGhlbHBzIHdpdGgg dGhlIGNvbXBsZXhpdHkgb2YgYSBjb3JyZXNwb25kaW5nIGNhbm9uaWNhbA0KZGUtY29tcG9zaXRp b24gYW5kIHJlLWNvbXBvc2l0aW9uIG9mICJDQk9SIGNlcnRpZmljYXRlcyIgLSBhbmQNCnVsdGlt YXRlbHkgdG8gc2FmZSBieXRlcyBkdXJpbmcgY29udmV5YW5jZS4gIEl0IGlzIGFsc28gaW1wb3J0 YW50IHRvDQpoaWdobGlnaHQgaGVyZSB0aGF0IG5vdCBvbmx5IHNhdmluZyBieXRlcyBpcyBpbXBv cnRhbnQsIGJ1dCBhbHNvIHRoZQ0KYXBwbGljYWJpbGl0eSBvZiB0aGUgc29sdXRpb24uICBUaGUg bW9yZSBjZXJ0aWZpY2F0ZXMgY2FuIGJlDQpwcm9jZXNzZWQvY29tcHJlc3NlZCB2aWEgdGhlIGRl ZmluZWQgYXBwcm9hY2gsIHRoZSBtb3JlIGl0IHdpbGwgYmUNCnVzZWZ1bCBpbiB0aGUgZmllbGQu DQoNClRoZSBQUiBoaWdobGlnaHRlZCBhYm92ZSBpbmNsdWRlcyBhIHByb3Bvc2FsIGhvdyBhIGZ1 bGwgQ0RETA0Kc3BlY2lmaWNhdGlvbiBjYW4gbG9va3MgbGlrZS4gIEl0IGFsc28gYWRkcyBzb21l IGNvbXBsZXhpdHkgdG8gdGhlIENCT1INCnN0cnVjdHVyZSB0aGF0IHdlIG1heSBvciBtYXkgbm90 IHdhbnQuICBBbmQgdGhhdCBpcyB3aGF0IHdlIHdvdWxkIGxpa2UNCnRvIGZpbmQgb3V0IHdpdGgg dGhlIGhlbHAgb2YgdGhlIGxpc3QuICBBcyBhIHJlc3VsdCB0aGF0IFBSIGlzIGludGVuZGVkDQp0 byBiZSBhIGJhc2lzIGZvciBkaXNjdXNzaW9uLg0KDQpJbiBvcmRlciB0byBraWNrLW9mZiB0aGUg ZGlzY3Vzc2lvbiwgSSB3b3VsZCBsaWtlIHRvIGhpZ2hsaWdodCBhIGZldw0KdG9waWNzIHdlIHN0 YXJ0ZWQgdG8gZGlzY3VzcyB2aWEgdGhlIFBSIGhlcmUgb24gdGhlIGxpc3QuDQoNCjEuKSBXaGls ZSB0aGUgdXNlIG9mIFN1YmplY3QgaXMgc2lnbmlmaWNhbnRseSBzaW1wbGlmaWVkIGluIFJGQzc5 MjUsIHRoZQ0Kc2FtZSBpcyBub3QgdHJ1ZSBmb3IgSXNzdWVyLiAgVGhlIFBSIHByb3ZpZGVzIGFu IGV4YW1wbGUgb2YgaG93IHRvDQpwcmVzZW50ICJub3QtUkZDNzkyNS1vcHRpbWl6ZWQiIGhpZXJh cmNoaWNhbCBuYW1lcy4gIEFuZCB5b3UgY2FuIHNlZSB0aGUNCmluY3JlYXNlZCBjb21wbGV4aXR5 IHF1aXRlIHdlbGwuICBTdHJpbmcgdHlwZXMgbGlrZSB0aGUgb3B0aW9ucyBmcm9tDQpkaXJlY3Rv cnlTdHJpbmcgb3IgQUk1IGhhdmUgdG8gYmUgcmV0YWluZWQgaW4gb3JkZXIgdG8gYWxsb3cgZm9y DQpjYW5vbmljYWwgcmUtY29uc3RydWN0aW9uIG9mIElzc3Vlci4gIEJ1dCBtYXliZSAtIGVmZmVj dGl2ZWx5IC0gc3RyaW5ncw0KdHlwZSBhcmUgdXNlZCBpbiBhIHZlcnkgZGV0ZXJtaW5pc3RpYyBt YW5uZXIuICBXb3VsZCB0aGF0IGJlIG5haXZlDQphc3N1bXB0aW9uPyAgT3IgbWlnaHQgaXQgYmUg ZmVhc2libGUgdG8gcmV1c2UgdGhlIFN1YmplY3QgY29uc3RyYWludHMNCmZyb20gUkZDNzkyNSBm b3IgSXNzdWVyPw0KDQoyLikgSW4gb3JkZXIgdG8gc3RlZXIgdGhlIHVzZSBhbGdvcml0aG1zLCBh bGdvcml0aG0gcGFyYW1ldGVycyBjYW4gYmUNCmluY2x1ZGVkIG5leHQgdG8gdGhlIGFsZ29yaXRo bSBpZGVudGlmaWVycy4gIElmIHRoZXkgYXJlIGluY2x1ZGVkIGluIGENCmNlcnRpZmljYXRlLCB0 aGVzZSBoYXZlIHRvIGJlIHJlcHJlc2VudGVkIGluIHRoaXMgcHJvZmlsZSwgdG9vLiAgT3IgY2Fu DQphc3N1bXB0aW9uIGJlIG1hZGUgdGhhdCB0aGV5IGFyZSBub3QgdXNlZCBvciBzb21laG93IGRl dGVybWluaXN0aWM/ICBJZg0KaW4gZG91YnQsIHRoZSBzbWFsbCBhbW91bnQgb2YgY29tcGxleGl0 eSBhcyBmb3VuZCBpbiB0aGUgQ0RETCBtaWdodCBiZQ0Kd2FycmFudGVkLiAgSW4gdGhlIGVuZCwg aXQgd291bGQgYmUgdW5mb3J0dW5hdGUgdG8gZXhjbHVkZSBhIHN1YnNldCBvZg0KY2VydHMsIGJl Y2F1c2UgdGhleSBpbmNsdWRlIGFsZyBwYXJhbWV0ZXJzLg0KDQozLikgSG93IHJlbGV2YW50IGlz IHRoZSBpbmNsdXNpb24gb2YgZ2VuZXJpYyBleHRlbnNpb25zIHZpYSBvaWQgZm9yIHRoZQ0KYXBw bGljYXRpb24gb2YgdGhlIENCT1IgcHJvZmlsZSBmb3IgWC41MDk/ICBUaGUgUFIgaW5jbHVkZXMg YSByZWxhdGl2ZQ0Kc3RyYWlnaHQgZm9yd2FyZCBhcHByb2FjaCBob3cgdG8gbWFwIG9pZCwgYnV0 IGlzIHRoYXQgbmVjZXNzYXJ5PyAgSXMgaXQNCnNhZmUgdG8gYXNzdW1lIHRoYXQgdGhlcmUgd2ls bCBiZSBhIGNvcmUgc2V0IG9mIGV4dGVuc2lvbnMgdGhhdCB3YXJyYW50cw0KYSBtYXBwaW5nIHRv IGEgc2V0IG9mIGludGVnZXJzIHRoYXQgd291bGQgc2lnbmlmaWNhbnRseSByZWR1Y2UgdGhlIHNp emUNCm9mIGEgQ0JPUiBjZXJ0Pw0KDQpUaGVzZSBhcmUgdGhyZWUgcHJvbWluZW50IHRvcGljcyB0 b2RheSBhbmQgdGhlcmUgd2lsbCBiZSBvdGhlci4gIEkgaG9wZQ0KdG8gZ2V0IGZlZWRiYWNrIG9u IHRoZSB0b3BpY3MgZWxhYm9yYXRlZCBvbiBoZXJlIGFuZCBvZiBjb3Vyc2UgdGhlIFBSLg0KVGhl IGRpZmYgZm9yIHRoZSBQUiB0byBzZWUgdGhlIGNoYW5nZXMgc2lkZSBieSBzaWRlIGNhbiBiZSBm b3VuZCBoZXJlOg0KDQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9Fcmljc3NvblJlc2VhcmNoL0NCT1It Y2VydGlmaWNhdGVzL3B1bGwvMjQvZmlsZXM8aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92 MS91cmw/az0xMDQ5MzgwOC00ZWU5ZDg5Ni0xMDQ5Nzg5My04NmVlODZiZDUxMDctZDUwYTA2ZGM2 NzVjNDYwYyZxPTEmZT00YjI5MmJhZS00OTYyLTRhODYtOWRlMC0wYzAxMjdlNzQxZmUmdT1odHRw cyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZFcmljc3NvblJlc2VhcmNoJTJGQ0JPUi1jZXJ0aWZpY2F0 ZXMlMkZwdWxsJTJGMjQlMkZmaWxlcz4NCg0KDQpMb29raW5nIGF0IHRoZSBjdXJyZW50IGFuZCBw cm9wb3NlZCBDRERMIHN0cnVjdHVyZSwgSSdkIGxpa2UgdG8gbm90ZSBhcw0KICAgIGEgc2VwYXJh dGUgdG9waWMgdGhhdCB3aXRoIG9ubHkgYSBmZXcgbWluaW1hbCB0d2Vha3MgdG8gdGhlIGN1cnJl bnQNCnNwZWNpZmljYXRpb24gaXQgYWxyZWFkeSByZXNlbWJsZXMgYSBzb2x1dGlvbiB2aWFibGUg Zm9yIG5hdGl2ZSBDQk9SDQpjZXJ0aWZpY2F0ZXMsIHRvby4gVGhlIG9ubHkgZWZmZWN0aXZlIGRp ZmZlcmVuY2UgaXMgdGhlIHNjb3BlIG9mIHRoZQ0Kc2lnbmF0dXJlLCB3aGljaCB3b3VsZCBub3Qg cmVxdWlyZSBhIGR1YWwgc3RhY2sgaW1wbGVtZW50YXRpb24gb24NCmNvbnN0cmFpbmVkIGRldmlj ZXMgKHRoYXQgc29tZXRpbWVzIG1pZ2h0IHdhbnQgdG8gY2hlY2sgYSBzaWduYXR1cmUpLg0KDQpJ biBnZW5lcmFsLCBuYXRpdmUgQ0JPUiBjZXJ0aWZpY2F0ZXMgd291bGQgYmUgcXVpdGUgdXNlZnVs IGluDQphcHBsaWNhdGlvbnMsIHN1Y2ggYXMgU1VJVCBXb3JrZmxvdyBNb2RlbHMsIHRydXN0d29y dGh5IHRpbWUNCnN5bmNocm9uaXphdGlvbiBpbiBzd2FybXMgb2YgdGhpbmdzLCBsaWdodHdlaWdo dCByZW1vdGUtYXR0ZXN0YXRpb24sDQpDb25jaXNlIFNvZnR3YXJlIElkZW50aXRpZXMgb3IgdGhl IGVtZXJnaW5nIFNCT00gZWZmb3J0cyBvZiBOVElBL0NJQ1AuDQpJZiB5b3UgdGhpbmsgb2YgdGhl IElvVCBhcyBhbiBpbml0aWFsIHNjb3BlLCB0aGVyZSBpcyBhbHNvIG5vIHByZXNzaW5nDQpuZWVk IGZvciBwdWJsaWMgQ0FzIHRvIGVtYnJhY2UgYSBuYXRpdmUgZm9ybWF0IGFkLWhvYy4NCg0KVmll bGUgR3LDvMOfZSwNCg0KSGVuaw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KQ09TRSBtYWlsaW5nIGxpc3QNCkNPU0VAaWV0Zi5vcmc8bWFpbHRvOkNP U0VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UN Cg== --_000_3BB91C08EA7E43888CB978275E1CBDF4ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <8BF4503EA830C747B51557F22C3E14DE@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9ImVu LVNFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBIZW5rLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPlRoYW5rcyBmb3IgdGhlIGlucHV0LiBHcmVhdCB0byBhbHNvIHNlZSB5b3VyIG5vdGUg YWJvdXQgdXNlZnVsbmVzcyBvZiBuYXRpdmUgQ0JPUiBjZXJ0aWZpY2F0ZXMhIFRoaXMgYWRkcyB0 byBMYXVyZW5jZSBwcmV2aW91cyBjb21tZW50cyBvbiB0aGUgbGlzdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5Gb3IgeW91ciBpbmZvcm1hdGlvbiwgd2UgYXJlIG5vdyB3b3JraW5n IG9uIGEgbWVyZ2Ugb2YgdGhlIGZvbGxvd2luZyBkcmFmdHM6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5kcmFmdC1yYXphLWFjZS1j Ym9yLWNlcnRpZmljYXRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ZHJhZnQtbWF0dHNz b24tdGxzLWNib3ItY2VydC1jb21wcmVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ZHJh ZnQtbWF0dHNzb24tY29zZS1jYm9yLWNlcnQtY29tcHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRo ZSB1bmlvbiBvZiB0aGUgY29udGVudHMgd2lsbCBiZWNvbWUgYSBuZXcgdmVyc2lvbiBvZg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ZHJhZnQtbWF0dHNz b24tY29zZS1jYm9yLWNlcnQtY29tcHJlc3M8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+IChiZWluZyB0aGUgZHJhZnQgaGF2aW5nIHRo ZSByaWdodCBXRyBkZXNpZ25hdGlvbikuIFdlIHdpbGwgbm90IGJlIGFibGUgdG8gdGFrZSB5b3Vy IGNvbW1lbnRzIGludG8gYWNjb3VudCBiZWZvcmUNCiB0aGUgY3V0b2ZmIG9uIHRoZSAxM3RoLCBi dXQgdGhpcyBpcyBleGNlbGxlbnQgaW5wdXQgZm9yIGRpc2N1c3Npb24gYmVmb3JlIGFuZCBhdCB0 aGUgIUVURiAxMDggV0cgbWVldGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5U aGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Hw7ZyYW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9t Og0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ Sm9lbCBIw7ZnbHVuZCAmbHQ7am9lbC5ob2dsdW5kQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+VGh1cnNkYXksIDkgSnVseSAyMDIwIGF0IDIyOjAyPGJyPg0KPGI+VG86IDwvYj4mcXVv dDtjb3NlQGlldGYub3JnJnF1b3Q7ICZsdDtjb3NlQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8 L2I+JnF1b3Q7ZHJhZnQtcmF6YS1hY2UtY2Jvci1jZXJ0aWZpY2F0ZXNAaWV0Zi5vcmcmcXVvdDsg Jmx0O2RyYWZ0LXJhemEtYWNlLWNib3ItY2VydGlmaWNhdGVzQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogW0NPU0VdIFN0cnVjdHVyZSBvZiBDQk9SIGNlcnRpZmljYXRlczxi cj4NCjxiPlJlc2VudCBmcm9tOiA8L2I+Jmx0O2FsaWFzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+UmVzZW50IHRvOiA8L2I+Jmx0O3NoYWhpZC5yYXphQHJpLnNlJmd0OywgJmx0O2pvZWwu aG9nbHVuZEByaS5zZSZndDssICZsdDtnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20mZ3Q7LCBK b2huIE1hdHRzc29uICZsdDtqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbSZndDssICZsdDttYXJ0 aW4uZnVydWhlZEBuZXh1c2dyb3VwLmNvbSZndDs8YnI+DQo8Yj5SZXNlbnQgZGF0ZTogPC9iPlRo dXJzZGF5LCA5IEp1bHkgMjAyMCBhdCAyMjowMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4t bGVmdDozNi4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JvcmRlcjpub25l IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20iPkhpIEhlbmsgYW5kIGFsbCE8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmln aHQ6MGNtO21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0OjM2LjBwdDttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2s7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n OjBjbSI+VGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzIGFuZCB1cGRhdGUgcHJvcG9zYWxzISZu YnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDow Y207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDozNi4wcHQ7 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JvcmRlcjpub25lIHdpbmRvd3RleHQg MS4wcHQ7cGFkZGluZzowY20iPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjBj bTttYXJnaW4tbGVmdDozNi4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2Jv cmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20iPkluIGJyaWVmLCB0aGVyZSBp cyBkZWZpbml0ZWx5IGEgbmVlZCB0byBjbGFyaWZ5IHRoZSBhc3N1bXB0aW9ucyBhYm91dCBleGlz dGluZyB4NTA5IGRhdGEgc3RydWN0dXJlcyB3ZSB3YW50IHRvIGVuY29kZSwgYW5kIHByb2JhYmx5 IGluIHNvbWUgY2FzZXMgbWFrZSB0aGUgcHJvcG9zYWwNCiBtb3JlIGdlbmVyYWwgdG8gYWxsb3cg bW9yZSB2YWxpZCByZmM3OTI1IGNlcnRpZmljYXRlcy4gU29tZSBmdXJ0aGVyIGNvbW1lbnRzIHRv IHRoZSBoaWdobGlnaHRlZCBpc3N1ZXMgZm9sbG93cy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206MGNtO21hcmdpbi1sZWZ0OjM2LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2s7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+MS4gQWJvdXQg SXNzdWVyLWZpZWxkIGVuY29kaW5nczogV2Ugd291bGQgbGlrZSB0byBoYXZlIG1vcmUgZGlzY3Vz c2lvbnMgb24gaWYgZm9yIGluc3RhbmNlIHlvdXIgZGlyZWN0b3J5U3RyaW5nIHByb3Bvc2FsIGlz IG5lY2Vzc2FyeSwgb3IgaWYgdGhlIHN0cmluZyB0eXBlcyBjYW4NCiBiZSBhc3N1bWVkIC0tIGhv cGVmdWxseSB3aXRoIGlucHV0IGZyb20gb3RoZXJzIHdpdGggZXhwZXJpZW5jZSBvZiBob3cgSXNz dWVyLWZpZWxkcyBub3JtYWxseSBhcmUgZW5jb2RlZC4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0OjM2LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2s7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+Mi4g QWJvdXQgYWxnb3JpdGhtIHBhcmFtZXRlcnM6IE91ciBjdXJyZW50IGFzc3VtcHRpb24gaXMgdGhh dCBmb3Igb3VyIHRhcmdldCBjZXJ0aWZpY2F0ZXMsIGFsbCBuZWVkZWQgYWxnb3JpdGhtIGluZm8g Y2FuIGJlIHJlcHJlc2VudGVkIHVzaW5nIG9ubHkgdGhlIHN1YmplY3RQdWJsaWNLZXlJbmZvX2Fs Z29yaXRobQ0KIGZpZWxkLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTowY207bWFyZ2lu LWxlZnQ6MzYuMHB0O21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztib3JkZXI6bm9u ZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIj4zLiBBYm91dCBhIGdlbmVyYWwgZXh0ZW5z aW9uIG9pZC1tYXBwaW5nOiBXZSBiZWxpZXZlIHRoZSBmb3VyIGV4dGVuc2lvbnMgbWFuZGF0ZWQg YnkgcmZjNzkyNSBzaG91bGQgc3VmZmljZSwgYnV0IGFyZSBvcGVuIGZvciBoZWFyaW5nIGFib3V0 IElvVCByZXF1aXJlbWVudHMgdGhhdA0KIGdvIGJleW9uZCB0aG9zZSBmb3VyLjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6MzYuMHB0O21hcmdpbi1ib3R0b206 LjAwMDFwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjaztib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6 MGNtIj5Mb29raW5nIGZvcndhcmQgdG8gZnVydGhlciBkaXNjdXNzaW9ucywgYW5kPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDozNi4wcHQ7bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGlu ZzowY20iPkJlc3QgUmVnYXJkczwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTowY207bWFy Z2luLWxlZnQ6MzYuMHB0O21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztib3JkZXI6 bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIj5Kb2VsIEjDtmdsdW5kPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0OjM2LjBwdDttYXJnaW4tYm90dG9tOi4wMDAx cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2s7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+ PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0OjM2LjBw dDttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7Ym9yZGVyOm5vbmUgd2luZG93dGV4 dCAxLjBwdDtwYWRkaW5nOjBjbSI+PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBUaHUsIDkgSnVsIDIwMjAgYXQgMTI6MjYsIEhlbmsgQmly a2hvbHogJmx0OzxhIGhyZWY9Im1haWx0bzpoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRl Ij5oZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ SGkgYWxsLDxicj4NCjxicj4NClRMO0RSIG1vdmluZyB0aGUgQ0JPUiBYLjUwOSBQcm9maWxlIGZv cndhcmQgJiM0MzsgY29tbWVudHMgb24gbmF0aXZlIENCT1IgPGJyPg0KY2VydGlmaWNhdGVzPGJy Pg0KPGJyPg0KPGJyPg0KQWZ0ZXIgc29tZSBkaWFsb2cgd2l0aCB0aGUgYXV0aG9ycywgSSBjcmVh dGVkIGEgUFIgb24gYSBmZXcgdG9waWNzIHdlIDxicj4NCnRoaW5rIHNob3VsZCBiZSBkaXNjdXNz ZWQgb24tbGlzdC48YnI+DQo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vcHJvdGVjdDIuZmly ZWV5ZS5jb20vdjEvdXJsP2s9NTU5NDhlNDYtMGIzNDZlZDgtNTU5NGNlZGQtODZlZTg2YmQ1MTA3 LWZhZjZlNjAyZjhhMTc0ZGQmYW1wO3E9MSZhbXA7ZT00YjI5MmJhZS00OTYyLTRhODYtOWRlMC0w YzAxMjdlNzQxZmUmYW1wO3U9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGRXJpY3Nzb25SZXNl YXJjaCUyRkNCT1ItY2VydGlmaWNhdGVzJTJGcHVsbCUyRjI0IiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL2dpdGh1Yi5jb20vRXJpY3Nzb25SZXNlYXJjaC9DQk9SLWNlcnRpZmljYXRlcy9wdWxs LzI0PC9hPjxicj4NCjxicj4NClNvbWUgY29udGV4dDogVGhlIENCT1IgcHJvZmlsZSBmb3IgWC41 MDkgY2VydHMgaXMgYmFzZWQgb24gcmVxdWlyZW1lbnRzIDxicj4NCmNvbWluZyBmcm9tIHRoZSAo RClUTFMgcHJvZmlsZXMgZm9yIElvVCBhcyBkZWZpbmVkIGluIFJGQzc5MjUuPGJyPg0KPGJyPg0K U2VjdGlvbiA0LjQgaW4gUkZDNzkyNSBpcyBhYm91dCBjZXJ0aWZpY2F0ZXMgYW5kIHRoZSBtb3N0 IHJlbGV2YW50IHBhcnQgPGJyPg0Kb2YgdGhhdCBSRkMgZm9yIHRoaXMgd29yay4mbmJzcDsgTW9z dCBvZiB0aGUgcmVxdWlyZW1lbnRzIGRlZmluZWQgaGVscCB0byA8YnI+DQpyZWR1Y2UgdGhlIGNv bXBsZXhpdHkgb2YgaG93IHRvIHVzZSBYLjUwOSBwdWIta2V5IGlkZW50aXR5IGRvY3VtZW50cy48 YnI+DQpUaGlzIGhlbHBzIHdpdGggdGhlIGNvbXBsZXhpdHkgb2YgYSBjb3JyZXNwb25kaW5nIGNh bm9uaWNhbCA8YnI+DQpkZS1jb21wb3NpdGlvbiBhbmQgcmUtY29tcG9zaXRpb24gb2YgJnF1b3Q7 Q0JPUiBjZXJ0aWZpY2F0ZXMmcXVvdDsgLSBhbmQgPGJyPg0KdWx0aW1hdGVseSB0byBzYWZlIGJ5 dGVzIGR1cmluZyBjb252ZXlhbmNlLiZuYnNwOyBJdCBpcyBhbHNvIGltcG9ydGFudCB0byA8YnI+ DQpoaWdobGlnaHQgaGVyZSB0aGF0IG5vdCBvbmx5IHNhdmluZyBieXRlcyBpcyBpbXBvcnRhbnQs IGJ1dCBhbHNvIHRoZSA8YnI+DQphcHBsaWNhYmlsaXR5IG9mIHRoZSBzb2x1dGlvbi4mbmJzcDsg VGhlIG1vcmUgY2VydGlmaWNhdGVzIGNhbiBiZSA8YnI+DQpwcm9jZXNzZWQvY29tcHJlc3NlZCB2 aWEgdGhlIGRlZmluZWQgYXBwcm9hY2gsIHRoZSBtb3JlIGl0IHdpbGwgYmUgPGJyPg0KdXNlZnVs IGluIHRoZSBmaWVsZC48YnI+DQo8YnI+DQpUaGUgUFIgaGlnaGxpZ2h0ZWQgYWJvdmUgaW5jbHVk ZXMgYSBwcm9wb3NhbCBob3cgYSBmdWxsIENEREwgPGJyPg0Kc3BlY2lmaWNhdGlvbiBjYW4gbG9v a3MgbGlrZS4mbmJzcDsgSXQgYWxzbyBhZGRzIHNvbWUgY29tcGxleGl0eSB0byB0aGUgQ0JPUiA8 YnI+DQpzdHJ1Y3R1cmUgdGhhdCB3ZSBtYXkgb3IgbWF5IG5vdCB3YW50LiZuYnNwOyBBbmQgdGhh dCBpcyB3aGF0IHdlIHdvdWxkIGxpa2UgPGJyPg0KdG8gZmluZCBvdXQgd2l0aCB0aGUgaGVscCBv ZiB0aGUgbGlzdC4mbmJzcDsgQXMgYSByZXN1bHQgdGhhdCBQUiBpcyBpbnRlbmRlZCA8YnI+DQp0 byBiZSBhIGJhc2lzIGZvciBkaXNjdXNzaW9uLjxicj4NCjxicj4NCkluIG9yZGVyIHRvIGtpY2st b2ZmIHRoZSBkaXNjdXNzaW9uLCBJIHdvdWxkIGxpa2UgdG8gaGlnaGxpZ2h0IGEgZmV3IDxicj4N CnRvcGljcyB3ZSBzdGFydGVkIHRvIGRpc2N1c3MgdmlhIHRoZSBQUiBoZXJlIG9uIHRoZSBsaXN0 Ljxicj4NCjxicj4NCjEuKSBXaGlsZSB0aGUgdXNlIG9mIFN1YmplY3QgaXMgc2lnbmlmaWNhbnRs eSBzaW1wbGlmaWVkIGluIFJGQzc5MjUsIHRoZSA8YnI+DQpzYW1lIGlzIG5vdCB0cnVlIGZvciBJ c3N1ZXIuJm5ic3A7IFRoZSBQUiBwcm92aWRlcyBhbiBleGFtcGxlIG9mIGhvdyB0byA8YnI+DQpw cmVzZW50ICZxdW90O25vdC1SRkM3OTI1LW9wdGltaXplZCZxdW90OyBoaWVyYXJjaGljYWwgbmFt ZXMuJm5ic3A7IEFuZCB5b3UgY2FuIHNlZSB0aGUgPGJyPg0KaW5jcmVhc2VkIGNvbXBsZXhpdHkg cXVpdGUgd2VsbC4mbmJzcDsgU3RyaW5nIHR5cGVzIGxpa2UgdGhlIG9wdGlvbnMgZnJvbSA8YnI+ DQpkaXJlY3RvcnlTdHJpbmcgb3IgQUk1IGhhdmUgdG8gYmUgcmV0YWluZWQgaW4gb3JkZXIgdG8g YWxsb3cgZm9yIDxicj4NCmNhbm9uaWNhbCByZS1jb25zdHJ1Y3Rpb24gb2YgSXNzdWVyLiZuYnNw OyBCdXQgbWF5YmUgLSBlZmZlY3RpdmVseSAtIHN0cmluZ3MgPGJyPg0KdHlwZSBhcmUgdXNlZCBp biBhIHZlcnkgZGV0ZXJtaW5pc3RpYyBtYW5uZXIuJm5ic3A7IFdvdWxkIHRoYXQgYmUgbmFpdmUg PGJyPg0KYXNzdW1wdGlvbj8mbmJzcDsgT3IgbWlnaHQgaXQgYmUgZmVhc2libGUgdG8gcmV1c2Ug dGhlIFN1YmplY3QgY29uc3RyYWludHMgPGJyPg0KZnJvbSBSRkM3OTI1IGZvciBJc3N1ZXI/PGJy Pg0KPGJyPg0KMi4pIEluIG9yZGVyIHRvIHN0ZWVyIHRoZSB1c2UgYWxnb3JpdGhtcywgYWxnb3Jp dGhtIHBhcmFtZXRlcnMgY2FuIGJlIDxicj4NCmluY2x1ZGVkIG5leHQgdG8gdGhlIGFsZ29yaXRo bSBpZGVudGlmaWVycy4mbmJzcDsgSWYgdGhleSBhcmUgaW5jbHVkZWQgaW4gYSA8YnI+DQpjZXJ0 aWZpY2F0ZSwgdGhlc2UgaGF2ZSB0byBiZSByZXByZXNlbnRlZCBpbiB0aGlzIHByb2ZpbGUsIHRv by4mbmJzcDsgT3IgY2FuIDxicj4NCmFzc3VtcHRpb24gYmUgbWFkZSB0aGF0IHRoZXkgYXJlIG5v dCB1c2VkIG9yIHNvbWVob3cgZGV0ZXJtaW5pc3RpYz8mbmJzcDsgSWYgPGJyPg0KaW4gZG91YnQs IHRoZSBzbWFsbCBhbW91bnQgb2YgY29tcGxleGl0eSBhcyBmb3VuZCBpbiB0aGUgQ0RETCBtaWdo dCBiZSA8YnI+DQp3YXJyYW50ZWQuJm5ic3A7IEluIHRoZSBlbmQsIGl0IHdvdWxkIGJlIHVuZm9y dHVuYXRlIHRvIGV4Y2x1ZGUgYSBzdWJzZXQgb2YgPGJyPg0KY2VydHMsIGJlY2F1c2UgdGhleSBp bmNsdWRlIGFsZyBwYXJhbWV0ZXJzLjxicj4NCjxicj4NCjMuKSBIb3cgcmVsZXZhbnQgaXMgdGhl IGluY2x1c2lvbiBvZiBnZW5lcmljIGV4dGVuc2lvbnMgdmlhIG9pZCBmb3IgdGhlIDxicj4NCmFw cGxpY2F0aW9uIG9mIHRoZSBDQk9SIHByb2ZpbGUgZm9yIFguNTA5PyZuYnNwOyBUaGUgUFIgaW5j bHVkZXMgYSByZWxhdGl2ZSA8YnI+DQpzdHJhaWdodCBmb3J3YXJkIGFwcHJvYWNoIGhvdyB0byBt YXAgb2lkLCBidXQgaXMgdGhhdCBuZWNlc3Nhcnk/Jm5ic3A7IElzIGl0IDxicj4NCnNhZmUgdG8g YXNzdW1lIHRoYXQgdGhlcmUgd2lsbCBiZSBhIGNvcmUgc2V0IG9mIGV4dGVuc2lvbnMgdGhhdCB3 YXJyYW50cyA8YnI+DQphIG1hcHBpbmcgdG8gYSBzZXQgb2YgaW50ZWdlcnMgdGhhdCB3b3VsZCBz aWduaWZpY2FudGx5IHJlZHVjZSB0aGUgc2l6ZSA8YnI+DQpvZiBhIENCT1IgY2VydD88YnI+DQo8 YnI+DQpUaGVzZSBhcmUgdGhyZWUgcHJvbWluZW50IHRvcGljcyB0b2RheSBhbmQgdGhlcmUgd2ls bCBiZSBvdGhlci4mbmJzcDsgSSBob3BlIDxicj4NCnRvIGdldCBmZWVkYmFjayBvbiB0aGUgdG9w aWNzIGVsYWJvcmF0ZWQgb24gaGVyZSBhbmQgb2YgY291cnNlIHRoZSBQUi4gPGJyPg0KVGhlIGRp ZmYgZm9yIHRoZSBQUiB0byBzZWUgdGhlIGNoYW5nZXMgc2lkZSBieSBzaWRlIGNhbiBiZSBmb3Vu ZCBoZXJlOjxicj4NCjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXll LmNvbS92MS91cmw/az0xMDQ5MzgwOC00ZWU5ZDg5Ni0xMDQ5Nzg5My04NmVlODZiZDUxMDctZDUw YTA2ZGM2NzVjNDYwYyZhbXA7cT0xJmFtcDtlPTRiMjkyYmFlLTQ5NjItNGE4Ni05ZGUwLTBjMDEy N2U3NDFmZSZhbXA7dT1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZFcmljc3NvblJlc2VhcmNo JTJGQ0JPUi1jZXJ0aWZpY2F0ZXMlMkZwdWxsJTJGMjQlMkZmaWxlcyIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cHM6Ly9naXRodWIuY29tL0VyaWNzc29uUmVzZWFyY2gvQ0JPUi1jZXJ0aWZpY2F0ZXMv cHVsbC8yNC9maWxlczwvYT48YnI+DQo8YnI+DQo8YnI+DQpMb29raW5nIGF0IHRoZSBjdXJyZW50 IGFuZCBwcm9wb3NlZCBDRERMIHN0cnVjdHVyZSwgSSdkIGxpa2UgdG8gbm90ZSBhcyA8YnI+DQom bmJzcDsgJm5ic3A7IGEgc2VwYXJhdGUgdG9waWMgdGhhdCB3aXRoIG9ubHkgYSBmZXcgbWluaW1h bCB0d2Vha3MgdG8gdGhlIGN1cnJlbnQgPGJyPg0Kc3BlY2lmaWNhdGlvbiBpdCBhbHJlYWR5IHJl c2VtYmxlcyBhIHNvbHV0aW9uIHZpYWJsZSBmb3IgbmF0aXZlIENCT1IgPGJyPg0KY2VydGlmaWNh dGVzLCB0b28uIFRoZSBvbmx5IGVmZmVjdGl2ZSBkaWZmZXJlbmNlIGlzIHRoZSBzY29wZSBvZiB0 aGUgPGJyPg0Kc2lnbmF0dXJlLCB3aGljaCB3b3VsZCBub3QgcmVxdWlyZSBhIGR1YWwgc3RhY2sg aW1wbGVtZW50YXRpb24gb24gPGJyPg0KY29uc3RyYWluZWQgZGV2aWNlcyAodGhhdCBzb21ldGlt ZXMgbWlnaHQgd2FudCB0byBjaGVjayBhIHNpZ25hdHVyZSkuPGJyPg0KPGJyPg0KSW4gZ2VuZXJh bCwgbmF0aXZlIENCT1IgY2VydGlmaWNhdGVzIHdvdWxkIGJlIHF1aXRlIHVzZWZ1bCBpbiA8YnI+ DQphcHBsaWNhdGlvbnMsIHN1Y2ggYXMgU1VJVCBXb3JrZmxvdyBNb2RlbHMsIHRydXN0d29ydGh5 IHRpbWUgPGJyPg0Kc3luY2hyb25pemF0aW9uIGluIHN3YXJtcyBvZiB0aGluZ3MsIGxpZ2h0d2Vp Z2h0IHJlbW90ZS1hdHRlc3RhdGlvbiwgPGJyPg0KQ29uY2lzZSBTb2Z0d2FyZSBJZGVudGl0aWVz IG9yIHRoZSBlbWVyZ2luZyBTQk9NIGVmZm9ydHMgb2YgTlRJQS9DSUNQLiA8YnI+DQpJZiB5b3Ug dGhpbmsgb2YgdGhlIElvVCBhcyBhbiBpbml0aWFsIHNjb3BlLCB0aGVyZSBpcyBhbHNvIG5vIHBy ZXNzaW5nIDxicj4NCm5lZWQgZm9yIHB1YmxpYyBDQXMgdG8gZW1icmFjZSBhIG5hdGl2ZSBmb3Jt YXQgYWQtaG9jLjxicj4NCjxicj4NClZpZWxlIEdyw7zDn2UsPGJyPg0KPGJyPg0KSGVuazxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KQ09TRSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q09TRUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPkNPU0VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3BB91C08EA7E43888CB978275E1CBDF4ericssoncom_-- From nobody Fri Jul 10 05:58:54 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 B5DCF3A0C44; Fri, 10 Jul 2020 05:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=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 ITm8I1UlGuI5; Fri, 10 Jul 2020 05:58:50 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2b.welho.com [83.102.41.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0F13A0C40; Fri, 10 Jul 2020 05:58:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 828CCD010F; Fri, 10 Jul 2020 15:58:47 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 3rXNcvhPrecc; Fri, 10 Jul 2020 15:58:47 +0300 (EEST) Received: from LK-Perkele-VII (84-253-234-84.bb.dnainternet.fi [84.253.234.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 2BED02316; Fri, 10 Jul 2020 15:58:44 +0300 (EEST) Date: Fri, 10 Jul 2020 15:58:43 +0300 From: Ilari Liusvaara To: Joel =?utf-8?Q?H=C3=B6glund?= Cc: cose@ietf.org, draft-raza-ace-cbor-certificates@ietf.org Message-ID: <20200710125843.GA224527@LK-Perkele-VII> References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 10 Jul 2020 12:58:52 -0000 On Thu, Jul 09, 2020 at 10:02:15PM +0200, Joel Höglund wrote: > Hi Henk and all! > > Thank you for your comments and update proposals! > > > In brief, there is definitely a need to clarify the assumptions about > existing x509 data structures we want to encode, and probably in some cases > make the proposal more general to allow more valid rfc7925 certificates. > Some further comments to the highlighted issues follows. > > 1. About Issuer-field encodings: We would like to have more discussions on > if for instance your directoryString proposal is necessary, or if the > string types can be assumed -- hopefully with input from others with > experience of how Issuer-fields normally are encoded. I would say that the encoding of the issuer (and subject) fields is the most difficult part. Looking at the definition of issuer/subject, it is essentially: List> Which is bit unfortunate in two ways: - Set of pairs is not the same as dictionary. - The right hand side type is Any, and not DirectoryString. - The outer list is usually of size 1. If one really wanted to eke bytes, one could have either 1 or 2 lists, since the the first element of inner list can not possibly be a list itself. If one goes for implementation complexity at cost of wire size, then one would always have 2 lists. And then one could have the Oid be encoded as integer for common ones and bstr for not-common ones. And the value could be str, which tries to autoguess the correct type, or bstr containing asn1tag+value as escape. The type autoguess would guess PrintableString if every character is valid for PrintableString, else it would guess Utf8String. In practice, I do not think anybody uses any other ones (and wrong guess would be just 1 byte penalty, unless name is 24 bytes, then it would be 2 byte penalty). Then there is the special case where subject is empty. That could be encoded as empty list. > 2. About algorithm parameters: Our current assumption is that for our > target certificates, all needed algorithm info can be represented using > only the subjectPublicKeyInfo_algorithm field. Note that in practice, there are very few different SubjectPublicKeyInfo field types in any sort of wide use. Anything else is extremely rare. Thus, one could compress the field by having integer for type, and bstr for contents. And perhaps bstr type and bstr contents as escape hatch (maybe even with the bit stripping octet retained), should that be ever needed (that would not increase size in common case). For instance, types could be: 0 => X25519/X448 1 => Ed25519/Ed448 2 => ECDSA P-256/P-384/P-521. The type overloads are resolvable. For instance, this encoding could encode Ed25519 or X25519 key to 35 bytes (3 bytes overhead). And with regards to signature algorithm (which is actually encoded twic in X.509!), the common case is a few actually used algorithms. E.g.: 0 => Ed25519 1 => Ed448 2 => ECDSA SHA-256 3 => ECDSA SHA-384 4 => ECDSA SHA-512 5 => ECDSA SHAKE-128 6 => ECDSA SHAKE-256 That goes to 1 byte (and of course one could have bstr escape without affecting common case). > 3. About a general extension oid-mapping: We believe the four extensions > mandated by rfc7925 should suffice, but are open for hearing about IoT > requirements that go beyond those four. Extensions could be encoded as array of pairs (one would not want map here due to order-sensitivity). One could have generic encoding by having integers encode known extensions (negative integers encoding critiality) and bstrs encode escapes (the value of escape would be optional critical flag and then the raw extension value, which is an octet string). Known extensions would have more specialzed encodings. Examples of what could be more specialized encodings: KeyUsage: Integer value + (1 << bits). This would not allow KeyUsage bits above 63th, but I do not think the number of defined bits is anywhere close to that (RFC5280 defines 9 bits). And things could turn real annoying if KeyUsage ever needs to set any bit above 63rd. Sure, one could escape the thing, but relying parties might puke on that. None of the other three extensions ever needs escaping for any reasonable value. ExtendedKeyUsage: List of integer / bstr Integers would encode some common key usages, bstrs would be escapes (with just values). BasicConstraints: null/true/uint Null encodes empty extension, true encodes just true, and int would encode true followed by max path length. SubjectAlternativeName: array of bstr The bstrs are asn1tag+value. Thus e.g. "foo.example" is encoded as: 4C 82 "foo.example". Encoding IPv4 address would take 6 bytes, IPv6 address would take 18 (2 bytes overhead in both cases). The difficulty of adding extension beyond these four would depend on the extension. There would be slots for 24 compact extensions (20 more than here), 232 bit less compact ones, etc... Looking at the extension list from RFC5280, the only ones that do not look like unsuitable for IoT are subject/authority key ID extensions. Besides the incompatible encodings, if PKI is not crazy, one can use issuer/subject fields as key identifiers (however, comparing the above subject/issuer encoding could be annoying). So these do not look important. Looking at the other fields, how those could be encoded: - version: Implicit from presence of optional fields. - serial_number: bstr (with initial 00 if any stripped). - validity: pair of integers (unix timestamps). The time format would depend on range (-631152000 to 2524607999 is UtcTime). Maybe bstr with asn1tag+value as escape in case of misencoded certificate. - issuerUniqueID/subjectUniqueID absent, null or bstr (including the strip bits byte). If subjectUniqueID is present, issuerUniqueID has to be as well. Looking at these rules, this could encode a lot more than just rfc7925 certificates, as there is an escape for nearly everything. The only obvious thing with no escape is the serial_number, but any violation there would be fatal ASN.1 error anyway. These should even give valid compression/decompression for webpki certificates, even if bad one, due to the junk present. I have not written any proof-of-concept code for this. So no performance numbers to give. -Ilari From nobody Fri Jul 10 17:49: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 013733A098A; Fri, 10 Jul 2020 17:49:22 -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 s5btR7erISSz; Fri, 10 Jul 2020 17:49:19 -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 95A7F3A0983; Fri, 10 Jul 2020 17:49:18 -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 06B0n8Cw007370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jul 2020 20:49:11 -0400 Date: Fri, 10 Jul 2020 17:49:07 -0700 From: Benjamin Kaduk To: Jim Schaad Cc: "'The IESG'" , cose-chairs@ietf.org, draft-ietf-cose-hash-algs@ietf.org, cose@ietf.org, ivaylo@ackl.io Message-ID: <20200711004907.GD16335@kduck.mit.edu> References: <159185494077.19612.5376022702223451135@ietfa.amsl.com> <007e01d653c9$c766bfe0$56343fa0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007e01d653c9$c766bfe0$56343fa0$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [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 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2020 00:49:22 -0000 On Mon, Jul 06, 2020 at 12:15:11PM -0700, Jim Schaad wrote: > > > > -----Original Message----- > > From: COSE On Behalf Of Benjamin Kaduk via > > Datatracker > > Sent: Wednesday, June 10, 2020 10:56 PM > > To: The IESG > > Cc: ivaylo@ackl.io; cose-chairs@ietf.org; > draft-ietf-cose-hash-algs@ietf.org; > > cose@ietf.org > > Subject: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-hash-algs-04: > (with > > DISCUSS and COMMENT) > > > > 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? > [JLS] This was a conflict between what I "knew to be true", even though I > had read the opposite several times, and what is "really true". I kept > forgetting this because of the fact that I knew there was no need for HMAC > to be used because the length extension attack did not exist. > > I have chosen to restrict to two items with fixed lengths. There was Okay. We should actually remove the "One of the benefits of this difference is that when computing a shorter SHAKE hash value, the value is not a prefix of the result of computing the longer hash" language, though. Also, per Ilaari's remarks it sounds like we're doing to be lengthening the lengths, too. > discussion on the mailing list about using a form with a length prefixed as > that variant would provide the desired behavior of changing the output for > every different length. In the end I decided that this was not a good way > to go because I expect things such as certificate databases to be indexed by > the hash value and I would not expect that the modified version of the hash > function that was suggested would be the same as the version used for that > index. The fact that this value may be computed externally and included > from that source leads me to decide that that would not currently be wise. It seems like that same argument ("might not be the same as the one used for the index") could be applied to basically any SHAKE formulation we use, though. That said, Ilari's proposal is fairly natural, at least. > > > > > > ---------------------------------------------------------------------- > > 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.) > > [JLS] I think the next paragraph flows out of the "additionally" bits. I > think it is better to keep it. For me this reads as an additional reason > for the omission, but I agree that I don't think this needs to be clearer. Right, I think it's an additional reason for the omission, but the transition between sentences does not make this super-super-obvious. There's the simple option "An additional reason for the omission is that an application [...]", but you can decide whether that's too banal to put in. > > > > 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. > [JLS] > > I have changed the paragraph to read > > 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 an identifier for 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. > Rather the signature can be validated on all of the hash values and > pointers to the associated contents, then those associated parts can be > downloaded, the hash value of that part computed, and then compared to the > hash value in the signed content. > 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. > An example of how this is used can be found in target="I-D.ietf-suit-manifest"/>. > > The third and last sentences are new. The third sentence provides a script > for how validation would be done and the last sentence points to a place > where this is being done. I think that clarifies things enough, thanks. > > > > 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? > > [JLS] s/for secure/in a secure/ > > > > > 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"? > [JLS] Done. > > > > > 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 :) > > [JLS] Yes it would. > > > > > 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". > [JLS] I took part of this. > > > > > 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"?) > [JLS] Yeah, I guess it should. > > > > > 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". > [JLS] Identified as payload and switch from cannot to could have been. > > > > > hashed be included. (Encoding as a CBOR array accomplished this > > requirement.) > > > > nit: s/accomplished/accomplishes/ > [JLS] Fixed > > > > > 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. > [JLS] What you think as the chair of the CBOR working group I should know > this? Nah, the authors will take care of it. :) > > > > 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. > [JLS] I think I cleaned it up. > > > > > 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"? > [JLS] No - > > > > Because of the known issues for SHA-1 and the fact that is should no > > > > nit: s/is/it/ > [JLS] Already fixed. > > > > > 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. > [JLS] I think it is fine. Yes the proportion is to the exponent but I think > this does not need to be explicit. > > > > > need either to analysis the potential problems with having a > > > > nit: s/analysis/analyze/ > [JLS] Fixed. > > > > > 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. > [JLS] I changed it and dropped a note to the RFC editor. > > > > > 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"? > [JLS] Yes that makes sense. > > > > > 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.) > [JLS] > > > > 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. > [JLS] With fixed lengths - I have changed this. Sure. > > > > Also, I think we should consider having some "minimum output length" > > that has to be used in order to qualify for the "Recommended:Yes". > [JLS] But that is now gone. > > > > > 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"? > [JLS] Yes I believe that to be true. The interesting question is when to > make those jumps. I think that generally Filter Only is almost the same as > deprecated for hash algorithms. That's my sense, too. > > > > 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. > [JLS] I am not sure that this is true. All of the properties are > cryptographically bound into the overall signature. So all that leaves > would be to say - Do what is there and not something else - which does not > really sound like a security consideration to me. What overall signature? Can't we use hashes outside of a signature? Sure, if there's a containing signature, that takes care of getting the parameters bound to the hash calculation, but if there's no signature we probably want some other way of doing that. > > > > 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. > [JLS] Think it got it. > > > > > 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) > [JLS] But much easier to do a second time. > > > > > 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. > [JLS] I agree. Done. > > > > > 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.) > [JLS] Yuck - An informative reference on something we say you shouldn't do. I'm just going by https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ > > > > 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.) > > [JLS] I would expect that the RFC editor would remove the paragraph because > it is an instruction that does not need to be kept long term. I will so > note in the xml. Ah, fair enough. Thanks for the updates! -Ben From nobody Fri Jul 10 18:06: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 982A33A09A5; Fri, 10 Jul 2020 18:06:05 -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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159442956559.24063.13675507837676989872@ietfa.amsl.com> Date: Fri, 10 Jul 2020 18:06:05 -0700 Archived-At: Subject: [COSE] Benjamin Kaduk's No Objection on draft-ietf-cose-hash-algs-06: (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, 11 Jul 2020 01:06:06 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-cose-hash-algs-06: 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 the past and pending updates to address my Discuss point. A few new comments on the -06: Section 2 attacks, SHOULD NOT be used for a cryptographic purpose. 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. The It's not really clear who this SHOULD is binding upon. 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. This turned into a comma splice; I'd just make it use a semicolon (and independently do s/check/checked/) Section 3.1 this hash algorithm. Some of these situations are with historic HSMs where only SHA-1 is implemented, other situations are where the SHA-1 value is used for the purpose of filtering and thus the collision resistance property is not needed. nit: comma splice The COSE capabilities for these algorithms is an empty array. This went from "this algorithm" to "these algorithms" in the -05, but I missed why -- it's just the one SHA-1 algorithm, I thought. 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. Use of this hash function needs analyze of the potential problems with having a collision occur, or must be limited to where the function of the hash is non-cryptographic. With the rest of the rewording, we have to go back to "analysis" from "analyze". (Sorry!) 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 difference is that when computing a shorter SHAKE hash value, the value is not a prefix of the result of computing the longer hash. (This last sentence is scheduled for removal.) From nobody Sat Jul 11 18: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 526DA3A07F3; Sat, 11 Jul 2020 18:37:12 -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 SGMsUAW3_waM; Sat, 11 Jul 2020 18:37:11 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 D1F1B3A07F2; Sat, 11 Jul 2020 18:37:10 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id h18so2985793uao.6; Sat, 11 Jul 2020 18:37:10 -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=5qXmrJLrqtASfWul5JBcIJzldLa9+FoOTGWIcxphUR8=; b=hiLozSAY8y34KmQZ+c0pHHjcm3I4fDqn9He1RU+IxBZNbegKfgHxOjaxEPim20z9av 8A1Djl2I3MFSr6Voz6K2SXyvXET8SRIJxNz7JhsKpIq50tbi2OZWT7tZkKcLvQtdlWt7 mgcHOxqiv585LPtlb1Ljq7M8H11Xd3YKQ0Wx26pt+BA5yExeYhIM19BJszJm7sOThCFm dXUL4RN4hOCqBPC2n+VXLKiqKmfcMz5h4hVHzrdIphei16MWq5jTheGiczG+ZFwHbLJ/ 2swWACr6xTCuveUrts3kTn3sE+Pgr8XCVb2qhng2R4WT9l28loNwrskleYosMLVJyxe0 DaxA== 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=5qXmrJLrqtASfWul5JBcIJzldLa9+FoOTGWIcxphUR8=; b=ih0mXR95p0M7foaX/679M/oV3CBJlth06v8LUL+Wo6EgNbldpKcEMBeg5r1W9TwRuR D18WHsgiocltOex3oKBoLUjMTDLEZyC2XAvr2LeR8HwhAN724u9F/dpGFB1/gsnrQb/b sO92B0/nYZ1IUt0SscsyEVRlM5euzK/iqJrxKOcjGzJjp4YN7OMEYKokKCcjo/9gOjaM wPX+DrgutQbpD18nO2vWEtHlsQhuI5H77m/Izqt+2YZZMmaoHyXQdSnjGdccv5seF8Ug h6pSqNcBdOyRxXVNJDEv4qVZvVqa4OdjdI3ZWz/2fQmrBMpncsa2uEh5jEGQBjJcA22u d84A== X-Gm-Message-State: AOAM530P7N8LbzpKdElpFhMEwcFsxDkKzH9ptfpUXfCLaAYVmJsHL2s4 BrCYSfeRr3+Lh2IUoLo00TyXeZ2uMMPphlYB0Dk= X-Google-Smtp-Source: ABdhPJz+obY4Dqxq3qA09gPfUjT4mg+jBZ9HhgSvxAhaRb8VTEbefcAVyYCnkprIvGSPAl+JsMK33MvFJDE+a0f1gE0= X-Received: by 2002:a9f:2a8e:: with SMTP id z14mr2226928uai.47.1594517829846; Sat, 11 Jul 2020 18:37:09 -0700 (PDT) MIME-Version: 1.0 References: <159442956559.24063.13675507837676989872@ietfa.amsl.com> In-Reply-To: <159442956559.24063.13675507837676989872@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Sat, 11 Jul 2020 18:36:57 -0700 Message-ID: To: Benjamin Kaduk Cc: The IESG , Ivaylo Petrov , Cose Chairs Wg , draft-ietf-cose-hash-algs@ietf.org, cose@ietf.org Content-Type: multipart/alternative; boundary="000000000000d60a4605aa349c3c" Archived-At: Subject: Re: [COSE] Benjamin Kaduk's No Objection on draft-ietf-cose-hash-algs-06: (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, 12 Jul 2020 01:37:12 -0000 --000000000000d60a4605aa349c3c Content-Type: text/plain; charset="UTF-8" On Fri, Jul 10, 2020 at 6:06 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-cose-hash-algs-06: 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 the past and pending updates to address my Discuss point. > A few new comments on the -06: > [...] > I take "pending" to mean I should expect an -07 before approving this? Assuming "yes", I'm going to mark it as "Revised I-D Needed" now, but please tell me if I'm misunderstanding. -MSK --000000000000d60a4605aa349c3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 10, 2020 at 6:06 PM Benjamin = Kaduk via Datatracker <noreply@ietf.= org> wrote:
Benjamin Kaduk has entered the following ball= ot position for
draft-ietf-cose-hash-algs-06: 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/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/draft-ie= tf-cose-hash-algs/



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

Thanks for the past and pending updates to address my Discuss point.
A few new comments on the -06:
[...]

I take "pending" to mean I should expect an -07 = before approving this?

Assuming "yes", I'm going to mark it as &quo= t;Revised I-D Needed" now, but please tell me if I'm misunderstand= ing.

-= MSK
--000000000000d60a4605aa349c3c-- From nobody Sat Jul 11 18:46:41 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 DFE523A0809; Sat, 11 Jul 2020 18:46:39 -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 zZ-EjXh9mGpz; Sat, 11 Jul 2020 18:46:38 -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 EA94F3A0805; Sat, 11 Jul 2020 18:46:37 -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 06C1kVaq020577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 11 Jul 2020 21:46:34 -0400 Date: Sat, 11 Jul 2020 18:46:31 -0700 From: Benjamin Kaduk To: "Murray S. Kucherawy" Cc: The IESG , Ivaylo Petrov , Cose Chairs Wg , draft-ietf-cose-hash-algs@ietf.org, cose@ietf.org Message-ID: <20200712014631.GQ16335@kduck.mit.edu> References: <159442956559.24063.13675507837676989872@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's No Objection on draft-ietf-cose-hash-algs-06: (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, 12 Jul 2020 01:46:40 -0000 On Sat, Jul 11, 2020 at 06:36:57PM -0700, Murray S. Kucherawy wrote: > On Fri, Jul 10, 2020 at 6:06 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-cose-hash-algs-06: 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 the past and pending updates to address my Discuss point. > > A few new comments on the -06: > > [...] > > > > I take "pending" to mean I should expect an -07 before approving this? > > Assuming "yes", I'm going to mark it as "Revised I-D Needed" now, but > please tell me if I'm misunderstanding. Your understanding is correct. See https://mailarchive.ietf.org/arch/msg/cose/KvoH-c1DXhfL_Jg_qxuY_IeTSL8/ and my comment on section 3.3 (we still have text that claims that a shorter SHAKE output is not a prefix of a longer SHAKE output, which is false). -Ben From nobody Tue Jul 14 06:27:18 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 C7C753A00DF for ; Tue, 14 Jul 2020 06:27:16 -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 DAq4dc2I77lu for ; Tue, 14 Jul 2020 06:27:15 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 2408B3A003D for ; Tue, 14 Jul 2020 06:27:15 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id q5so21598761wru.6 for ; Tue, 14 Jul 2020 06:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0ynAnx/BnWYXH6FE/PtSpdWUl6sC4Z4ejBQ9o79APQU=; b=jn/SmFhLXP4kmFXwn9wpZo6kKdbOplReQWLXDiFlagWM+Y2fgbAmmWzp9joySVKy6g 7VDPMtRRT9lesKqotdUTOeZK97nlAP1BNLMUjl1eTjnXQiQa/F1Rmg6L206cxCxabkmm sId6exs/OSbVPifOd0+ijiUslqPw9va1TDMPZcRmX+jq9tFh9t/HePvSGyz+kYB7g8rf MHBoWDwR6DgkQQCQbttBxMGen/hyXHRTwdSrVmebDGVzjkcbHVQt2S+hgYQX0l7mk3Rp lSFcZGlr66pxK66hQbwjP4rZDxu2Sjv+b1b5e2wr6jARsordA/PZbZUlNsyz7mMlaW9F xo8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0ynAnx/BnWYXH6FE/PtSpdWUl6sC4Z4ejBQ9o79APQU=; b=hJVtTSMAtRAkoqfR5MNOd7CbESA1WoRAImKItH1JoilB5Q0xJXHUQvK1VGlI32YtPm VDK+0XgGLu4QTEOxmjwrEq6LaMQa51O6JcOtaziTuEkHUa3NO2szHCLRh9tU+9dTi51K /5fryUDIfdlUGNT4WgwKANZIA6tdDvY5U2DYu8GSPZzKB9Te/7OeYIIWv51NbR+GEsWD noKkWkrjam5aBuQrDu6bBUFD8SuPb105j5ZXTMY2u/GITyrm1L1umhT2K/I8OSEcp2VG c17oeeBDht3eQn0h8WGb8FLYuUyZDp5OwRDl70brrrz3ZSxmotm2fZqj9qTYrgxqwhmN HZ7Q== X-Gm-Message-State: AOAM532jfna0gQlT+21V8UO7kl83iRixTbSLanKx3yJN+TpbJx2hievF LeOu0NsCNjI+fnL7DBf+KcJCj8IUfndoxEZKH0m2/3jFRjY= X-Google-Smtp-Source: ABdhPJwFU0sqyqlJvt+EnlXT84xX4c+/afgnngOAqD3kLhIRIGtFsSRzriZj6k9q73hnbEJWRUAffpRhQ4P/udAiYco= X-Received: by 2002:adf:f14c:: with SMTP id y12mr5418088wro.30.1594733232700; Tue, 14 Jul 2020 06:27:12 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Joel_H=C3=B6glund?= Date: Tue, 14 Jul 2020 15:27:00 +0200 Message-ID: To: cose@ietf.org Content-Type: multipart/alternative; boundary="000000000000d8c13b05aa66c33e" Archived-At: Subject: [COSE] Fwd: New Version Notification for draft-mattsson-cose-cbor-cert-compress-01.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, 14 Jul 2020 13:27:17 -0000 --000000000000d8c13b05aa66c33e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello COSE! We have recently submitted an updated =E2=80=98CBOR Profile of X.509 Certif= icates=E2=80=99 draft. This is a merger of the main draft-raza-ace-cbor-certificates together with the TLS and COSE profiles, draft-mattsson-tls-cbor-cert-compress and draft-mattsson-cose-cbor-cert-compress. The merged draft is available as: https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-01 The document specifies a CBOR encoding and compression of RFC 7925 profiled certificates targeting IoT scenarios. It proposes COSE headers as well as the use of CBOR certificate compression algorithm with TLS Certificate Compression in (D)TLS 1.3. Besides the merger, compared with the previous version we have clarified more encoding details and optimizations. The goal is to provide a compact yet easy to implement encoding scheme, and we look forward to continued discussions on the trade-offs between expressiveness and compactness. Best Regards Joel H=C3=B6glund ------------------------------ *Fr=C3=A5n:* internet-drafts@ietf.org *=C3=84mne:* New Version Notification for draft-mattsson-cose-cbor-cert-compress-01.txt A new version of I-D, draft-mattsson-cose-cbor-cert-compress-01.txt has been successfully submitted by =3D?utf-8?q?G=3DC3=3DB6ran_Selander?=3D = and posted to the IETF repository. Name: draft-mattsson-cose-cbor-cert-compress Revision: 01 Title: CBOR Profile of X.509 Certificates Document date: 2020-07-13 Group: Individual Submission Pages: 18 --000000000000d8c13b05aa66c33e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello COSE!


We have recently submitted an updated =E2=80=98CBOR Profile of X.= 509 Certificates=E2=80=99 draft. This is a merger of the main draft-raza-ac= e-cbor-certificates together with the TLS and COSE profiles, draft-mattsson= -tls-cbor-cert-compress and draft-mattsson-cose-cbor-cert-compress. The mer= ged draft is available as:


https://tools.ietf.org/html/draft-mattsson-cose-cbor-= cert-compress-01


The document specifies a CBOR encoding and compression of RFC 7925= profiled certificates targeting IoT scenarios. It proposes COSE headers as= well as the use of CBOR certificate compression algorithm with TLS Certifi= cate Compression in (D)TLS 1.3.


Besides the merger, compared with the previous version = we have clarified more encoding details and optimizations. The goal is to p= rovide a compact yet easy to implement encoding scheme, and we look forward= to continued discussions on the trade-offs between expressiveness and comp= actness.


Bes= t Regards=C2=A0


Joel H=C3=B6glund



F= r=C3=A5n: internet-drafts@i= etf.org <internet-drafts= @ietf.org>
=C3=84mne: New Version Notification for draft-m= attsson-cose-cbor-cert-compress-01.txt
=C2=A0

A new version of I-D, draft-mattsson-co= se-cbor-cert-compress-01.txt
has been successfully submitted by =3D?utf-= 8?q?G=3DC3=3DB6ran_Selander?=3D and posted to the
IETF repository.
Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-m= attsson-cose-cbor-cert-compress
Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 01
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C= BOR Profile of X.509 Certificates
Document date:=C2=A0 2020-07-13
Gro= up:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Individual Submis= sion
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 18
=
--000000000000d8c13b05aa66c33e-- From nobody Thu Jul 16 02:38:26 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 5C3F33A07D4; Thu, 16 Jul 2020 02:38:25 -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 yzZ0L7Nw-8UQ; Thu, 16 Jul 2020 02:38:23 -0700 (PDT) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 143263A07D6; Thu, 16 Jul 2020 02:38:22 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id f7so6373569wrw.1; Thu, 16 Jul 2020 02:38:22 -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=NoUIuASIoILhitdPPG/KjMVlMfYJrbUkurv6g/huET0=; b=rUVW2hXueAN70neMJxogwvpiefRt5MH71wPifou/QGgKfvUFT7JmooOicZxNvb74kq bFCcGm07ZqUTwYp8S7Kj3FxY2J5nswA38428SPnGBUa32ke+Xx4FxA0V+HLaweGeDRKl M7RZWgTaztz8M+eddyqngV9mxJ9stx5kH40I/zp/J8LR3Oy3hGeJxLxaWuNOSZSgpDqP l8XVI8reDNH2Lnq4vGEbrNBTsLFc1+X0X8bLUdKRDlS0EVCIMGmB71vqQjgG9NY/FgPh 9/6LHt7+yWIRuhC9xc+a58tI69qTe6nVYH/gFO/YsL+C9QEWdWQgmrU9f1E7Xo7RqJJ9 UlhA== 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=NoUIuASIoILhitdPPG/KjMVlMfYJrbUkurv6g/huET0=; b=hgRWjwOdHwpFcFpcLbTmXO+KwME4OQQksc1ZSJSLOh7rEeLaKyhcUhjkcaZglJU1nd g4plkkGOdg+nU2OHnoQ59dyfokcSoUhR96GnwI9Oosl5A3YFijoJ/EsBp80ItUvrErA6 iXg+Mbp3gn9qKUzSF/P/p8nQ5Mp8hFYfkkmE4bpkShi8ckCawDbGBvnGJGQ1nLlMaXEt IpM3Wvz89V66H2BWfT0rk75PdqKcBHX/MO3YPvT4gV7fbKzDgTbDKjD4yVMZaJm0uVqF 80XPZGdG13tXnsXUJ/ZLtNIAt4wGeGvzOtAan99jKePNKm9EXTjEHVErIN5Arr8rrJvM PocA== X-Gm-Message-State: AOAM533fV4iGWpne3iFgfGtqIYzrHzdVijuFKi9Tv8X3huN63CnMth7I oghpXAKylIPIH2ean1GixLb9/FxybFaf1CCtZ54= X-Google-Smtp-Source: ABdhPJx0FUhCiA97R26Z9mnghMGEbDynvu1gEXuXsE8kR5t77221tzQ4QQBEqU4/BsnNqNJUo60MmSrAU0WD4tfJB3U= X-Received: by 2002:adf:ee0f:: with SMTP id y15mr4154127wrn.76.1594892301284; Thu, 16 Jul 2020 02:38:21 -0700 (PDT) MIME-Version: 1.0 References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <20200710125843.GA224527@LK-Perkele-VII> In-Reply-To: <20200710125843.GA224527@LK-Perkele-VII> From: =?UTF-8?Q?Joel_H=C3=B6glund?= Date: Thu, 16 Jul 2020 11:38:06 +0200 Message-ID: To: Ilari Liusvaara Cc: cose@ietf.org, draft-raza-ace-cbor-certificates@ietf.org Content-Type: multipart/alternative; boundary="00000000000012b80605aa8bcd0e" Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 16 Jul 2020 09:38:25 -0000 --00000000000012b80605aa8bcd0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi! Ilari Liusvaara, we are grateful for your detailed comments, and constructive proposals. With an extra thank you for sharing your insights on which field types that are actually in common use. Your comments highlight the need to further discuss trade-offs between compactness, generality and ease of implementation. As you might have seen, we have merged and updated the old cbor certificate related drafts into one (draft-mattsson-cose-cbor-cert-compress-01) where we have added some more details regarding encoding and optimizations. We will look closer to the implications of your proposals as input for upcoming revisions. Best Regards Joel H=C3=B6glund On Fri, 10 Jul 2020 at 14:58, Ilari Liusvaara wrote: > On Thu, Jul 09, 2020 at 10:02:15PM +0200, Joel H=C3=B6glund wrote: > > Hi Henk and all! > > > > Thank you for your comments and update proposals! > > > > > > In brief, there is definitely a need to clarify the assumptions about > > existing x509 data structures we want to encode, and probably in some > cases > > make the proposal more general to allow more valid rfc7925 certificates= . > > Some further comments to the highlighted issues follows. > > > > 1. About Issuer-field encodings: We would like to have more discussions > on > > if for instance your directoryString proposal is necessary, or if the > > string types can be assumed -- hopefully with input from others with > > experience of how Issuer-fields normally are encoded. > > I would say that the encoding of the issuer (and subject) fields is the > most difficult part. > > Looking at the definition of issuer/subject, it is essentially: > List> > > Which is bit unfortunate in two ways: > > - Set of pairs is not the same as dictionary. > - The right hand side type is Any, and not DirectoryString. > - The outer list is usually of size 1. > > If one really wanted to eke bytes, one could have either 1 or 2 > lists, since the the first element of inner list can not possibly be > a list itself. If one goes for implementation complexity at cost of > wire size, then one would always have 2 lists. > > And then one could have the Oid be encoded as integer for common > ones and bstr for not-common ones. > > And the value could be str, which tries to autoguess the correct type, > or bstr containing asn1tag+value as escape. > > The type autoguess would guess PrintableString if every character is > valid for PrintableString, else it would guess Utf8String. In practice, > I do not think anybody uses any other ones (and wrong guess would be > just 1 byte penalty, unless name is 24 bytes, then it would be 2 byte > penalty). > > Then there is the special case where subject is empty. That could be > encoded as empty list. > > > > 2. About algorithm parameters: Our current assumption is that for our > > target certificates, all needed algorithm info can be represented using > > only the subjectPublicKeyInfo_algorithm field. > > Note that in practice, there are very few different SubjectPublicKeyInfo > field types in any sort of wide use. Anything else is extremely rare. > > Thus, one could compress the field by having integer for type, and bstr > for contents. And perhaps bstr type and bstr contents as escape hatch > (maybe even with the bit stripping octet retained), should that be ever > needed (that would not increase size in common case). > > For instance, types could be: > > 0 =3D> X25519/X448 > 1 =3D> Ed25519/Ed448 > 2 =3D> ECDSA P-256/P-384/P-521. > > The type overloads are resolvable. > > For instance, this encoding could encode Ed25519 or X25519 key to 35 > bytes (3 bytes overhead). > > And with regards to signature algorithm (which is actually encoded twic > in X.509!), the common case is a few actually used algorithms. E.g.: > > 0 =3D> Ed25519 > 1 =3D> Ed448 > 2 =3D> ECDSA SHA-256 > 3 =3D> ECDSA SHA-384 > 4 =3D> ECDSA SHA-512 > 5 =3D> ECDSA SHAKE-128 > 6 =3D> ECDSA SHAKE-256 > > That goes to 1 byte (and of course one could have bstr escape without > affecting common case). > > > > 3. About a general extension oid-mapping: We believe the four extension= s > > mandated by rfc7925 should suffice, but are open for hearing about IoT > > requirements that go beyond those four. > > Extensions could be encoded as array of pairs (one would not want map > here due to order-sensitivity). > > One could have generic encoding by having integers encode known > extensions (negative integers encoding critiality) and bstrs encode > escapes (the value of escape would be optional critical flag and then > the raw extension value, which is an octet string). Known extensions > would have more specialzed encodings. > > Examples of what could be more specialized encodings: > > KeyUsage: Integer value + (1 << bits). > > This would not allow KeyUsage bits above 63th, but I do not think > the number of defined bits is anywhere close to that (RFC5280 defines > 9 bits). > > And things could turn real annoying if KeyUsage ever needs to set any > bit above 63rd. Sure, one could escape the thing, but relying parties > might puke on that. None of the other three extensions ever needs > escaping for any reasonable value. > > ExtendedKeyUsage: List of integer / bstr > > Integers would encode some common key usages, bstrs would be escapes > (with just values). > > BasicConstraints: null/true/uint > > Null encodes empty extension, true encodes just true, and int would > encode true followed by max path length. > > SubjectAlternativeName: array of bstr > > The bstrs are asn1tag+value. Thus e.g. "foo.example" is encoded as: > 4C 82 "foo.example". Encoding IPv4 address would take 6 bytes, IPv6 > address would take 18 (2 bytes overhead in both cases). > > > The difficulty of adding extension beyond these four would depend on > the extension. There would be slots for 24 compact extensions (20 more > than here), 232 bit less compact ones, etc... > > Looking at the extension list from RFC5280, the only ones that do not > look like unsuitable for IoT are subject/authority key ID extensions. > Besides the incompatible encodings, if PKI is not crazy, one can use > issuer/subject fields as key identifiers (however, comparing the above > subject/issuer encoding could be annoying). So these do not look > important. > > > Looking at the other fields, how those could be encoded: > > - version: Implicit from presence of optional fields. > - serial_number: bstr (with initial 00 if any stripped). > - validity: pair of integers (unix timestamps). The time format would > depend on range (-631152000 to 2524607999 is UtcTime). Maybe bstr > with asn1tag+value as escape in case of misencoded certificate. > - issuerUniqueID/subjectUniqueID absent, null or bstr (including the > strip bits byte). If subjectUniqueID is present, issuerUniqueID > has to be as well. > > > Looking at these rules, this could encode a lot more than just rfc7925 > certificates, as there is an escape for nearly everything. The only > obvious thing with no escape is the serial_number, but any violation > there would be fatal ASN.1 error anyway. These should even give valid > compression/decompression for webpki certificates, even if bad one, > due to the junk present. > > I have not written any proof-of-concept code for this. So no performance > numbers to give. > > > -Ilari > --00000000000012b80605aa8bcd0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi!


Ilari Liusvaara, = we are grateful for your detailed comments, and constructive proposals. Wit= h an extra thank you for sharing your insights on which field types that ar= e actually in common use. Your comments highlight the need to further discu= ss trade-offs between compactness, generality and ease of implementation.


As you might have seen, we have merged and updated the old = cbor certificate related drafts into one (draft-mattsson-cose-cbor-cert-com= press-01) where we have added some more details regarding encoding and opti= mizations. We will look closer to the implications of your proposals as inp= ut for upcoming revisions.


Best Regards


J= oel H=C3=B6glund



On Fri, 10 Jul 2020 at 14:58, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Thu, Jul 09, 2020 at 10:= 02:15PM +0200, Joel H=C3=B6glund wrote:
> Hi Henk and all!
>
> Thank you for your comments and update proposals!
>
>
> In brief, there is definitely a need to clarify the assumptions about<= br> > existing x509 data structures we want to encode, and probably in some = cases
> make the proposal more general to allow more valid rfc7925 certificate= s.
> Some further comments to the highlighted issues follows.
>
> 1. About Issuer-field encodings: We would like to have more discussion= s on
> if for instance your directoryString proposal is necessary, or if the<= br> > string types can be assumed -- hopefully with input from others with > experience of how Issuer-fields normally are encoded.

I would say that the encoding of the issuer (and subject) fields is the
most difficult part.

Looking at the definition of issuer/subject, it is essentially:
List<Set<(Oid, Any)>>

Which is bit unfortunate in two ways:

- Set of pairs is not the same as dictionary.
- The right hand side type is Any, and not DirectoryString.
- The outer list is usually of size 1.

If one really wanted to eke bytes, one could have either 1 or 2
lists, since the the first element of inner list can not possibly be
a list itself. If one goes for implementation complexity at cost of
wire size, then one would always have 2 lists.

And then one could have the Oid be encoded as integer for common
ones and bstr for not-common ones.

And the value could be str, which tries to autoguess the correct type,
or bstr containing asn1tag+value as escape.

The type autoguess would guess PrintableString if every character is
valid for PrintableString, else it would guess Utf8String. In practice,
I do not think anybody uses any other ones (and wrong guess would be
just 1 byte penalty, unless name is 24 bytes, then it would be 2 byte
penalty).

Then there is the special case where subject is empty. That could be
encoded as empty list.


> 2. About algorithm parameters: Our current assumption is that for our<= br> > target certificates, all needed algorithm info can be represented usin= g
> only the subjectPublicKeyInfo_algorithm field.

Note that in practice, there are very few different SubjectPublicKeyInfo field types in any sort of wide use. Anything else is extremely rare.

Thus, one could compress the field by having integer for type, and bstr
for contents. And perhaps bstr type and bstr contents as escape hatch
(maybe even with the bit stripping octet retained), should that be ever
needed (that would not increase size in common case).

For instance, types could be:

0 =3D> X25519/X448
1 =3D> Ed25519/Ed448
2 =3D> ECDSA P-256/P-384/P-521.

The type overloads are resolvable.

For instance, this encoding could encode Ed25519 or X25519 key to 35
bytes (3 bytes overhead).

And with regards to signature algorithm (which is actually encoded twic
in X.509!), the common case is a few actually used algorithms. E.g.:

0 =3D> Ed25519
1 =3D> Ed448
2 =3D> ECDSA SHA-256
3 =3D> ECDSA SHA-384
4 =3D> ECDSA SHA-512
5 =3D> ECDSA SHAKE-128
6 =3D> ECDSA SHAKE-256

That goes to 1 byte (and of course one could have bstr escape without
affecting common case).


> 3. About a general extension oid-mapping: We believe the four extensio= ns
> mandated by rfc7925 should suffice, but are open for hearing about IoT=
> requirements that go beyond those four.

Extensions could be encoded as array of pairs (one would not want map
here due to order-sensitivity).

One could have generic encoding by having integers encode known
extensions (negative integers encoding critiality) and bstrs encode
escapes (the value of escape would be optional critical flag and then
the raw extension value, which is an octet string). Known extensions
would have more specialzed encodings.

Examples of what could be more specialized encodings:

KeyUsage: Integer value + (1 << bits).

This would not allow KeyUsage bits above 63th, but I do not think
the number of defined bits is anywhere close to that (RFC5280 defines
9 bits).

And things could turn real annoying if KeyUsage ever needs to set any
bit above 63rd. Sure, one could escape the thing, but relying parties
might puke on that. None of the other three extensions ever needs
escaping for any reasonable value.

ExtendedKeyUsage: List of integer / bstr

Integers would encode some common key usages, bstrs would be escapes
(with just values).

BasicConstraints: null/true/uint

Null encodes empty extension, true encodes just true, and int would
encode true followed by max path length.

SubjectAlternativeName: array of bstr

The bstrs are asn1tag+value. Thus e.g. "foo.example" is encoded a= s:
4C 82 "foo.example". Encoding IPv4 address would take 6 bytes, IP= v6
address would take 18 (2 bytes overhead in both cases).


The difficulty of adding extension beyond these four would depend on
the extension. There would be slots for 24 compact extensions (20 more
than here), 232 bit less compact ones, etc...

Looking at the extension list from RFC5280, the only ones that do not
look like unsuitable for IoT are subject/authority key ID extensions.
Besides the incompatible encodings, if PKI is not crazy, one can use
issuer/subject fields as key identifiers (however, comparing the above
subject/issuer encoding could be annoying). So these do not look
important.


Looking at the other fields, how those could be encoded:

- version: Implicit from presence of optional fields.
- serial_number: bstr (with initial 00 if any stripped).
- validity: pair of integers (unix timestamps). The time format would
=C2=A0 depend on range (-631152000 to 2524607999 is UtcTime). Maybe bstr =C2=A0 with asn1tag+value as escape in case of misencoded certificate.
- issuerUniqueID/subjectUniqueID absent, null or bstr (including the
=C2=A0 strip bits byte). If subjectUniqueID is present, issuerUniqueID
=C2=A0 has to be as well.


Looking at these rules, this could encode a lot more than just rfc7925
certificates, as there is an escape for nearly everything. The only
obvious thing with no escape is the serial_number, but any violation
there would be fatal ASN.1 error anyway. These should even give valid
compression/decompression for webpki certificates, even if bad one,
due to the junk present.

I have not written any proof-of-concept code for this. So no performance numbers to give.


-Ilari
--00000000000012b80605aa8bcd0e-- From nobody Mon Jul 20 09:01: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 85F3D3A0CB1 for ; Mon, 20 Jul 2020 09:01: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, 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=outer-planes-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 W-JQ9sQJ0NyB for ; Mon, 20 Jul 2020 09:01:37 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 094D83A0CAF for ; Mon, 20 Jul 2020 09:01:36 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id a21so12578099otq.8 for ; Mon, 20 Jul 2020 09:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:autocrypt:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=QowtebwNv/nWqXOTH0nb+CbDYNu2pPu2OTXpRAgVH8s=; b=ba1BB6BYjC7ppbjioyT/3MYdzkHNqgC4finZDJSR0iPYjojs+2LqnyTsdex9X8rBx5 gzwwVxJzUthMCuUFP63Yl1Jv+IHumliBTwUZ7oaG+s9To0awwDSp6aYdjf7ITaJAo5/C LQDsbc18nCqkRRxKuxSDy5se8dPUnOJuqfQec4i1Y4h9BJaFFv9G/AZZA0soPsDZN1oI O4hTWfG8C2KE0FBkMSKDIJEE167pnw5kmoNMJSjPiZIcdYy/wr21Ias203k8H5MSkqoT 08ma9G3ptYvRzh9ozRVgOtVSqoJv0xhzd8Sh/19ZQB2C2psIIecBwGtMSeFAU6fp2Raj zxJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:autocrypt:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=QowtebwNv/nWqXOTH0nb+CbDYNu2pPu2OTXpRAgVH8s=; b=nfKP/buUVWXTzpSeUwLosuLzlhmTU9D17agyDrLakls/95zt2GSSyb2uY3j1Ij4hZJ 9RoxPMKUjAYzRfxOgL13bbnb5jZV1WchAnCC3K80QmQPl6HGrIe4jKnewDIhVg+0VSOA 5/JcGx7VA+Q/BJE2/cGgQ5ulQ3E6bEp9SXCpuJaxs4o9Ggph069BmPCZfIszoB4TzR5h 6RYQyaSFrtHl61s/ZCn7hCbQ3If8EA9v7trHTSzWBLfcHNpAeKBXmAknAVTqhfmPSBJx x5r92PMpNwsDLwK2zURZ9d3Q6jLEW/j9N3IHmiRA0tMievJ4NsqBecXCSOr8j6Y5qxtl r1QA== X-Gm-Message-State: AOAM532hH6JYgluNe2IpQy+U0k+XsuWbFL/4yX17wInNbsrGhTinvnJz 9AyiNatvrWay1oDBZ+TYuzEJolyz2Zk= X-Google-Smtp-Source: ABdhPJx7mHJfsGfjyMaOSL3vBpOj0S3r/zM07stFhdQImkhjEMRji1HzGzb++XAaW58sxfuW/F5XoA== X-Received: by 2002:a9d:6d03:: with SMTP id o3mr19939312otp.343.1595260895576; Mon, 20 Jul 2020 09:01:35 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:9854:bbbb:3cf3:7050]) by smtp.gmail.com with ESMTPSA id t22sm3589754otl.73.2020.07.20.09.01.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jul 2020 09:01:34 -0700 (PDT) To: cose From: "Matthew A. Miller" Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBDHXWI3skGkNa8yY4Oz0 ck4QngW7BQJeDg4fBQkVMJSlAAoJEOz0ck4QngW7XCcH/RBVW3Nd0ezXtL9XSn5DHJxRTb5q 6ZVIBQgVIMcH2DVzO/aCs3o1ECONHAazVGQ9b6cwHCtPWJpM0ENGx7DERa/Ay4vDeKXc1TEX VuukdGrX2zWOaFHDT/oU1SEg0C+f3JGnaTwYQ7i2KXkFuYNmqROkB+Z0PDaLu4biCYdjhkIm Yu3frzySHhEX2VVMcJA6lcqdBTE3j2+ywQ7icpiWUcvLuhCeuFER1JjTRchcXwtuiOAKPQCZ BM9B70Q73hiKKK4ylNjhLFKGomkWDqsQ6sAENn6YkWyBuXNr5Y66uFxFS0VY938o/ZoXw4tb qUIdBzMnHkHxxiNUUBb6dPkaEGO5AQ0EUmgCigEIAMD+u4fBiVDul2Mljq3CRlwyZ52RA0vq vm00F5CTBWu+K1SMdMoqKmPEHaQSRRmjE+AwjWHv96cOtWUwwyqrpEgnzof7LHXfM0hk0GUl +ZUeAePtNPyylroD+ohxx2IhE2wVW+W8XGkfyxONVsd89h7Ft05HmQellZPNjE3JUtcwrmN6 fQHgr6+NuAUkC+ygt/MtnkHPeRvp2m7FQ3OqEPKGTn9Q9oIgW9lYG2JEqaSo/ASrwbZowmrl nhKvwJGSmgwHbmvEI9LxH4HKIfGmr5TyYq6o9WDUsnNwDuEeaazxoE3qXFKVvIqfMSDwBaCV 37r7GUle7lT9+oMAKVOPmZ8AEQEAAYkBPAQYAQoAJgIbDBYhBDHXWI3skGkNa8yY4Oz0ck4Q ngW7BQJeM+W5BQkPjlg/AAoJEOz0ck4QngW7a+IIANBU7R3t17LKflQo3nSUoqMBLkjxo9/e yzKAb3u0Fjb5md+9ESrFb03w1ZUkKLh/b6leTFq50IJbfxgDlVgkTn/j0XPOmIHpfDtVYPnA /rI5sqMzjb3qFOPFZFX9Til360uv9Zc5mlkJcM57X4aLRl7wSGRXPqh7v356s+JlvLF8rBtZ 7LU5SrCWeoWZu/7NvqW+UNEOOP2xAlOId4BeYWflkpzNcSPkhAkD2Xvw/GmyOm24Im7Ef2O5 scQhEO/dG+3jU4QnSGFtLXHndHpNM20vD6T+uWUpyp5g27KrIHApWq9M3o6KR68pTOLJrMxc th8xmHLOpuWVAKEABNQRDfE= Message-ID: <050fc5f8-7053-0e8a-acf2-0ffcba1bc71f@outer-planes.net> Date: Mon, 20 Jul 2020 10:01:30 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [COSE] Preliminary Agenda and Call for Items @ IETF 108 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, 20 Jul 2020 16:01:39 -0000 This is well overdue, but here is a preliminary agenda based on activities. If anyone has more to discuss, please alert the chairs. The COSE WG session is scheduled for 50 minutes on Wednesday, 20 July at 11:00 UTC. Note this is quite early for those of located in western North America (including a document author and a co-chair); bear with any grogginess. < https://www.ietf.org/proceedings/108/agenda/agenda-108-cose-00.txt > """ COSE WG Agenda IETF 108 - Virtual/Meetecho 2020-07-29 @ 11:00 UTC ## 0. Administrivia (Chairs) - 5 minutes * NOTE WELL * Bluesheets * Jabber + Minutes * Agenda Bartering ## 1. Document Status (Chairs) - 10 minutes * https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/ * https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ * https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ * https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ * https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ ## 2. Cert Compression (Joel Höglund) - 10 minutes * https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-01 ## 3. Chartering (Chairs) - 20 minutes * (WIP) https://github.com/cose-wg/Charter/blob/master/Charter.md ## 4. AOB """ -- Ivaylo and Matthew COSE Chairs From nobody Mon Jul 20 13:30: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 217DF3A0F12 for ; Mon, 20 Jul 2020 13:30:16 -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 L8Z9mj_yIRzM for ; Mon, 20 Jul 2020 13:30:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 307FA3A0EF9 for ; Mon, 20 Jul 2020 13:30:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id ECDF138A0C; Mon, 20 Jul 2020 16:09:40 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fGeSJioDu24E; Mon, 20 Jul 2020 16:09:39 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A043138A0A; Mon, 20 Jul 2020 16:09:39 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7DD733F; Mon, 20 Jul 2020 16:30:02 -0400 (EDT) From: Michael Richardson To: cose@ietf.org, Mike Jones X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [COSE] implementations of RFC8152 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, 20 Jul 2020 20:30:22 -0000 --=-=-= Content-Type: text/plain Hi, Is the WG aware of any formal (cryptographic) reviews of RFC7515 and RFC8152? Was there an implementation report when 8152 was published? While I'm aware of many of the IETF efforts that leverage COSE, is there any data on how it has been used outside of the IETF? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8V/soACgkQgItw+93Q 3WUqrgf+KdOdhAiVmlGIuW3L9AbbZbLRmVfcD/b4AYx0ZaUS9ULdMYDtSNnPxMYl R0c1AAfn/WlbEqkrcqy/fzIH/pygjLs62cA+jZ/93RKITVdU/sG7M5N6Fo8UvNx4 sewyXIFqUMrZYZr0hiS4VsZ7eGUSIvyW7qqtnkz3rX8tH3SzUj4IeGXI2pKUipp4 lw2j66cH2xNeBeydpp/cEDfg34l0AdJhyBa7fWZV1b2GEQOpZQP6HtRzgsQMKUw8 1e1amv+IaK+G88S1Qmy9/nbJ4eKkTmjAGxXOnDdL8RY/cRGyQH0vJX9Cs37Bp9bx 0t73UfZMPHDopeft3CpA0OmjoePuPw== =+J23 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 20 14:03:41 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 E1F1A3A0F8F for ; Mon, 20 Jul 2020 14:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAPZiR1YhkxF for ; Mon, 20 Jul 2020 14:03: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 7F22E3A0F8C for ; Mon, 20 Jul 2020 14:03: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; Mon, 20 Jul 2020 14:03:30 -0700 From: Jim Schaad To: 'Michael Richardson' , , 'Mike Jones' References: <19246.1595277002@localhost> In-Reply-To: <19246.1595277002@localhost> Date: Mon, 20 Jul 2020 14:03:28 -0700 Message-ID: <006101d65ed9$3928d5e0$ab7a81a0$@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: AQE33Buuj6OaOFTIAozoOJYLxvMVmqpN9kFg Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] implementations of RFC8152 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, 20 Jul 2020 21:03:39 -0000 > -----Original Message----- > From: COSE On Behalf Of Michael Richardson > Sent: Monday, July 20, 2020 1:30 PM > To: cose@ietf.org; Mike Jones > Subject: [COSE] implementations of RFC8152 > > > Hi, > > Is the WG aware of any formal (cryptographic) reviews of RFC7515 and > RFC8152? [JLS] I am not too sure of what you mean by a cryptographic review, but I suspect that the answer is no. There have been some community reviews of RFC 7515 which point to issues that need to be kept in mind, such as the existence of the None signature algorithm. I don't remember seeing anything for RFC 8152 which was not along the lines of - it must have the same issues as RFC 7515. > > Was there an implementation report when 8152 was published? [JLS] Yes there was. > While I'm aware of many of the IETF efforts that leverage COSE, is there any > data on how it has been used outside of the IETF? [JLS] There are a couple of different projects at the W3C. Web Authentication is one and Secure Data Storage is another. There is an ISO driving license standard that I have see reference (ISO/IEC JTC 001/SC 17 "Cards and security devices for personal identification" Mobile Driver's License (mDL)). A couple of people have talked to me about potentially using COSE rather than CMS but needing certificates to do so. I can't remember who off the top of my head. Jim > > -- > Michael Richardson , Sandelman Software Works - > = IPv6 IoT consulting =- > > From nobody Tue Jul 21 04:50: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 699353A0475 for ; Tue, 21 Jul 2020 04:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, SPF_HELO_NONE=0.001, SPF_NONE=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 lVDymdUXPfe2 for ; Tue, 21 Jul 2020 04:50:16 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1b.welho.com [83.102.41.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8D83A046D for ; Tue, 21 Jul 2020 04:50:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 7B71560788; Tue, 21 Jul 2020 14:50:13 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id qzLHyItjOcEM; Tue, 21 Jul 2020 14:50:13 +0300 (EEST) Received: from LK-Perkele-VII (84-253-234-84.bb.dnainternet.fi [84.253.234.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 07BDB7A; Tue, 21 Jul 2020 14:50:10 +0300 (EEST) Date: Tue, 21 Jul 2020 14:50:09 +0300 From: Ilari Liusvaara To: Joel =?utf-8?Q?H=C3=B6glund?= Cc: cose@ietf.org Message-ID: <20200721115009.GB464556@LK-Perkele-VII> References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <20200710125843.GA224527@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 21 Jul 2020 11:50:18 -0000 On Thu, Jul 16, 2020 at 11:38:06AM +0200, Joel Höglund wrote: > Hi! > > Ilari Liusvaara, we are grateful for your detailed comments, and > constructive proposals. With an extra thank you for sharing your insights > on which field types that are actually in common use. Your comments > highlight the need to further discuss trade-offs between compactness, > generality and ease of implementation. The principles I followed were mostly: - Try to do something simple, yet compact in common cases. The solution may or may not be pareto-optimal. And even if it is pareto-optimal, it may or may not be the best. - Offer escape hatches, unless fundamential PKIX limitation. - Minimize the impact of escape hatches on common case (mostly no impact). - Check RFC7925 for the most important extensions, then check RFC5280 to see if there are more extensions that could be considered important (turns out there are none that are not iffy). There are some simple optimizations left. For example, one could encode CN-only names as just tstr/bstr, like is done in draft-mattsson-cose-cbor-cert-compress-01. This would save 2 bytes for such name (by eliminating array and integer type tag). > As you might have seen, we have merged and updated the old cbor certificate > related drafts into one (draft-mattsson-cose-cbor-cert-compress-01) where > we have added some more details regarding encoding and optimizations. We > will look closer to the implications of your proposals as input for > upcoming revisions. The approach in draft-mattsson-cose-cbor-cert-compress-01 seems much more specialized. It will probably be at least a few bytes more compact than what I came up with, but can encode much fewer certificates (which still may be plenty). Some issues I noted in draft-mattsson-cose-cbor-cert-compress-01: 1) The encoded certificates may be CA certificates, which would presumably indicate that issuer certificate can be explicitly encoded. There are at least two issues with encoding such certificates: a) because subject of issuer must equal issuer of subject (preferably bitwise), and subject is CN-only the name of any such CA is restricted to be CN-only. Which is not really sufficient for CAs, as I would also at least expect unique identifier of the organization. b) The issuing certificates commonly have Pathlen=0, which is not RFC7925-compliant, and is not possible to encode. If it is not intended to have explicit issuers, one could remove the CA flag entierely, and assume that BasicConstraints is always empty. 2) ExtendedKeyUsage is not fixed-order: ExtendedKeyUsage is SEQUENCE of OBJECT IDENTIFIER. Neither RFC5280 nor RFC7925 define order. So presumably the order used is CA- dependent, and does affect the signature. 4 bits is not sufficient to represent non-empty ordered subsets of 4 elements. One needs at least 6 bits for that. However, one could fit the thing in 4 bits by noting that combining id-kp-OCSPSigning with anything else is Bad Idea. And non-empty ordered subset of mutually exclusive sets of 3+1 elements does fit in 4 bits (A, B, C, AB, AC, BA, BC, CA, CB, ABC, ACB, BAC, BCA, CAB, CBA, Z). 3) id-kp-serverAuth/id-kp-clientAuth are TLS-only (the "WWW" in the description should read "TLS"). This does also encompass DTLS (and future cTLS). But it does not encompass EDHOC. EDHOC uses signatures in way incompatible with TLS, and using the same key in multiple incompatible ways is not a good idea. Altough none of COSE, JWS, X.509 and TLS 1.3 interact harmfully (for pretty obvious reasons), e.g., analyzing if TLS 1.2 and COSE would interact harmfully is not trivial. EDHOC would need its own ExtendedKeyUsage values. And those can not be encoded within RFC7925 profile (encoding non-empty ordered subset of mutually exclusive sets of 5+1 elements would need 9 bits to encode (as there are 326 possibilities)). 4) The draft uses TLS certificate compression instead of TLS certificate types. These two have different semantics: - TLS certificate types are about encoding of a single certificate (it is assumed that all the certificates in chain are of the same type). This seems to match with what this draft is doing. - TLS certificate compression compresses the entiere TLS certificate messages in one go. With potentially many certificates, and extension blocks for each (which are used, e.g., for OCSP). It is only meant to be used with possibly specialized general- purpose lossless data compressors (meaning can produce valid, but possibly not well-compressed, bytestream for any input). Even the much more general compressor I outlined is not even close to general-purpose (as there are plenty of inputs where it can not produce a valid bytestream). And TLS certificate compression and TLS certificate types can both be used at once. In this case the decompression is expected to produce certificate(s) of correct type. If it does not, the certificates(s) very likely get parsed wrong (hopefully running into fatal parse error). > > On Fri, 10 Jul 2020 at 14:58, Ilari Liusvaara > wrote: > > > On Thu, Jul 09, 2020 at 10:02:15PM +0200, Joel Höglund wrote: > > > Hi Henk and all! > > > > > > Thank you for your comments and update proposals! > > > > > > > > > In brief, there is definitely a need to clarify the assumptions about > > > existing x509 data structures we want to encode, and probably in some > > cases > > > make the proposal more general to allow more valid rfc7925 certificates. > > > Some further comments to the highlighted issues follows. > > > > > > 1. About Issuer-field encodings: We would like to have more discussions > > on > > > if for instance your directoryString proposal is necessary, or if the > > > string types can be assumed -- hopefully with input from others with > > > experience of how Issuer-fields normally are encoded. > > > > I would say that the encoding of the issuer (and subject) fields is the > > most difficult part. > > > > Looking at the definition of issuer/subject, it is essentially: > > List> > > > > Which is bit unfortunate in two ways: > > > > - Set of pairs is not the same as dictionary. > > - The right hand side type is Any, and not DirectoryString. > > - The outer list is usually of size 1. > > > > If one really wanted to eke bytes, one could have either 1 or 2 > > lists, since the the first element of inner list can not possibly be > > a list itself. If one goes for implementation complexity at cost of > > wire size, then one would always have 2 lists. > > > > And then one could have the Oid be encoded as integer for common > > ones and bstr for not-common ones. > > > > And the value could be str, which tries to autoguess the correct type, > > or bstr containing asn1tag+value as escape. > > > > The type autoguess would guess PrintableString if every character is > > valid for PrintableString, else it would guess Utf8String. In practice, > > I do not think anybody uses any other ones (and wrong guess would be > > just 1 byte penalty, unless name is 24 bytes, then it would be 2 byte > > penalty). > > > > Then there is the special case where subject is empty. That could be > > encoded as empty list. > > > > > > > 2. About algorithm parameters: Our current assumption is that for our > > > target certificates, all needed algorithm info can be represented using > > > only the subjectPublicKeyInfo_algorithm field. > > > > Note that in practice, there are very few different SubjectPublicKeyInfo > > field types in any sort of wide use. Anything else is extremely rare. > > > > Thus, one could compress the field by having integer for type, and bstr > > for contents. And perhaps bstr type and bstr contents as escape hatch > > (maybe even with the bit stripping octet retained), should that be ever > > needed (that would not increase size in common case). > > > > For instance, types could be: > > > > 0 => X25519/X448 > > 1 => Ed25519/Ed448 > > 2 => ECDSA P-256/P-384/P-521. > > > > The type overloads are resolvable. > > > > For instance, this encoding could encode Ed25519 or X25519 key to 35 > > bytes (3 bytes overhead). > > > > And with regards to signature algorithm (which is actually encoded twic > > in X.509!), the common case is a few actually used algorithms. E.g.: > > > > 0 => Ed25519 > > 1 => Ed448 > > 2 => ECDSA SHA-256 > > 3 => ECDSA SHA-384 > > 4 => ECDSA SHA-512 > > 5 => ECDSA SHAKE-128 > > 6 => ECDSA SHAKE-256 > > > > That goes to 1 byte (and of course one could have bstr escape without > > affecting common case). > > > > > > > 3. About a general extension oid-mapping: We believe the four extensions > > > mandated by rfc7925 should suffice, but are open for hearing about IoT > > > requirements that go beyond those four. > > > > Extensions could be encoded as array of pairs (one would not want map > > here due to order-sensitivity). > > > > One could have generic encoding by having integers encode known > > extensions (negative integers encoding critiality) and bstrs encode > > escapes (the value of escape would be optional critical flag and then > > the raw extension value, which is an octet string). Known extensions > > would have more specialzed encodings. > > > > Examples of what could be more specialized encodings: > > > > KeyUsage: Integer value + (1 << bits). > > > > This would not allow KeyUsage bits above 63th, but I do not think > > the number of defined bits is anywhere close to that (RFC5280 defines > > 9 bits). > > > > And things could turn real annoying if KeyUsage ever needs to set any > > bit above 63rd. Sure, one could escape the thing, but relying parties > > might puke on that. None of the other three extensions ever needs > > escaping for any reasonable value. > > > > ExtendedKeyUsage: List of integer / bstr > > > > Integers would encode some common key usages, bstrs would be escapes > > (with just values). > > > > BasicConstraints: null/true/uint > > > > Null encodes empty extension, true encodes just true, and int would > > encode true followed by max path length. > > > > SubjectAlternativeName: array of bstr > > > > The bstrs are asn1tag+value. Thus e.g. "foo.example" is encoded as: > > 4C 82 "foo.example". Encoding IPv4 address would take 6 bytes, IPv6 > > address would take 18 (2 bytes overhead in both cases). > > > > > > The difficulty of adding extension beyond these four would depend on > > the extension. There would be slots for 24 compact extensions (20 more > > than here), 232 bit less compact ones, etc... > > > > Looking at the extension list from RFC5280, the only ones that do not > > look like unsuitable for IoT are subject/authority key ID extensions. > > Besides the incompatible encodings, if PKI is not crazy, one can use > > issuer/subject fields as key identifiers (however, comparing the above > > subject/issuer encoding could be annoying). So these do not look > > important. > > > > > > Looking at the other fields, how those could be encoded: > > > > - version: Implicit from presence of optional fields. > > - serial_number: bstr (with initial 00 if any stripped). > > - validity: pair of integers (unix timestamps). The time format would > > depend on range (-631152000 to 2524607999 is UtcTime). Maybe bstr > > with asn1tag+value as escape in case of misencoded certificate. > > - issuerUniqueID/subjectUniqueID absent, null or bstr (including the > > strip bits byte). If subjectUniqueID is present, issuerUniqueID > > has to be as well. > > > > > > Looking at these rules, this could encode a lot more than just rfc7925 > > certificates, as there is an escape for nearly everything. The only > > obvious thing with no escape is the serial_number, but any violation > > there would be fatal ASN.1 error anyway. These should even give valid > > compression/decompression for webpki certificates, even if bad one, > > due to the junk present. > > > > I have not written any proof-of-concept code for this. So no performance > > numbers to give. > > > > > > -Ilari > > -Ilari From nobody Tue Jul 21 08:58:26 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 A7AC23A0B4D for ; Tue, 21 Jul 2020 08:58:24 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 V7M_h9aq29IL for ; Tue, 21 Jul 2020 08:58:23 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0313A0B4C for ; Tue, 21 Jul 2020 08:58:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4681B300B22 for ; Tue, 21 Jul 2020 11:58:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tT3Go6HL6u5t for ; Tue, 21 Jul 2020 11:58:18 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 07AA0300595; Tue, 21 Jul 2020 11:58:17 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: <20200721115009.GB464556@LK-Perkele-VII> Date: Tue, 21 Jul 2020 11:58:19 -0400 Cc: =?utf-8?Q?Joel_H=C3=B6glund?= , cose@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <20200710125843.GA224527@LK-Perkele-VII> <20200721115009.GB464556@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 21 Jul 2020 15:58:25 -0000 A few thoughts inline ... > On Jul 21, 2020, at 7:50 AM, Ilari Liusvaara = wrote: >=20 > On Thu, Jul 16, 2020 at 11:38:06AM +0200, Joel H=C3=B6glund wrote: >> Hi! >>=20 >> Ilari Liusvaara, we are grateful for your detailed comments, and >> constructive proposals. With an extra thank you for sharing your = insights >> on which field types that are actually in common use. Your comments >> highlight the need to further discuss trade-offs between compactness, >> generality and ease of implementation. >=20 > The principles I followed were mostly: >=20 > - Try to do something simple, yet compact in common cases. The = solution > may or may not be pareto-optimal. And even if it is pareto-optimal, = it > may or may not be the best. > - Offer escape hatches, unless fundamential PKIX limitation. > - Minimize the impact of escape hatches on common case (mostly no > impact). > - Check RFC7925 for the most important extensions, then check RFC5280 = to > see if there are more extensions that could be considered important > (turns out there are none that are not iffy). >=20 > There are some simple optimizations left. For example, one could = encode > CN-only names as just tstr/bstr, like is done in > draft-mattsson-cose-cbor-cert-compress-01. This would save 2 bytes for > such name (by eliminating array and integer type tag). >=20 >> As you might have seen, we have merged and updated the old cbor = certificate >> related drafts into one (draft-mattsson-cose-cbor-cert-compress-01) = where >> we have added some more details regarding encoding and optimizations. = We >> will look closer to the implications of your proposals as input for >> upcoming revisions. >=20 > The approach in draft-mattsson-cose-cbor-cert-compress-01 seems much > more specialized. It will probably be at least a few bytes more = compact > than what I came up with, but can encode much fewer certificates = (which > still may be plenty). >=20 > Some issues I noted in draft-mattsson-cose-cbor-cert-compress-01: >=20 > 1) The encoded certificates may be CA certificates, which would > presumably indicate that issuer certificate can be explicitly > encoded. >=20 > There are at least two issues with encoding such certificates: >=20 > a) because subject of issuer must equal issuer of subject = (preferably > bitwise), and subject is CN-only the name of any such CA is > restricted to be CN-only. Which is not really sufficient for CAs, > as I would also at least expect unique identifier of the > organization. >=20 > b) The issuing certificates commonly have Pathlen=3D0, which is not > RFC7925-compliant, and is not possible to encode. >=20 > If it is not intended to have explicit issuers, one could remove > the CA flag entierely, and assume that BasicConstraints is always > empty. BasicConstraints ::=3D SEQUENCE { cA BOOLEAN DEFAULT FALSE, pathLenConstraint INTEGER (0..MAX) OPTIONAL } You need a way to be clear the difference between no BasicConstraints at = all and a BasicConstraints with cA=3DFalse and pathLen absent. > 2) ExtendedKeyUsage is not fixed-order: >=20 > ExtendedKeyUsage is SEQUENCE of OBJECT IDENTIFIER. Neither RFC5280 > nor RFC7925 define order. So presumably the order used is CA- > dependent, and does affect the signature. >=20 > 4 bits is not sufficient to represent non-empty ordered subsets > of 4 elements. One needs at least 6 bits for that. >=20 > However, one could fit the thing in 4 bits by noting that combining > id-kp-OCSPSigning with anything else is Bad Idea. And non-empty > ordered subset of mutually exclusive sets of 3+1 elements does > fit in 4 bits (A, B, C, AB, AC, BA, BC, CA, CB, ABC, ACB, BAC, BCA, > CAB, CBA, Z). Yes, a SET OF would have defined an order, but it does not help the = relying party, who only cares about whether a particular OID is in the = SEQUENCE or not. Putting them in the same order as SET OF would work for new = certificates, but it will not help with existing ones. > 3) id-kp-serverAuth/id-kp-clientAuth are TLS-only (the "WWW" in the > description should read "TLS"). This does also encompass DTLS (and > future cTLS). But it does not encompass EDHOC. >=20 > EDHOC uses signatures in way incompatible with TLS, and using the > same key in multiple incompatible ways is not a good idea. Altough > none of COSE, JWS, X.509 and TLS 1.3 interact harmfully (for pretty > obvious reasons), e.g., analyzing if TLS 1.2 and COSE would interact > harmfully is not trivial. >=20 > EDHOC would need its own ExtendedKeyUsage values. And those can > not be encoded within RFC7925 profile (encoding non-empty ordered > subset of mutually exclusive sets of 5+1 elements would need 9 bits > to encode (as there are 326 possibilities)). Agree that new EKU values are needed for this context. Russ From nobody Tue Jul 21 10: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 664953A0C7F for ; Tue, 21 Jul 2020 10:27:47 -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 yresxZpXgZsx for ; Tue, 21 Jul 2020 10:27:45 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96163A0C7E for ; Tue, 21 Jul 2020 10:27:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 407BC38A22; Tue, 21 Jul 2020 13:07:18 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2Qm-DZeuTda2; Tue, 21 Jul 2020 13:07:17 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E7A323899F; Tue, 21 Jul 2020 13:07:16 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4D5B73F; Tue, 21 Jul 2020 13:27:42 -0400 (EDT) From: Michael Richardson To: Jim Schaad cc: cose@ietf.org, 'Mike Jones' In-Reply-To: <006101d65ed9$3928d5e0$ab7a81a0$@augustcellars.com> References: <19246.1595277002@localhost> <006101d65ed9$3928d5e0$ab7a81a0$@augustcellars.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [COSE] implementations of RFC8152 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, 21 Jul 2020 17:27:47 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: >> -----Original Message----- >> From: COSE On Behalf Of Michael Richardson >> Sent: Monday, July 20, 2020 1:30 PM >> To: cose@ietf.org; Mike Jones >> Subject: [COSE] implementations of RFC8152 >> >> >> Hi, >> >> Is the WG aware of any formal (cryptographic) reviews of RFC7515 and >> RFC8152? > [JLS] I am not too sure of what you mean by a cryptographic review, but I > suspect that the answer is no. There have been some community reviews of > RFC 7515 which point to issues that need to be kept in mind, such as the > existence of the None signature algorithm. I don't remember seeing anything > for RFC 8152 which was not along the lines of - it must have the same issues > as RFC 7515. Sorry, I used impresise language because I was tired and frustrated at the time. I'm asking about formal verifications, either at the protocol interaction level, such as was done for IKE recently: https://mailarchive.ietf.org/arch/msg/ipsec/LNEPxxRwNAeWbp2Cjzqb-uS7-No/ and has been planned for EDHOC: https://mailarchive.ietf.org/arch/msg/lake/WGmpD4F9Yb6qCfgwYkF0oKcEqYw which I know has been done for TLS. >> Was there an implementation report when 8152 was published? > [JLS] Yes there was. I looked back through the IDs before RFC, since we usually remove that before publication, but I didn't see it in the ID. I guess it might be in the shepherd write up... Yup. I wish we would get on with having this on the rfc-editor.org pages :-) >> While I'm aware of many of the IETF efforts that leverage COSE, is there > > any >> data on how it has been used outside of the IETF? > [JLS] There are a couple of different projects at the W3C. Web > Authentication is one and Secure Data Storage is another. > There is an ISO > driving license standard that I have see reference (ISO/IEC JTC 001/SC 17 > "Cards and security devices for personal identification" Mobile Driver's > License (mDL)). A couple of people have talked to me about potentially > using COSE rather than CMS but needing certificates to do so. I can't > remember who off the top of my head. Thank you. Is it worth enabling a wiki in https://github.com/cose-wg somewhere to record these things? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8XJY4ACgkQgItw+93Q 3WUpoQgAh6rVfILXw3v2xhpCNLSZZ3eGfunQGPkQJTVBJNdqMUC8UCNWA+e4Zv5P KLoE20rZCDvQSkoQuHv1mC1GLWqQrxDU6d8unWALudZE7HzmHU0tKcZPJwbnaJqp jhfO0LAfR0rQKo+OgJVzdAipQfnqvXfTvJLP8ck4tDJgl2Iv42xx+aDylTQ58Kef s8UurBzeeGD2Rac5kwG3z0JyRFwm+yWzndX8HBUQjU68Ew/E2PohnUdOxQu8ShiV 7HnxvOYQ4Hlx7zC7lL6QWuqUWjBWY9e/NoyDh7JGLF62c7g9PLOK/fYO8HDZpYGY 2ceqVMes9hremB8RI/kyiPs2gq7Miw== =ny2I -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 21 11:07:50 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 314B33A0D4B for ; Tue, 21 Jul 2020 11:07: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 PpU9nJ8gZQFR for ; Tue, 21 Jul 2020 11:07: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 B9F233A0D49 for ; Tue, 21 Jul 2020 11:07:45 -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, 21 Jul 2020 11:07:39 -0700 From: Jim Schaad To: 'Michael Richardson' CC: , 'Mike Jones' References: <19246.1595277002@localhost> <006101d65ed9$3928d5e0$ab7a81a0$@augustcellars.com> <25624.1595352462@localhost> In-Reply-To: <25624.1595352462@localhost> Date: Tue, 21 Jul 2020 11:07:37 -0700 Message-ID: <00f901d65f89$d2be3f50$783abdf0$@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: AQE33Buuj6OaOFTIAozoOJYLxvMVmgIm237XAWHbqNKqMxBfMA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] implementations of RFC8152 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, 21 Jul 2020 18:07:48 -0000 Michael, So here is the problem. For both IPSEC and Lake you are talking about protocols. However COSE is not a protocol but a message encapsulation object. This means that the question of what you are asking about for a protocol becomes more problematic. If we wanted to do the modeling we would need to do it in the context of a protocol. If you are asking - does the protocol exceed the number of blocks of data that can be encrypted? This is not something that COSE can look at. Most of any analysis is going to sit on top of an analysis of the cryptographic algorithm that is being looked at along with how the protocol is designed in. One can do an analysis along the lines of - are all of the pieces of information that are supposed to be covered by a cryptographic operation covered, but even there just looking at COSE will not be able to answer the question. If one says that the content encryption algorithms MUST be covered by the authenticated data for the AEAD. One needs to look at the protocol that COSE is placed in to see if that is true. It could be part of the authenticated attributes or it could be part of the externally supplied authenticated data. The first is what I would expect for a simple use of a COSE encryption object, but the latter is what is used for OSCORE. In both cases the correct thing is being done but that cannot be determined solely from an analysis of COSE. I have seen reviews such as https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that- everyone-should-avoid which talk to JOSE about some issues that are there and can be avoided - Don't use signature algorithm None - Do checking of algorithms with keys correctly. I saw one review from them that painted COSE with the same brush but when I read their review it looked like they just copied the JWT review over without looking at things from the start. Most if not all of the issues that they highlighted were fixed before I even read this review of JOSE because I found them to be difficult. On the other hand, if you send the signing key as part of the signed message and the recipient does not bother to check that it matches the purported originator of the message. I have no idea how anyone can ever fix that as they might just as easily got the signing key from some other untrusted source and used it. I cannot say that their bespoke crypto will have fewer issues, however WalnutDSA was thought by the company proposing it to be a great algorithm until it underwent some cryptographic review. (And a number of bounds in the algorithm were then changed.) As I remember Frog, which was one of the AEAD algorithms submitted to NIST as part of that computation was presented to a conference and broken before the rump session had finished. If you can get more detail on what you think you are really looking for I might be able to help. Jim > -----Original Message----- > From: Michael Richardson > Sent: Tuesday, July 21, 2020 10:28 AM > To: Jim Schaad > Cc: cose@ietf.org; 'Mike Jones' > Subject: Re: [COSE] implementations of RFC8152 > > > Jim Schaad wrote: > >> -----Original Message----- > >> From: COSE On Behalf Of Michael Richardson > >> Sent: Monday, July 20, 2020 1:30 PM > >> To: cose@ietf.org; Mike Jones > >> Subject: [COSE] implementations of RFC8152 > >> > >> > >> Hi, > >> > >> Is the WG aware of any formal (cryptographic) reviews of RFC7515 and > >> RFC8152? > > > [JLS] I am not too sure of what you mean by a cryptographic review, but I > > suspect that the answer is no. There have been some community reviews > of > > RFC 7515 which point to issues that need to be kept in mind, such as the > > existence of the None signature algorithm. I don't remember seeing > anything > > for RFC 8152 which was not along the lines of - it must have the same > issues > > as RFC 7515. > > Sorry, I used impresise language because I was tired and frustrated at the time. > > I'm asking about formal verifications, either at the protocol interaction level, > such as was done for IKE recently: > https://mailarchive.ietf.org/arch/msg/ipsec/LNEPxxRwNAeWbp2Cjzqb-uS7- > No/ > > and has been planned for EDHOC: > > https://mailarchive.ietf.org/arch/msg/lake/WGmpD4F9Yb6qCfgwYkF0oKcEqYw > > which I know has been done for TLS. > > >> Was there an implementation report when 8152 was published? > > > [JLS] Yes there was. > > I looked back through the IDs before RFC, since we usually remove that before > publication, but I didn't see it in the ID. I guess it might be in the shepherd > write up... Yup. > I wish we would get on with having this on the rfc-editor.org pages :-) > > >> While I'm aware of many of the IETF efforts that leverage COSE, is there > > > any > >> data on how it has been used outside of the IETF? > > > [JLS] There are a couple of different projects at the W3C. Web > > Authentication is one and Secure Data Storage is another. > > There is an ISO > > driving license standard that I have see reference (ISO/IEC JTC 001/SC 17 > > "Cards and security devices for personal identification" Mobile Driver's > > License (mDL)). A couple of people have talked to me about potentially > > using COSE rather than CMS but needing certificates to do so. I can't > > remember who off the top of my head. > > Thank you. > Is it worth enabling a wiki in https://github.com/cose-wg somewhere to record > these things? > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Tue Jul 21 17:19:38 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 3BF883A0887; Tue, 21 Jul 2020 17:19:36 -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 xKFx5DhkVq_i; Tue, 21 Jul 2020 17:19:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE973A0888; Tue, 21 Jul 2020 17:19:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CA6A838A26; Tue, 21 Jul 2020 19:59:05 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QQY23bTxMXsq; Tue, 21 Jul 2020 19:59:05 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0574738A1D; Tue, 21 Jul 2020 19:59:05 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9AC76A8; Tue, 21 Jul 2020 20:19:30 -0400 (EDT) From: Michael Richardson To: draft-raza-ace-cbor-certificates@ietf.org, cose@ietf.org In-Reply-To: <20200710125843.GA224527@LK-Perkele-VII> References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <20200710125843.GA224527@LK-Perkele-VII> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 22 Jul 2020 00:19:36 -0000 --=-=-= Content-Type: text/plain Ilari Liusvaara wrote: > I would say that the encoding of the issuer (and subject) fields is the > most difficult part. > Looking at the definition of issuer/subject, it is essentially: > List> Yes, you are right. To decode for others, the point is that one can have a DN like: DC=tuna,DC=sandelman,DC=ca this is rather uncommon, as most would use CN=tuna.sandelman.ca, or SAN dnsName=tuna.sandelman.ca with an empty CN if it's the Subject. I think that the question is perhaps: * can we write a reasonable subset (BCP) profile of PKIX for constrained environments? > The type autoguess would guess PrintableString if every character is > valid for PrintableString, else it would guess Utf8String. In practice, > I do not think anybody uses any other ones (and wrong guess would be > just 1 byte penalty, unless name is 24 bytes, then it would be 2 byte > penalty). Who did the CSR, and did the CA molest the type at all? Otherwise, we could just do Utf8String. >> 2. About algorithm parameters: Our current assumption is that for our >> target certificates, all needed algorithm info can be represented using >> only the subjectPublicKeyInfo_algorithm field. > Note that in practice, there are very few different SubjectPublicKeyInfo > field types in any sort of wide use. Anything else is extremely rare. > Thus, one could compress the field by having integer for type, and bstr > for contents. And perhaps bstr type and bstr contents as escape hatch > (maybe even with the bit stripping octet retained), should that be ever > needed (that would not increase size in common case). > For instance, types could be: > 0 => X25519/X448 > 1 => Ed25519/Ed448 > 2 => ECDSA P-256/P-384/P-521. > The type overloads are resolvable. We'll have to have RSA in the list too. We may never want to use it, but I think it will hav eto be there :-) What I think we need to do is have someone implement the compressor/decompressor and then do a survey of certificates out there via TLS/HTTPS. That won't be definitive: we'll probably have some failures, and we may declare them out-of-scope. I think that the biggest problem will be what goes in the Issuer, which can be empty, so it has all sorts of kinda throw-away stuff, then a simple CN= would be enough. See ^^^ about BCP. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8XhhIACgkQgItw+93Q 3WXM8ggAjqFkmFbHrNA09HPTPcWrqjAj125tnGHVffoHTy62YCSgDxTr68oXb27g mI5zi7YzCXd/l0VsTyZERQTk79N+jzeoScHBb7E13bP2uuGpzDGLrDr8UljX4XO9 3ziHt5SLDUvK4NsNfUx7+pF+KBZRSBXnGOt+KtSWuk04mXhOAldf+i1WtDFRsjNc fE/vL5z57JryhNwc5+2a2rketlVLDA1G0Sf6YJxjNIm/pOQ9DAic97sDexAbQ/uF ZwEqc8MXTa/EJVcXefdFEyL1zMs8ddLG+NOEMCUF2319yJ0nTk3PDNprusesgPEB I8zm9VslK78YJaYShFhaYp0633nF2g== =2j3E -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 21 17:20:56 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 8CD953A0889; Tue, 21 Jul 2020 17:20:53 -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 86GcnVDMSCy0; Tue, 21 Jul 2020 17:20:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D636F3A0888; Tue, 21 Jul 2020 17:20:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 22CDF38A26; Tue, 21 Jul 2020 20:00:23 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oje9vcZ9KG2T; Tue, 21 Jul 2020 20:00:21 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2BAB138A1D; Tue, 21 Jul 2020 20:00:21 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C5AEEA8; Tue, 21 Jul 2020 20:20:46 -0400 (EDT) From: Michael Richardson To: =?us-ascii?Q?=3D=3FUTF-8=3FQ=3FJoel=5FH=3DC3=3DB6glund=3F=3D?= cc: Ilari Liusvaara , draft-raza-ace-cbor-certificates@ietf.org, cose@ietf.org In-Reply-To: References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <20200710125843.GA224527@LK-Perkele-VII> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 22 Jul 2020 00:20:54 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Joel H=C3=B6glund wrote: > As you might have seen, we have merged and updated the old cbor certi= ficate > related drafts into one (draft-mattsson-cose-cbor-cert-compress-01) w= here > we have added some more details regarding encoding and optimizations.= We > will look closer to the implications of your proposals as input for > upcoming revisions. Am I correct that the -01 version didn't get posted in time? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8Xhl4ACgkQgItw+93Q 3WXhQwf9EJi+gXQngm0XYMW2NXjSpxX4bv8UQOUZMFrkjkM86oVcdL7JV4dTcRuL 6ETjbLdSPhyDEzFNekUWcpzg5P1VfiDGl/xAcjvuc62izfWmKZzxRos9iMW2rL4+ lLv7mTXlg8cE1vSF+8OUwW/49rUw78AfGrDhZSfL4QowR6Npx9t7TD6PZJuOCiJa jTn6EbWdm0EllugZH384Nd4ua+1XJYCc/7GONIM33aX7TTE0DF6+/5A48Bl46uzf T8cQKEoxmq+W+U9due+35KT4xZppJAmDV9kTVZGA1HzDqtjwFL3zquCoxDc5mvGI cLO856uaal/nd+zC2I4FqQxww5o7Ng== =4EDG -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 22 00:38: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 4DA893A0F3D; Wed, 22 Jul 2020 00:38:44 -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 SrBexsvV5eIH; Wed, 22 Jul 2020 00:38:43 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 E94AC3A0F3B; Wed, 22 Jul 2020 00:38:42 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id a15so857961wrh.10; Wed, 22 Jul 2020 00:38:42 -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=xwhykst2xE2yh9sMwcKabt6eWf6aJkZYq72TMjRTeoA=; b=NL1dUAsaeBPlJf3eCuQWiHNLr4kQRhamDFIrdQNzzTgAx5+dVBYjcGXKXEnPiu+D8m T3Xdx4OQJG2aNNu7zTmE+EKxdjigJhy30F5Cz1UgAnJDV0OHEXNnrb3J6dntQwugeqga dx/fieKb5iKnkIiXAcnPBtOYsL8fXX5APdSou/9btgHSm0yEm/f0OrfmT077LaVntriG By7DC11WLzjv/P5eqR6+7UY+tLy4NuKDOYVkfAqqUS9Hp+8gBdV4nnvOtjMq5X57Mq5F Vd0LWjdrpzCsQw1KADCfP7bfer4fhaj36GoFq+/Kq9nx9pg2ETWaXagl0b85VFzFYOBr ZQug== 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=xwhykst2xE2yh9sMwcKabt6eWf6aJkZYq72TMjRTeoA=; b=OwQerptCSYdDuCsFSWpvF949Gs9PMQP9XUPwF6vwzgkpHQ3CYsjE7MdDotGPClKUAq yurEkWBZutJtRiqnLZDwZIAmEm+otwEfepya43oj4GfQY+4/1/inCKwZQpO/twrgXGy9 l3xP955zHTmRY/19ecKDkCFKB5B5uDuzS+LS/yI1nPBTndmnUw1lHq9LM6wYU77mIRsw AVq+rpGG/+Ycf3gn2kIn0s/dOqeZjt1xb8iSSi7iC2BS+a6h8cM7r3tKSgcPwzn2qpvI 6IZmb6pfgJTYgi1/vCLSAHEPElPieOJmE2wT3BXPW4lQYVDxnbq00LRnNx2Nl2CLSPPh 1g+Q== X-Gm-Message-State: AOAM530ZB8QKTsoXuDg96y/r06CuOO33ZcfRA1H1jgILo2qknk+0Qz+h /ZcDgAO5xIjwaYBH99cSriB8nOaLP4FJB5GShjg= X-Google-Smtp-Source: ABdhPJwJ2hSZFYQTpW3OEnh+godOVKNIcDTyzRbebiOT2t1I290A9+OfNQeKzomZjt5Sd/qgmL6gBLsSCdyTjtQIwwk= X-Received: by 2002:adf:8282:: with SMTP id 2mr15121306wrc.76.1595403521371; Wed, 22 Jul 2020 00:38:41 -0700 (PDT) MIME-Version: 1.0 References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <20200710125843.GA224527@LK-Perkele-VII> <702.1595377246@localhost> In-Reply-To: <702.1595377246@localhost> From: =?UTF-8?Q?Joel_H=C3=B6glund?= Date: Wed, 22 Jul 2020 09:38:29 +0200 Message-ID: To: Michael Richardson Cc: Ilari Liusvaara , draft-raza-ace-cbor-certificates@ietf.org, cose@ietf.org Content-Type: multipart/alternative; boundary="0000000000002a342f05ab02d420" Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 22 Jul 2020 07:38:44 -0000 --0000000000002a342f05ab02d420 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you all for your comments and observations! We will further investigate the ambiguity of the encoding, and how the scope should be clarified. Michael, to quickly reply to your explicit question: the new draft was posted before the IETF 108 deadline on 2020-07-13, which is also before the expiry dates of the three different drafts that are now combined. ( https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/ ) Another observation is that while our starting point has been to encode rfc7925 compliant certificates, we hope to make the proposal more future proof by allowing new algorithms also deemed suitable for constrained environments. With that target, we think it is possible to exclude RSA on the list of supported algorithms. Best Regards Joel H=C3=B6glund On Wed, 22 Jul 2020 at 02:20, Michael Richardson wrote: > > Joel H=C3=B6glund wrote: > > As you might have seen, we have merged and updated the old cbor > certificate > > related drafts into one (draft-mattsson-cose-cbor-cert-compress-01) > where > > we have added some more details regarding encoding and > optimizations. We > > will look closer to the implications of your proposals as input for > > upcoming revisions. > > Am I correct that the -01 version didn't get posted in time? > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > --0000000000002a342f05ab02d420 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you all for your comments and observations! We will = further investigate the ambiguity of the encoding, and how the scope should= be clarified.

Michael, to=C2=A0quickly reply to your ex= plicit question: the new draft was posted=20 before the IETF 108 deadline on 2020-07-13, which is also before the expiry= dates of the three different drafts that are now combined. (http= s://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/=C2= =A0)

Another observation is that while our startin= g point has been to encode rfc7925 compliant certificates, we hope to make = the proposal more future proof by allowing new algorithms also deemed suita= ble for=20 constrained environments. With that target, we think it is possible to excl= ude RSA on the list of supported algorithms.

Best = Regards

Joel H=C3=B6glund


On W= ed, 22 Jul 2020 at 02:20, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Joel H=C3=B6glund <joel.hoglund@gmail.com> wrote:
=C2=A0 =C2=A0 > As you might have seen, we have merged and updated the o= ld cbor certificate
=C2=A0 =C2=A0 > related drafts into one (draft-mattsson-cose-cbor-cert-c= ompress-01) where
=C2=A0 =C2=A0 > we have added some more details regarding encoding and o= ptimizations. We
=C2=A0 =C2=A0 > will look closer to the implications of your proposals a= s input for
=C2=A0 =C2=A0 > upcoming revisions.

Am I correct that the -01 version didn't get posted in time?

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



--0000000000002a342f05ab02d420-- From nobody Wed Jul 22 04:12: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 6858F3A07F9; Wed, 22 Jul 2020 04:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 uI8J1dTqJAgG; Wed, 22 Jul 2020 04:12:54 -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 987E33A07F5; Wed, 22 Jul 2020 04:12:54 -0700 (PDT) Received: from [172.16.42.100] (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 4BBXr43WfCzybP; Wed, 22 Jul 2020 13:12:52 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 22 Jul 2020 13:12:50 +0200 Cc: Michael Richardson , draft-raza-ace-cbor-certificates@ietf.org, Ilari Liusvaara , cose@ietf.org X-Mao-Original-Outgoing-Id: 617109170.743904-0459fba31c76a4866bc1966e93b77891 Content-Transfer-Encoding: quoted-printable Message-Id: <75486A7D-E06F-49F8-A851-6A051816EBA7@tzi.org> References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <20200710125843.GA224527@LK-Perkele-VII> <702.1595377246@localhost> To: =?utf-8?Q?Joel_H=C3=B6glund?= X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 22 Jul 2020 11:12:58 -0000 Hi Joel, > Michael, to quickly reply to your explicit question: the new draft was = posted before the IETF 108 deadline on 2020-07-13, which is also before = the expiry dates of the three different drafts that are now combined. = (https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/ = ) That draft says in = https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/ = that it Replaces draft-raza-ace-cbor-certificates, = draft-mattsson-tls-cbor-cert-compress What is the third draft? > Another observation is that while our starting point has been to = encode rfc7925 compliant certificates, we hope to make the proposal more = future proof by allowing new algorithms also deemed suitable for = constrained environments. With that target, we think it is possible to = exclude RSA on the list of supported algorithms. Supported for what=E2=80=A6 The chain may still have RSA certificates in it. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 22 09:17: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 6EBB83A0A50; Wed, 22 Jul 2020 09:17:14 -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 DVoyWzwtFG9u; Wed, 22 Jul 2020 09:17:12 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C0A3A0A4E; Wed, 22 Jul 2020 09:17:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E660238A28; Wed, 22 Jul 2020 11:56:43 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5AJzbJpPZ1Ce; Wed, 22 Jul 2020 11:56:43 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C657338A26; Wed, 22 Jul 2020 11:56:42 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 060571CC; Wed, 22 Jul 2020 12:17:09 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , =?us-ascii?Q?=3D=3Futf-8=3FQ=3FJoel=5F?= =?us-ascii?Q?H=3DC3=3DB6glund=3F=3D?= , draft-raza-ace-cbor-certificates@ietf.org, Ilari Liusvaara , cose@ietf.org In-Reply-To: <75486A7D-E06F-49F8-A851-6A051816EBA7@tzi.org> References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <20200710125843.GA224527@LK-Perkele-VII> <702.1595377246@localhost> <75486A7D-E06F-49F8-A851-6A051816EBA7@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 22 Jul 2020 16:17:15 -0000 Carsten Bormann wrote: joel> Another observation is that while our starting point has been to joel> encode rfc7925 compliant certificates, we hope to make the propos= al joel> more future proof by allowing new algorithms also deemed suitable joel> for constrained environments. With that target, we think it is joel> possible to exclude RSA on the list of supported algorithms. > Supported for what=E2=80=A6 > The chain may still have RSA certificates in it. exactly! I think that the cost is just a single code point. We are optimizing for network bandwidth, not CPU cycles. Constrained "environments" isn't specific enough. In particular, device IDevID or device LDevID, while maybe ECDSA on the device, may have a chain that anchors up to some pre-existing CA which can not for legacy reasons be ECDSA (yet). -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Wed Jul 22 12:16:38 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 D68153A0475 for ; Wed, 22 Jul 2020 12:16:36 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 suUA-rRuaH6I for ; Wed, 22 Jul 2020 12:16:35 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173FD3A08A3 for ; Wed, 22 Jul 2020 12:16:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5190E300AB7 for ; Wed, 22 Jul 2020 15:16:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qjBtlaskrJyX for ; Wed, 22 Jul 2020 15:16:26 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 139CD3001A7; Wed, 22 Jul 2020 15:16:25 -0400 (EDT) From: Russ Housley Message-Id: <10F66F8D-6FD7-454F-965A-1C7612AE6581@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_14AA93B7-169A-4EFF-AF05-373CB37ECC72"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Wed, 22 Jul 2020 15:16:26 -0400 In-Reply-To: <387.1595377170@localhost> Cc: draft-raza-ace-cbor-certificates@ietf.org, cose@ietf.org To: Michael Richardson References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <20200710125843.GA224527@LK-Perkele-VII> <387.1595377170@localhost> X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 22 Jul 2020 19:16:37 -0000 --Apple-Mail=_14AA93B7-169A-4EFF-AF05-373CB37ECC72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Micheal: I suspect that many IoT devices will need to be able to connect to = existing infrastructure, and if the requirements get too tight, then = people will put proxies in place to avoid changing the certificates on = existing infrastructure. That thinking leads me to a view that we can = get great compression when the reasonable subset is followed, but we = need to accommodate things outside the subset, even if it means less = compression. Russ > On Jul 21, 2020, at 8:19 PM, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Ilari Liusvaara wrote: >> I would say that the encoding of the issuer (and subject) fields is = the >> most difficult part. >=20 >> Looking at the definition of issuer/subject, it is essentially: >> List> >=20 > Yes, you are right. > To decode for others, the point is that one can have a DN like: > DC=3Dtuna,DC=3Dsandelman,DC=3Dca >=20 > this is rather uncommon, as most would use CN=3Dtuna.sandelman.ca, > or SAN dnsName=3Dtuna.sandelman.ca with an empty CN if it's the = Subject. >=20 > I think that the question is perhaps: > * can we write a reasonable subset (BCP) profile of PKIX for = constrained environments? >=20 >> The type autoguess would guess PrintableString if every character is >> valid for PrintableString, else it would guess Utf8String. In = practice, >> I do not think anybody uses any other ones (and wrong guess would be >> just 1 byte penalty, unless name is 24 bytes, then it would be 2 byte >> penalty). >=20 > Who did the CSR, and did the CA molest the type at all? > Otherwise, we could just do Utf8String. >=20 >>> 2. About algorithm parameters: Our current assumption is that for = our >>> target certificates, all needed algorithm info can be represented = using >>> only the subjectPublicKeyInfo_algorithm field. >=20 >> Note that in practice, there are very few different = SubjectPublicKeyInfo >> field types in any sort of wide use. Anything else is extremely rare. >=20 >> Thus, one could compress the field by having integer for type, and = bstr >> for contents. And perhaps bstr type and bstr contents as escape hatch >> (maybe even with the bit stripping octet retained), should that be = ever >> needed (that would not increase size in common case). >=20 >> For instance, types could be: >=20 >> 0 =3D> X25519/X448 >> 1 =3D> Ed25519/Ed448 >> 2 =3D> ECDSA P-256/P-384/P-521. >=20 >> The type overloads are resolvable. >=20 > We'll have to have RSA in the list too. We may never want to use it, = but I > think it will hav eto be there :-) >=20 > What I think we need to do is have someone implement the > compressor/decompressor and then do a survey of certificates out there = via > TLS/HTTPS. That won't be definitive: we'll probably have some = failures, and > we may declare them out-of-scope. >=20 > I think that the biggest problem will be what goes in the Issuer, = which can > be empty, so it has all sorts of kinda throw-away stuff, then a simple = CN=3D > would be enough. > See ^^^ about BCP. >=20 > -- > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | IoT = architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >=20 >=20 >=20 --Apple-Mail=_14AA93B7-169A-4EFF-AF05-373CB37ECC72 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXxiQigAKCRCK5O7Q9ZwR yxSfAJ9kOD+HIg+LVuxj0SIXs44XE9PFwgCg8gvh20iTL924U1QmrUTXaXqps5Y= =MFoF -----END PGP SIGNATURE----- --Apple-Mail=_14AA93B7-169A-4EFF-AF05-373CB37ECC72-- From nobody Wed Jul 22 12:32: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 C055F3A08F4; Wed, 22 Jul 2020 12:32:06 -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, NICE_REPLY_A=-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 uZp-N3-tt-ju; Wed, 22 Jul 2020 12:32:04 -0700 (PDT) Received: from mail-edgeS23.fraunhofer.de (mail-edges23.fraunhofer.de [153.97.7.23]) (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 A46C43A07E5; Wed, 22 Jul 2020 12:32:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FWAQBTkxhf/xmnZsBgGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBSoMZUGMKh3KNS4EBmn8JCwEBAQEBAQEBAQYBARg?= =?us-ascii?q?LCgIEAQECgVSCdgKCEAEkOBMCEAEBBgEBAQEBBgQCAoZFDINTgQIBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBARYCMRJCExIBAR4BAQEDAQEWGgEFNgsQCxguJzAGAQw?= =?us-ascii?q?BBQIBAYMiAYJ8BAuuAIE0hAOBT4NIgUCBOAGIbYQED4FMP4ERJw+CJTU+gX5?= =?us-ascii?q?eAQGBX4V2BI8cijWbVSgHgVmBB4EIBAuHP5EEBQoehBqNHQaOFJIGnwcCBAI?= =?us-ascii?q?JAhWBaoF7TSRPgmkJRxcCDY4nAxeCeoVohURyNwIGAQcBAQMJfI4ZAYEQAQE?= X-IPAS-Result: =?us-ascii?q?A2FWAQBTkxhf/xmnZsBgGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBSoMZUGMKh3KNS4EBmn8JCwEBAQEBAQEBAQYBARgLCgIEAQECgVSCd?= =?us-ascii?q?gKCEAEkOBMCEAEBBgEBAQEBBgQCAoZFDINTgQIBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARYCMRJCExIBAR4BAQEDAQEWGgEFNgsQCxguJzAGAQwBBQIBAYMiAYJ8B?= =?us-ascii?q?AuuAIE0hAOBT4NIgUCBOAGIbYQED4FMP4ERJw+CJTU+gX5eAQGBX4V2BI8ci?= =?us-ascii?q?jWbVSgHgVmBB4EIBAuHP5EEBQoehBqNHQaOFJIGnwcCBAIJAhWBaoF7TSRPg?= =?us-ascii?q?mkJRxcCDY4nAxeCeoVohURyNwIGAQcBAQMJfI4ZAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.75,383,1589234400"; d="scan'208";a="19234796" Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jul 2020 21:32:00 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAgAhkxhf/1lIDI1gGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBSoIqbwNNBzAsCpU+gQGbCAsBAwEBAQEBBgEBGAs?= =?us-ascii?q?KAgQBAYFWgnYCgg4CJDgTAhABAQUBAQECAQYEbYVcDIVyAQEEAQEWGgEFNgs?= =?us-ascii?q?QCxguJzAGAQwBBQIBAYMiAYMAC618gTSFUoNIgUCBOAGIbYQED4FMP4ERJw+?= =?us-ascii?q?CJTU+gX5eAQGBX4V2BI8cijWbVSgHgVmBB4EIBAuHP5EEBQoehBqNHQaOFJI?= =?us-ascii?q?GnwcCBAIJAhWBaiOBV00kT4JpCUcXAg2OJwMXgnqFaIVEQTE3AgYBBwEBAwl?= =?us-ascii?q?8jhkBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,383,1589234400"; d="scan'208";a="86795377" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jul 2020 21:31:57 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 06MJVvYm007373 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 22 Jul 2020 21:31:57 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 22 Jul 2020 21:31:52 +0200 To: Russ Housley , Michael Richardson CC: , References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <20200710125843.GA224527@LK-Perkele-VII> <387.1595377170@localhost> <10F66F8D-6FD7-454F-965A-1C7612AE6581@vigilsec.com> From: Henk Birkholz Message-ID: <5f8473e2-acd8-3f1f-5c4e-0119b89854c2@sit.fraunhofer.de> Date: Wed, 22 Jul 2020 21:31:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <10F66F8D-6FD7-454F-965A-1C7612AE6581@vigilsec.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.156.41] Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 22 Jul 2020 19:32:07 -0000 +1 for pointing exactly that out, Russ. Identifying an appropriate/reasonable subset that allows for streamlined value types or condensed keys (or fixed indices in arrays, analogously) is an important step that needs critical mass for discussion. "less common" cases, or simply cases that will not find consensus in this discussion we will have to represent in a more thorough/verbose manner. My assumption is that this to be identified subset could also possibly help more native representations using COSE. Viele Gre, Henk On 22.07.20 21:16, Russ Housley wrote: > Micheal: > > I suspect that many IoT devices will need to be able to connect to existing infrastructure, and if the requirements get too tight, then people will put proxies in place to avoid changing the certificates on existing infrastructure. That thinking leads me to a view that we can get great compression when the reasonable subset is followed, but we need to accommodate things outside the subset, even if it means less compression. > > Russ > > >> On Jul 21, 2020, at 8:19 PM, Michael Richardson wrote: >> >> Signed PGP part >> >> Ilari Liusvaara wrote: >>> I would say that the encoding of the issuer (and subject) fields is the >>> most difficult part. >> >>> Looking at the definition of issuer/subject, it is essentially: >>> List> >> >> Yes, you are right. >> To decode for others, the point is that one can have a DN like: >> DC=tuna,DC=sandelman,DC=ca >> >> this is rather uncommon, as most would use CN=tuna.sandelman.ca, >> or SAN dnsName=tuna.sandelman.ca with an empty CN if it's the Subject. >> >> I think that the question is perhaps: >> * can we write a reasonable subset (BCP) profile of PKIX for constrained environments? >> >>> The type autoguess would guess PrintableString if every character is >>> valid for PrintableString, else it would guess Utf8String. In practice, >>> I do not think anybody uses any other ones (and wrong guess would be >>> just 1 byte penalty, unless name is 24 bytes, then it would be 2 byte >>> penalty). >> >> Who did the CSR, and did the CA molest the type at all? >> Otherwise, we could just do Utf8String. >> >>>> 2. About algorithm parameters: Our current assumption is that for our >>>> target certificates, all needed algorithm info can be represented using >>>> only the subjectPublicKeyInfo_algorithm field. >> >>> Note that in practice, there are very few different SubjectPublicKeyInfo >>> field types in any sort of wide use. Anything else is extremely rare. >> >>> Thus, one could compress the field by having integer for type, and bstr >>> for contents. And perhaps bstr type and bstr contents as escape hatch >>> (maybe even with the bit stripping octet retained), should that be ever >>> needed (that would not increase size in common case). >> >>> For instance, types could be: >> >>> 0 => X25519/X448 >>> 1 => Ed25519/Ed448 >>> 2 => ECDSA P-256/P-384/P-521. >> >>> The type overloads are resolvable. >> >> We'll have to have RSA in the list too. We may never want to use it, but I >> think it will hav eto be there :-) >> >> What I think we need to do is have someone implement the >> compressor/decompressor and then do a survey of certificates out there via >> TLS/HTTPS. That won't be definitive: we'll probably have some failures, and >> we may declare them out-of-scope. >> >> I think that the biggest problem will be what goes in the Issuer, which can >> be empty, so it has all sorts of kinda throw-away stuff, then a simple CN= >> would be enough. >> See ^^^ about BCP. >> >> -- >> ] Never tell me the odds! | ipv6 mesh networks [ >> ] Michael Richardson, Sandelman Software Works | IoT architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >> >> >> > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > From nobody Wed Jul 22 14:35: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 D0FA93A09F1 for ; Wed, 22 Jul 2020 14:35: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 577c9yTb7ktC for ; Wed, 22 Jul 2020 14:35:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259E93A09C9 for ; Wed, 22 Jul 2020 14:35:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 11BBC38A20; Wed, 22 Jul 2020 17:14:53 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xsShXLJfhTkZ; Wed, 22 Jul 2020 17:14:51 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8E3D338A1F; Wed, 22 Jul 2020 17:14:51 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 014471CB; Wed, 22 Jul 2020 17:35:17 -0400 (EDT) From: Michael Richardson To: Russ Housley , cose@ietf.org In-Reply-To: <10F66F8D-6FD7-454F-965A-1C7612AE6581@vigilsec.com> References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <20200710125843.GA224527@LK-Perkele-VII> <387.1595377170@localhost> <10F66F8D-6FD7-454F-965A-1C7612AE6581@vigilsec.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 22 Jul 2020 21:35:23 -0000 --=-=-= Content-Type: text/plain Russ Housley wrote: > I suspect that many IoT devices will need to be able to connect to > existing infrastructure, and if the requirements get too tight, then > people will put proxies in place to avoid changing the certificates on > existing infrastructure. That thinking leads me to a view that we can > get great compression when the reasonable subset is followed, but we > need to accommodate things outside the subset, even if it means less > compression. I agree, and I would say this differently: Devices connecting over challenged networks will need to be part of larger security infrastructure, not all of which will be trivially upgradable. (often for non-technical reasons involving regulation) So, while it might be reasonable to not try to optimize SubjectDN containing DC=tuna,DC=sandelman,DC=ca, I think that including RSA is easy enough. {It's not the devices necessarily that are constrained, it's the networks} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8YsRUACgkQgItw+93Q 3WVpEggArDsFOXPYBY3829SVerKtyzwrZUspVlw2aLwncGRNmjAi/jVUAL4xN5Fe RAC8ZT641GebcV59jfcHsh0D5Kdr9Esx3nYuftrAnFV+ch3Kp0Q9Dk87Wfzx4b5S bvp7mJj2/aaoP4zis9+BJGOx2T7Vh2BsZYIzMXjKqvF9Letuc54Ms8DuBnu7CY+O IWLRi3cyFnRHmT1lRMOt6J5ZLEgRdLlmxCZjromp6yCmIrYF3W2S+vRP72afD+lj GDBgY70H0QNYXNZ7thWV+UxtzhgeNBs8KVvkTrvVz490mx7gRWPlHkE+gji4TFpZ kczTCN8a4JDLFFs6dxQEOfEt3TWgjQ== =Dlmw -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 23 10:44:09 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 D4F343A0C15 for ; Thu, 23 Jul 2020 10:44:06 -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 PMvGvhlmYWHX for ; Thu, 23 Jul 2020 10:44:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53BC33A0C13 for ; Thu, 23 Jul 2020 10:44:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8A1D338A31 for ; Thu, 23 Jul 2020 13:23:36 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uvqva1rmixNj for ; Thu, 23 Jul 2020 13:23:36 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A9FF238A1A for ; Thu, 23 Jul 2020 13:23:35 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D86CE9A for ; Thu, 23 Jul 2020 13:44:02 -0400 (EDT) From: Michael Richardson To: cose@ietf.org In-Reply-To: <00f901d65f89$d2be3f50$783abdf0$@augustcellars.com> References: <19246.1595277002@localhost> <006101d65ed9$3928d5e0$ab7a81a0$@augustcellars.com> <25624.1595352462@localhost> <00f901d65f89$d2be3f50$783abdf0$@augustcellars.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [COSE] implementations of RFC8152 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, 23 Jul 2020 17:44:07 -0000 --=-=-= Content-Type: text/plain Jim, thank you for the summary and for clarifying for me the difference between formal verification of a protocol and of a message encapsulation object. It is a good point. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8ZzGIACgkQgItw+93Q 3WXwBQf/ffoBNs7fiWQSTLdUG7MDzwxnyFpbesAmlQiP4oyr0JcrGBMBTEvUhSPH 3kpGB2JX3LB2ONxUPzEUtqDcLS7p1hNU0/+GkWdOdNPLa0nAJNhCvXKsRkoVazG3 CGJExdweOTuEzSgKttQDpNXUrccNgp8Tr8oCjWvu6/uTOmFTETIoVfAGKltLz2VY 6qrKSq6Hq13i8fH5kk4UTEPTw505LDr+Z7PZx9Khe0wY3PLnb91saKzkfnjCBjE/ oO7eWT83QV0UXcBXlqEX6pjeblDpda1gFCJxDWtVHnadG1hm8c8cz7M+v9O65P+n Am/uUibMK8/H8Zok+KUQ1K/Sq5nLUA== =3nxC -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 23 13:26:28 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 E15863A0D6B for ; Thu, 23 Jul 2020 13:26:26 -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 LkmjljRDpgb7 for ; Thu, 23 Jul 2020 13:26: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 9F54A3A0D69 for ; Thu, 23 Jul 2020 13:26:25 -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, 23 Jul 2020 13:26:19 -0700 From: Jim Schaad To: Date: Thu, 23 Jul 2020 13:26:17 -0700 Message-ID: <027601d6612f$868d6960$93a83c20$@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: AdZhIWMJ1Dtcyy94R7GeN5PupF/yQw== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] COSE Struct 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: Thu, 23 Jul 2020 20:26:27 -0000 During the IESG review of draft-ietf-cose-rfc8152bis-struct a DISCUSS was raised that it took a while to convince me was a real problem and I have been since looking at this to try and figure out if there were any good answers. Unfortunately I did not find anything that I really liked. So this is going to the list to try and get some type of resolution for the problem. All of the structures start out the same * bstr w/ protected attributes * map w/ unprotected attributes * bstr w/ some type of content * Array of items above (i.e. recipients) or nothing For all but four of the COSE message structures, what goes into the second bstr is some type of cryptographically computed value and thus applying a countersignature to that value provides additional benefits. COSE_Signature has this layout, but it does not have any cryptographically computed values so the document describes putting a countersignature on this structure as being the same as adding a parallel signature. The last three structures have one additional bstr added so that you get * bstr w/ protected attributes * map w/ unprotected attributes * bstr w/ some type of content * bstr w/ cryptographic value * Array of items above (i.e. recipients) or nothing In these cases if you wanted to provide additional value with the countersignature you need to be computing it on the fourth value in the structure and not the third. This was correctly indicated for COSE_Mac and COSE_Mac0 in the current document, but it was not correctly indicated for COSE_Sign1. The following are the options that I have come up with so far: 1. Change the text so that it indicates that a countersignature on COSE_Sign1 does not provide a countersignature but only provides an additional signature as is currently done for the two MAC structures. This is going to be somewhat non-intuitive as a countersignature on a signature structure does not produce a countersignature. This is what my current code base does. 2. Change the countersignature algorithm to use the first and last bstr in the structure. This will change the behavior for countersignatures on COSE_Mac and COSE_Mac0, but I would not expect this to have any significant real world issues. Changing the algorithm does mean that any future structures defined for COSE (perhaps some type of combined signature/encryption algorithm) are going to need to be designed so that if a new bstr is added, it needs to ensure that the last one is where the cryptographic value is added to the structure. 3. Change the countersignature algorithm to use every bstr value in the structure. Again, this will change the algorithm for countersignatures on COSE_Mac and COSE_Mac0. The benefit is that every new item added is going to be included in the countersignature so you don't need to have a single value which contains all of the new cryptographic value. 4. Change the countersignature algorithm for COSE_Sign1, but leave it alone for the COSE_Mac and COSE_Mac0 structures. This has the benefit that a countersignature on a COSE_Sign1 produces the type of value one would expect, and it does not change what you get for the current MAC structures. The downside is that you suddenly need to look at the structure before you can do the validation in the cases where the fourth bstr is in the structure. An additional downside is that if a new structure is created with the extra bstr value, the validator will not know which of the two extraction algorithms is to be used. I don't have any preference between the options above. They all have good points and bad points. The first one is the easiest to implement as it would only require adding some text to the document. But the frisson between what one would expect a countersignature to be and what it is in actuality for a COSE_Sign1 is jarring. Please look at this and give me opinions about the correct way to go forward. Jim From nobody Thu Jul 23 15:08: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 DED2A3A05A0 for ; Thu, 23 Jul 2020 15:08:11 -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 9GtHUxstGB-F for ; Thu, 23 Jul 2020 15:08:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5863A0598 for ; Thu, 23 Jul 2020 15:08:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CF128389F2; Thu, 23 Jul 2020 17:47:39 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nw2Ul6Dn55EH; Thu, 23 Jul 2020 17:47:39 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0DBC2389AD; Thu, 23 Jul 2020 17:47:39 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 62E4D1CB; Thu, 23 Jul 2020 18:08:06 -0400 (EDT) From: Michael Richardson To: Jim Schaad , cose@ietf.org In-Reply-To: <027601d6612f$868d6960$93a83c20$@augustcellars.com> References: <027601d6612f$868d6960$93a83c20$@augustcellars.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [COSE] COSE Struct 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: Thu, 23 Jul 2020 22:08:12 -0000 --=-=-= Content-Type: text/plain I'm sorry, I've been pretty much unaware of the 8152bis effort. I feel rather embarrassed about that, having written some code that did not (yet) fully interoperate with Jim's code (That TODO item shouts at me daily) Jim Schaad wrote: > During the IESG review of draft-ietf-cose-rfc8152bis-struct a DISCUSS was > raised that it took a while to convince me was a real problem and I have > been since looking at this to try and figure out if there were any good > answers. Unfortunately I did not find anything that I really liked. So > this is going to the list to try and get some type of resolution for the > problem. > All of the structures start out the same > * bstr w/ protected attributes > * map w/ unprotected attributes > * bstr w/ some type of content > * Array of items above (i.e. recipients) or nothing > For all but four of the COSE message structures, what goes into the second > bstr is some type of cryptographically computed value and thus applying a > countersignature to that value provides additional benefits. I found your words "second bstr" mystyfing because it maps to "* bstr w/ some type of content" rather than the "second" item, "map w/ unprotected attributes" :-) Next time, can we number the items... > COSE_Signature has this layout, but it does not have any cryptographically > computed values so the document describes putting a countersignature on this > structure as being the same as adding a parallel signature. I understand this part. > The last three structures have one additional bstr added so that you get > * bstr w/ protected attributes > * map w/ unprotected attributes > * bstr w/ some type of content > * bstr w/ cryptographic value > * Array of items above (i.e. recipients) or nothing "Last three structures"... I think you must mean COSE_Encrypt, COSE_recipient and COSE_Mac. (Why on page 16 are they: COSE_Sign1, COSE_Signature, COSE_Encrypt, COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0. In this order, rather than: COSE_Signature, COSE_Sign1, COSE_Encrypt0, COSE_Encrypt, COSE_recipient, COSE_Mac, and COSE_Mac0. ) But, COSE_Encrypt combines: "* bstr w/ some type of content"/"* bstr w/ cryptographic value" because it's encrypted, right? > In these cases if you wanted to provide additional value with the > countersignature you need to be computing it on the fourth value in the > structure and not the third. This was correctly indicated for COSE_Mac and > COSE_Mac0 in the current document, but it was not correctly indicated for > COSE_Sign1. The following are the options that I have come up with so far: Can you give a use case here? I think that I get that we are either breaking COSE_Sign1 (which has been rarely used so far), or COSE_Mac*, in-so-far as they need countersignatures with additional values. If no additional values, then not a problem. > I don't have any preference between the options above. They all have good > points and bad points. The first one is the easiest to implement as it > would only require adding some text to the document. But the frisson > between what one would expect a countersignature to be and what it is in > actuality for a COSE_Sign1 is jarring. I think that I'm okay with breaking/updating COSE_Sign1. Don't we need Sign1 for SUIT? I believe that Henk's SBOM proposal (outside of the IETF), does. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8aCkYACgkQgItw+93Q 3WW+kQf+PvDhGvxU9CqGgMqwdJb6Y4O5MM5VikEIVaNWsGpiI2nYYtj6ZfOA2XOX YubJlTK6a3wyLDLtbt7E7X1e2Edx3MJhsUOJF4qfqmkzYrPN4GYh5bMjhM+8K5HK D/q7qET63XsUP1jRAW6GsKzmDWkfZfQ03sq0K5m3bQhK48p7bNQxgv5omAsVA7TO 8Y2Hzni+PoimMipX629gkARWACLUHY+nKZ7TD0qnWLixGTQxM0Da1XPfkkelPojK 3f3PmhBve2FYDvq7LgsULk4iw9guQ32XaoF55r7/6/f7gqkx2aBBW36MdZzK7sxw hGpCbzum29v85/ZAr06JhyEyuSdrOQ== =6M9m -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 23 17:23:28 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 AA45B3A09A2 for ; Thu, 23 Jul 2020 17:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 bS-4F0Nm0ltF for ; Thu, 23 Jul 2020 17:23:23 -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 E79A73A0948 for ; Thu, 23 Jul 2020 17:23:22 -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 4BCVKh31rVzyX5; Fri, 24 Jul 2020 02:23:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <21650.1595542086@localhost> Date: Fri, 24 Jul 2020 02:23:19 +0200 Cc: Jim Schaad , cose@ietf.org X-Mao-Original-Outgoing-Id: 617242999.820437-54b3e796a107cc7e76a44d7294223f86 Content-Transfer-Encoding: quoted-printable Message-Id: <4CAC209C-7343-4234-A8C4-14C61089B4B6@tzi.org> References: <027601d6612f$868d6960$93a83c20$@augustcellars.com> <21650.1595542086@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [COSE] COSE Struct 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: Fri, 24 Jul 2020 00:23:26 -0000 On 2020-07-24, at 00:08, Michael Richardson wrote: >=20 > I think that I'm okay with breaking/updating COSE_Sign1. Well, we wouldn=E2=80=99t break Sign1, but would break countersignatures = with Sign1. > Don't we need Sign1 for SUIT? > I believe that Henk's SBOM proposal (outside of the IETF), does. Yes, we shouldn=E2=80=99t break Sign1. Now, about countersignatures: Do SUIT or SBOM use countersignatures on Sign1? We could always (and probably should) put in another structure that is = called countersignature1 that does what we want while leaving the old = one alone. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 24 04:23: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 F2D8A3A0EEE for ; Fri, 24 Jul 2020 04:23:02 -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 uxMUqk1jAPnx for ; Fri, 24 Jul 2020 04:23:01 -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 DA2973A0EED for ; Fri, 24 Jul 2020 04:23: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; Fri, 24 Jul 2020 04:22:52 -0700 From: Jim Schaad To: 'Michael Richardson' , References: <027601d6612f$868d6960$93a83c20$@augustcellars.com> <21650.1595542086@localhost> In-Reply-To: <21650.1595542086@localhost> Date: Fri, 24 Jul 2020 04:22:50 -0700 Message-ID: <02ea01d661ac$c5f2ef30$51d8cd90$@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: AQFCXW2FEiC82TXE8hIcpoMJzNSmNAGa91naqjHFdWA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] COSE Struct 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: Fri, 24 Jul 2020 11:23:03 -0000 > -----Original Message----- > From: Michael Richardson > Sent: Thursday, July 23, 2020 3:08 PM > To: Jim Schaad ; cose@ietf.org > Subject: Re: [COSE] COSE Struct Discuss > > > I'm sorry, I've been pretty much unaware of the 8152bis effort. > I feel rather embarrassed about that, having written some code that did not > (yet) fully interoperate with Jim's code (That TODO item shouts at me daily) > > Jim Schaad wrote: > > During the IESG review of draft-ietf-cose-rfc8152bis-struct a DISCUSS was > > raised that it took a while to convince me was a real problem and I have > > been since looking at this to try and figure out if there were any good > > answers. Unfortunately I did not find anything that I really liked. So > > this is going to the list to try and get some type of resolution for the > > problem. > > > All of the structures start out the same > > * bstr w/ protected attributes > > * map w/ unprotected attributes > > * bstr w/ some type of content > > * Array of items above (i.e. recipients) or nothing > > > For all but four of the COSE message structures, what goes into the second > > bstr is some type of cryptographically computed value and thus applying a > > countersignature to that value provides additional benefits. > > I found your words "second bstr" mystyfing because it maps to "* bstr w/ some > type of content" > rather than the "second" item, "map w/ unprotected attributes" :-) Next time, > can we number the items... > > > COSE_Signature has this layout, but it does not have any cryptographically > > computed values so the document describes putting a countersignature on > this > > structure as being the same as adding a parallel signature. > > I understand this part. > > > The last three structures have one additional bstr added so that you get > > * bstr w/ protected attributes > > * map w/ unprotected attributes > > * bstr w/ some type of content > > * bstr w/ cryptographic value > > * Array of items above (i.e. recipients) or nothing > > "Last three structures"... I think you must mean COSE_Encrypt, COSE_recipient > and COSE_Mac. > (Why on page 16 are they: > COSE_Sign1, COSE_Signature, COSE_Encrypt, > COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0. > > In this order, rather than: > COSE_Signature, COSE_Sign1, > COSE_Encrypt0, COSE_Encrypt, > COSE_recipient, COSE_Mac, and COSE_Mac0. > ) > > But, COSE_Encrypt combines: "* bstr w/ some type of content"/"* bstr w/ > cryptographic value" > because it's encrypted, right? > No - The last three structures were COSE_Sign1, COSE_Mac and COSE_Mac0 - they are enumerated below > > In these cases if you wanted to provide additional value with the > > countersignature you need to be computing it on the fourth value in the > > structure and not the third. This was correctly indicated for COSE_Mac > and > > COSE_Mac0 in the current document, but it was not correctly indicated for > > COSE_Sign1. The following are the options that I have come up with so far: > > Can you give a use case here? > > I think that I get that we are either breaking COSE_Sign1 (which has been > rarely used so far), or COSE_Mac*, in-so-far as they need countersignatures > with additional values. > If no additional values, then not a problem. I think there have been a fair number of possible standards that are using or planning to use COSE_Sign1. However, as Carsten said we are not breaking COE_Sign1, COSE_Mac0 or COSE_Mac1. We are breaking how countersignatures are applied to them. > > > I don't have any preference between the options above. They all have > good > > points and bad points. The first one is the easiest to implement as it > > would only require adding some text to the document. But the frisson > > between what one would expect a countersignature to be and what it is in > > actuality for a COSE_Sign1 is jarring. > > I think that I'm okay with breaking/updating COSE_Sign1. > Don't we need Sign1 for SUIT? > I believe that Henk's SBOM proposal (outside of the IETF), does. Does knowing that only countersignatures are being broken change how you would weight the options? Jim > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Fri Jul 24 17: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 DC3293A0C99 for ; Fri, 24 Jul 2020 17:06:43 -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 Cu1MW2VgwgKw for ; Fri, 24 Jul 2020 17:06:42 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2DAA3A0C9C for ; Fri, 24 Jul 2020 17:06:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3EC4C389F1; Fri, 24 Jul 2020 19:46:11 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wDiTmkp-mMx2; Fri, 24 Jul 2020 19:46:10 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E37A4389F0; Fri, 24 Jul 2020 19:46:09 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3E7FE26; Fri, 24 Jul 2020 20:06:38 -0400 (EDT) From: Michael Richardson To: Jim Schaad cc: cose@ietf.org In-Reply-To: <02ea01d661ac$c5f2ef30$51d8cd90$@augustcellars.com> References: <027601d6612f$868d6960$93a83c20$@augustcellars.com> <21650.1595542086@localhost> <02ea01d661ac$c5f2ef30$51d8cd90$@augustcellars.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [COSE] COSE Struct 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, 25 Jul 2020 00:06:44 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: > Does knowing that only countersignatures are being broken change how you > would weight the options? Yes, it makes me less able to express a preference :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8bd40ACgkQgItw+93Q 3WX68ggAhrde0OAcR1TOW96HarZ4biL0dfG2vXcUxiexwxxeErtwD5VUVMFKGMUm gdj8J4vJCM/GTP0DrB2FmWnVaUDHgGsc2c/M9CvUXu1D7z9QxkjFQwwjE1Q3+yyM IMiPFYH1pNRlZuwGet8k8OP1e/tKNXJsggPSCSQDybwPl76dAfkwFw+XgMGxTW4f UvlypUFedMkqUbmMS6n8jGarG1YwJr4kYzQEh6BDvXu8pUgHRvHSQ7GTqaHvTgzu Jdi+qFQ5TB8AR2ZB6sObQDV3pQF4/NPpFP88s2SEB8xJsBZquS9cTTYvTE2Zcjb5 64sX5c7Af7fzzLq4LSRT64+P6pni5Q== =KM24 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 26 10:57: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 BB6143A11E4 for ; Sun, 26 Jul 2020 10:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, SPF_HELO_NONE=0.001, SPF_NONE=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 pHigD80qYBSq for ; Sun, 26 Jul 2020 10:56:57 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2b.welho.com [83.102.41.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625133A11E0 for ; Sun, 26 Jul 2020 10:56:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id C9F58C4B03; Sun, 26 Jul 2020 20:56:54 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id gJWioB3CQU_3; Sun, 26 Jul 2020 20:56:54 +0300 (EEST) Received: from LK-Perkele-VII (84-253-234-84.bb.dnainternet.fi [84.253.234.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 4B5B42308; Sun, 26 Jul 2020 20:56:52 +0300 (EEST) Date: Sun, 26 Jul 2020 20:56:51 +0300 From: Ilari Liusvaara To: Michael Richardson Cc: cose@ietf.org Message-ID: <20200726175651.GA559101@LK-Perkele-VII> References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <20200710125843.GA224527@LK-Perkele-VII> <387.1595377170@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <387.1595377170@localhost> Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 26 Jul 2020 17:57:05 -0000 On Tue, Jul 21, 2020 at 08:19:30PM -0400, Michael Richardson wrote: > > Ilari Liusvaara wrote: > > I would say that the encoding of the issuer (and subject) fields is the > > most difficult part. > > > Looking at the definition of issuer/subject, it is essentially: > > List> > > Yes, you are right. > To decode for others, the point is that one can have a DN like: > DC=tuna,DC=sandelman,DC=ca > > this is rather uncommon, as most would use CN=tuna.sandelman.ca, > or SAN dnsName=tuna.sandelman.ca with an empty CN if it's the Subject. I think most end-entity stuff just has one of the SANs duplicated as CN and nothing else. Omitting subject is fairly rare due to some software puking on that. > I think that the question is perhaps: > * can we write a reasonable subset (BCP) profile of PKIX for constrained environments? > > > The type autoguess would guess PrintableString if every character is > > valid for PrintableString, else it would guess Utf8String. In practice, > > I do not think anybody uses any other ones (and wrong guess would be > > just 1 byte penalty, unless name is 24 bytes, then it would be 2 byte > > penalty). > > Who did the CSR, and did the CA molest the type at all? > Otherwise, we could just do Utf8String. I think names are usually PrintableString. Utf8String is just used for the cases where PrintableString just won't do (PrintableString is proper subset of ASCII, most notably @ and & are not in it). > >> 2. About algorithm parameters: Our current assumption is that for our > >> target certificates, all needed algorithm info can be represented using > >> only the subjectPublicKeyInfo_algorithm field. > > > Note that in practice, there are very few different SubjectPublicKeyInfo > > field types in any sort of wide use. Anything else is extremely rare. > > > Thus, one could compress the field by having integer for type, and bstr > > for contents. And perhaps bstr type and bstr contents as escape hatch > > (maybe even with the bit stripping octet retained), should that be ever > > needed (that would not increase size in common case). > > > For instance, types could be: > > > 0 => X25519/X448 > > 1 => Ed25519/Ed448 > > 2 => ECDSA P-256/P-384/P-521. > > > The type overloads are resolvable. > > We'll have to have RSA in the list too. We may never want to use it, but I > think it will hav eto be there :-) Well, codepoints are pretty cheap here. There are 24 one-byte uints, and the above just uses 3 of those. And even if it was not, it would be maybe a two dozen or so more bytes. > What I think we need to do is have someone implement the > compressor/decompressor and then do a survey of certificates out there via > TLS/HTTPS. That won't be definitive: we'll probably have some failures, and > we may declare them out-of-scope. Well, on TLS/HTTPS, there is mostly WebPKI, which mandates all sorts of effectively uncompressable junk. Looking at one 1169 byte certificate, removing all the junk would make it shrink to ~650 bytes. And using more efficient crypto would shrink it to ~405 bytes. And fair bit of thet ~405 bytes could be compressed. -Ilari From nobody Mon Jul 27 09:12: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 DB6593A1AC7 for ; Mon, 27 Jul 2020 09:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.469 X-Spam-Level: X-Spam-Status: No, score=-0.469 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_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 7xgR5oUESuTy for ; Mon, 27 Jul 2020 09:12:42 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 BB3EE3A1EC2 for ; Mon, 27 Jul 2020 09:09:32 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id t142so8968978wmt.4 for ; Mon, 27 Jul 2020 09:09:32 -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=pEGkGShDoEXBxGuLTGV3cDPaUjMpLc3iKcKKW8lZ+nQ=; b=m/sUcTeUx/Eo4NRTUeWItRboWWBhBT7Ez+JZz8WmoIFALBzbUcpAL8aRHxJtuEiqVV N8XpwFrHc3yrMN3kRj4r/EX6LgD1OI1iXP7nd3w3WhK/h8raHEbLbAgzC2SOxsPKTpIT OvWDYFVzc+VQKf8XFwW/1WwB0Wv43gttRF+klxZmGe99veQhsUAxATY+3nf7IaMExncl h03UK3xV7UZ/grMQkycb78xHE7UCXSMeJhaAA+wjkPWdd6qSvR5n/Oz33d+avpC4tezc syHSgw4G9LXR9TcvfGNQdVHnxCOLPs3zeIW9/Kh32zoOeircPI3vmzDQMwr/2zELkico XtPQ== 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=pEGkGShDoEXBxGuLTGV3cDPaUjMpLc3iKcKKW8lZ+nQ=; b=Miyz4g06TKjHPNgfA2F2kUp2+hsMdRQN961Y4YfadUif1dRbnDO/A5g+DwRpmAffCk yRKjgi9+p48sgxfKay3LXmUVExX1VbcVvbGNrsEox0W5JUby3VO82ffJy5tvpvddEebH keSoZCZM04kIU37lJdurp3wMjDyfh9mIuOX/oitAX91rbRHxoUJTi2HyZWddLup0iu9b fREYT1sXIueT75qPGZ3JZpmuTtttg2jNel4rU1bDRrPHEnafzf9GLhCYUaYO7e2JM6TF soO+S/6nC/z3t6+FPl/mYDRrOpjOHWr8QwJggGbJLSjDpTByWaFRUU5mC9Z+XnWnDPZo F17w== X-Gm-Message-State: AOAM532lDnMftc3nkFHK5+ObfFisZXAQYlgndlsHfSQu71eFyrbVqVaR FGLKhcKg866LaRgElgymByqD1V2ssYrW5d6A5Dc= X-Google-Smtp-Source: ABdhPJyTU1B2h9j/j8GVJUFEhYsfiuGxS3QMoILYaVuaRXHIYaPf3DuRt/hxt2Grs/2uVOzLGXZshuK0iVPkajsG4z8= X-Received: by 2002:a1c:7d55:: with SMTP id y82mr34849wmc.186.1595866171314; Mon, 27 Jul 2020 09:09:31 -0700 (PDT) MIME-Version: 1.0 References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <20200710125843.GA224527@LK-Perkele-VII> <20200721115009.GB464556@LK-Perkele-VII> In-Reply-To: From: =?UTF-8?Q?Joel_H=C3=B6glund?= Date: Mon, 27 Jul 2020 18:09:20 +0200 Message-ID: To: Russ Housley Cc: Ilari Liusvaara , cose@ietf.org Content-Type: multipart/alternative; boundary="0000000000004016d105ab6e8c7b" Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 27 Jul 2020 16:12:44 -0000 --0000000000004016d105ab6e8c7b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A follow-up question below: > 4 bits is not sufficient to represent non-empty ordered subsets > > of 4 elements. One needs at least 6 bits for that. > > > > However, one could fit the thing in 4 bits by noting that combining > > id-kp-OCSPSigning with anything else is Bad Idea. And non-empty > > ordered subset of mutually exclusive sets of 3+1 elements does > > fit in 4 bits (A, B, C, AB, AC, BA, BC, CA, CB, ABC, ACB, BAC, BCA, > > CAB, CBA, Z). > > Yes, a SET OF would have defined an order, but it does not help the > relying party, who only cares about whether a particular OID is in the > SEQUENCE or not. > > Putting them in the same order as SET OF would work for new certificates, > but it will not help with existing ones. > > We read Ilari's proposal as a way to uniquely order the relevant EKU combinations, in which case the encoding would work with both existing and new certificates. Can you please clarify which situation you are referring to? Best Regards Joel H=C3=B6glund Virus-free. www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> --0000000000004016d105ab6e8c7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A follow-up question below:

>= ;=C2=A0 =C2=A04 bits is not sufficient to represent non-empty ordered subse= ts
>=C2=A0 =C2=A0of 4 elements. One needs at least 6 bits for that.
>
>=C2=A0 =C2=A0However, one could fit the thing in 4 bits by noting that = combining
>=C2=A0 =C2=A0id-kp-OCSPSigning with anything else is Bad Idea. And non-= empty
>=C2=A0 =C2=A0ordered subset of mutually exclusive sets of 3+1 elements = does
>=C2=A0 =C2=A0fit in 4 bits (A, B, C, AB, AC, BA, BC, CA, CB, ABC, ACB, = BAC, BCA,
>=C2=A0 =C2=A0CAB, CBA, Z).

Yes, a SET OF would have defined an order, but it does not help the relying= party, who only cares about whether a particular OID is in the SEQUENCE or= not.

Putting them in the same order as SET OF would work for new certificates, b= ut it will not help with existing ones.


We read Ilari's proposal as a way = to uniquely order the relevant EKU combinations, in which case the encoding= would work with both existing and new certificates. Can you please clarify= which situation you are referring to?

Best Regard= s=C2=A0

Joel H=C3=B6glund


= Virus-free. www.avg.com
--0000000000004016d105ab6e8c7b-- From nobody Mon Jul 27 09:24:55 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 820873A1B25; Mon, 27 Jul 2020 09:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUhuWNzGYXg8; Mon, 27 Jul 2020 09:24:52 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 AA9F03A1B39; Mon, 27 Jul 2020 09:24:37 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id a14so15522998wra.5; Mon, 27 Jul 2020 09:24:37 -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=qelDdkHxD2MNryuUirLIMvENB98jiG21CK3vtO1UckI=; b=VzLCdZBgYDduKdMRG+cRnFf9v4PajAR4lSFb5Ci3FxGAR0xJ8kf/pDWGA1Z2K1dPPN YPmEpzs7zxqNbVW2YimWISods88q/hnvPDlHhlKFJAOzeJ5b/uXhB6NsgzROVPKQJaeL 4EmdgjdckQsENao7QAmF5c78LS7Ukny5sJTlkdnKL+Yke2Pf6CuzPcgIFC1eRrjLN1ea L3tGvTyyfPA3Bg5Q5wNCq9u8tFiTEJFn1PTsydKGkdsQ/VkIMqBsBZU/ze7RlSMIRzhJ kys1dg39oo9lgljUVSHX5WZiSYaP2qJqt2rdXwNsHWsP8CVFpFkov9emdiOBWKBzACeq u9DQ== 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=qelDdkHxD2MNryuUirLIMvENB98jiG21CK3vtO1UckI=; b=j/5d0yjNAbJKVRR3bpiFOHMpGca+7rrMKEBriyfvLDt/wmRIkmawYEH0Wjh4nsSDvi cYcH3TG1J9FBTic+/yQvjd2z5VwvyrAjl/TgnVqSiRnx6wGSW7pdZgyNRNZbWY1TpCfI yvahX27W3GhkSZ6EKEuTESx4HsMgQfpxZqi3p1Pf8xTud2aF2OPrLqXPt0KBcsLBlfJA +I1b1PR15ZqjRAV7gTI2NtqFg6WxTVEAfTfn4riqugiSOCDvpaOayIl6NDNgWcze34Po VH2OIGj3+c5IHQLghOBVsIdTXzUeNTBNuoHiKSGzA2lqCQlA/+efN33i6dsttVVZcZyz wHvA== X-Gm-Message-State: AOAM531pfjsHTY0ymhgQdtUlVQKqpgm/nLBuvn2ZqaLdnvoj1Jnq1MZW gqt5910dq1kJJiX9g68s4VfstQ8YgHSc5g38l5fTUv8Hc8w= X-Google-Smtp-Source: ABdhPJxvj0JqLSphQC9EpJBgwu+FyZXvu0Y2QN0ZX/qx5/Kb47mAleGE4lrO15vyO9x7gvGFY1yPfOZPYUK0bdyfW3Y= X-Received: by 2002:adf:dfc7:: with SMTP id q7mr21005381wrn.80.1595867076199; Mon, 27 Jul 2020 09:24:36 -0700 (PDT) MIME-Version: 1.0 References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <20200710125843.GA224527@LK-Perkele-VII> <702.1595377246@localhost> <75486A7D-E06F-49F8-A851-6A051816EBA7@tzi.org> In-Reply-To: <75486A7D-E06F-49F8-A851-6A051816EBA7@tzi.org> From: =?UTF-8?Q?Joel_H=C3=B6glund?= Date: Mon, 27 Jul 2020 18:24:25 +0200 Message-ID: To: Carsten Bormann Cc: Michael Richardson , draft-raza-ace-cbor-certificates@ietf.org, Ilari Liusvaara , cose@ietf.org Content-Type: multipart/alternative; boundary="0000000000002f880f05ab6ec286" Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 27 Jul 2020 16:24:55 -0000 --0000000000002f880f05ab6ec286 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi! A reply and a comment below: On Wed, 22 Jul 2020 at 13:12, Carsten Bormann wrote: > Hi Joel, > > > Michael, to quickly reply to your explicit question: the new draft was > posted before the IETF 108 deadline on 2020-07-13, which is also before t= he > expiry dates of the three different drafts that are now combined. ( > https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/ = ) > > That draft says in > https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/ > that it Replaces draft-raza-ace-cbor-certificates, > draft-mattsson-tls-cbor-cert-compress > > What is the third draft? > The current draft, draft-mattsson-cose-cbor-cert-compress-01 is the result of updating and combining: draft-raza-ace-cbor-certificates-04, draft-mattsson-tls-cbor-cert-compress-00 and draft-mattsson-cose-cbor-cert-compress-00. > > > Another observation is that while our starting point has been to encode > rfc7925 compliant certificates, we hope to make the proposal more future > proof by allowing new algorithms also deemed suitable for constrained > environments. With that target, we think it is possible to exclude RSA on > the list of supported algorithms. > > Supported for what=E2=80=A6 > > The chain may still have RSA certificates in it. > > Gr=C3=BC=C3=9Fe, Carsten > Supported for being possible to parse and validate by an IoT device: if a chain has RSA certificates in it, the end device would need to implement RSA algorithms too. Which is what we have considered out of scope. From rfc7925, the following explicit constraint is stated: There are various cryptographic algorithms available to sign digital certificates; those algorithms include RSA, the Digital Signature Algorithm (DSA), and ECDSA. ... [C]ertificates are signed using ECDSA in this profile. This is not only true for the end-entity certificates but also for all other certificates in the chain, including CA certificates.This profiling reduces the amount of flash memory needed on an IoT device to store the code of several algorithm implementations due to the smaller number of options." Best Regards Joel H=C3=B6glund Virus-free. www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> --0000000000002f880f05ab6ec286 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi!

A reply and a comment be= low:

On Wed, 22 Jul 2020 at 13:12, Carsten Bormann <cabo@tzi.org> wrote:
Hi Joel,

> Michael, to quickly reply to your explicit question: the new draft was= posted before the IETF 108 deadline on 2020-07-13, which is also before th= e expiry dates of the three different drafts that are now combined. (https://datatracker.ietf.org/doc/d= raft-mattsson-cose-cbor-cert-compress/ )

That draft says in https://d= atatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/ that it= Replaces=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-raza-ace-cbor-cert= ificates, draft-mattsson-tls-cbor-cert-compress

What is the third draft?

The current dr= aft,=C2=A0draft-mattsson-cose-cbor-cert-compress-01 is the result of updati= ng and combining:
draft-raza-ace-cbor-certificates-04,
= draft-mattsson-tls-cbor-cert-compress-00 and
draft-mattsson-cose-= cbor-cert-compress-00.
=C2=A0

> Another observation is that while our starting point has been to encod= e rfc7925 compliant certificates, we hope to make the proposal more future = proof by allowing new algorithms also deemed suitable for constrained envir= onments. With that target, we think it is possible to exclude RSA on the li= st of supported algorithms.

Supported for what=E2=80=A6

The chain may still have RSA certificates in it.

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

Supported for = being possible to parse and validate by an IoT device: if a chain has RSA c= ertificates in it, the end device would need to implement RSA algorithms to= o. Which is what we have considered out of scope. From rfc7925, the followi= ng explicit constraint is stated:=C2=A0

There are = various cryptographic algorithms available to sign digital certificates; th= ose algorithms include RSA, the Digital Signature=C2=A0Algorithm (DSA), and= ECDSA. =C2=A0... [C]ertificates are=C2=A0signed using ECDSA in this profil= e. This is not only true for the=C2=A0end-entity certificates but also for = all other certificates in the chain, including CA certificates.This profili= ng reduces the amount=C2=A0of flash memory needed on an IoT device to store= the code of several=C2=A0algorithm implementations due to the smaller numb= er of options."

Best Regards

Joel H=C3=B6glund
=C2=A0

= Virus-free. www.avg.com
--0000000000002f880f05ab6ec286-- From nobody Mon Jul 27 10:04: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 736D53A1A24 for ; Mon, 27 Jul 2020 10:04:21 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 icEjWBYhpjfJ for ; Mon, 27 Jul 2020 10:04:19 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291143A0FA3 for ; Mon, 27 Jul 2020 10:04:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 807C6300B81 for ; Mon, 27 Jul 2020 13:04:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id f3j1RUgr93iD for ; Mon, 27 Jul 2020 13:04:14 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 6F098300B5A; Mon, 27 Jul 2020 13:04:14 -0400 (EDT) From: Russ Housley Message-Id: <398A4546-4305-4935-BA00-0C9420774359@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3BAD8B9D-8101-469A-AD2F-8436C6C94547" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Mon, 27 Jul 2020 13:04:15 -0400 In-Reply-To: Cc: Ilari Liusvaara , cose@ietf.org To: =?utf-8?Q?Joel_H=C3=B6glund?= References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <20200710125843.GA224527@LK-Perkele-VII> <20200721115009.GB464556@LK-Perkele-VII> X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [COSE] Structure of CBOR certificates 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, 27 Jul 2020 17:04:22 -0000 --Apple-Mail=_3BAD8B9D-8101-469A-AD2F-8436C6C94547 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 27, 2020, at 12:09 PM, Joel H=C3=B6glund = wrote: >=20 > A follow-up question below: >=20 > > 4 bits is not sufficient to represent non-empty ordered subsets > > of 4 elements. One needs at least 6 bits for that. > >=20 > > However, one could fit the thing in 4 bits by noting that = combining > > id-kp-OCSPSigning with anything else is Bad Idea. And non-empty > > ordered subset of mutually exclusive sets of 3+1 elements does > > fit in 4 bits (A, B, C, AB, AC, BA, BC, CA, CB, ABC, ACB, BAC, = BCA, > > CAB, CBA, Z). >=20 > Yes, a SET OF would have defined an order, but it does not help the = relying party, who only cares about whether a particular OID is in the = SEQUENCE or not. >=20 > Putting them in the same order as SET OF would work for new = certificates, but it will not help with existing ones. >=20 >=20 > We read Ilari's proposal as a way to uniquely order the relevant EKU = combinations, in which case the encoding would work with both existing = and new certificates. Can you please clarify which situation you are = referring to? The ASN.1 DER encoding of SET OF specifies the order. The encoding of = SEQUENCE OF allows the sender to pick the order. I suggest we not pick = another ordering. Russ --Apple-Mail=_3BAD8B9D-8101-469A-AD2F-8436C6C94547 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 27, 2020, at 12:09 PM, Joel H=C3=B6glund <joel.hoglund@gmail.com> wrote:

A follow-up question below:

>   4 bits is not = sufficient to represent non-empty ordered subsets
>   of 4 elements. One needs at least 6 bits for that.
>
>   However, one could fit the thing in 4 bits by noting = that combining
>   id-kp-OCSPSigning with anything else is Bad Idea. And = non-empty
>   ordered subset of mutually exclusive sets of 3+1 = elements does
>   fit in 4 bits (A, B, C, AB, AC, BA, BC, CA, CB, ABC, = ACB, BAC, BCA,
>   CAB, CBA, Z).

Yes, a SET OF would have defined an order, but it does not help the = relying party, who only cares about whether a particular OID is in the = SEQUENCE or not.

Putting them in the same order as SET OF would work for new = certificates, but it will not help with existing ones.


We read Ilari's proposal as a way to uniquely order the = relevant EKU combinations, in which case the encoding would work with = both existing and new certificates. Can you please clarify which = situation you are referring = to?

The = ASN.1 DER encoding of SET OF specifies the order.  The encoding of = SEQUENCE OF allows the sender to pick the order.  I suggest we not = pick another ordering.

Russ

= --Apple-Mail=_3BAD8B9D-8101-469A-AD2F-8436C6C94547-- From nobody Tue Jul 28 06:20: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 7DE2C3A0C19 for ; Tue, 28 Jul 2020 06:20:43 -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=outer-planes-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 LllsUw2tVC6B for ; Tue, 28 Jul 2020 06:20:41 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 532B03A0C7A for ; Tue, 28 Jul 2020 06:20:15 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id a26so6045748otf.1 for ; Tue, 28 Jul 2020 06:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:autocrypt:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=AW38TNKPEDbCudwFC1bhNcmRCyuCRG133ZhquCmZV1U=; b=Z/XiVcXnCmqy8L0wN3bCLsigfqgHc2vDnd9EUUnvC7ATKhwlw/KQpONru0NnTjByzu AFF93XhwvHG+f9lVplk/nwRf6E30uAiEmumfTG2ziOOj+nuJz5FfagvdRTvmzj1G5SEH GuNW3oMNU8Ja9xkuPE2QVs19q1NFIKEvjMBO5UU/RMmNRxAM7FYqUPqS6QC8HD7/zMQ7 jmHco7xkT+CU5jazWfF5IG5nyTnU8CwDpfsvhFygpBp0jEaRSRMIu0SsX1laG4SQbmje VpALmrnjctBeFuGgGsnFRT9GRQpjVHX1ALRpkGUUIy6vFSQUOv25NfcWM8H/dzUqWV9r AtPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:autocrypt:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=AW38TNKPEDbCudwFC1bhNcmRCyuCRG133ZhquCmZV1U=; b=ipsVK6ZD9ybSKPa/qE0RovWtvk2PsT16tlBomRKK6b8FIk4vnc6zcN0l6yAvPjXV0w 4A4SOoPyQPiqnSl6mcNSiwo6npZ+rCgCw/JmRT9pTSZnWL6M2x8LKiLYbP+zJAZVVUZ6 r65mRWl2jtuviYCS58oMae3SkLhNlSejTEG5fskPUG8zeBo6399+xy7I1SGWt9Zf3R/1 x9ycNuccK63FNW5jvxEOz1G/o+1fUdq2W/Q0ioHz94+p9O4HujafPnodS065oL01SY7z SkJTaa2PFCRy7JZugyK1MgvIoBvqDt46gIGU3OC0h0SgWf7urcFmrWy52KOY9Ge5irnt WAWA== X-Gm-Message-State: AOAM530VV0f9jpbwbdbMxDfQpRqULVy+ycM3GbQZ9b2kbYeBv/G3IZPH 0Dpj7AjY5DzqqZXTd7Nw4/wQn1hXzjk= X-Google-Smtp-Source: ABdhPJwMBEG2KWHrrtAr32VdTD9JR9r1c7Aez2bOpffTAxbgtAM4gEcZGifYT9uKRzpkdsWds30fpg== X-Received: by 2002:a05:6830:1af9:: with SMTP id c25mr23821815otd.271.1595942412992; Tue, 28 Jul 2020 06:20:12 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:d80b:ad93:39ea:4d5f]) by smtp.gmail.com with ESMTPSA id j2sm57155ooo.6.2020.07.28.06.20.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jul 2020 06:20:12 -0700 (PDT) To: cose From: "Matthew A. Miller" Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBDHXWI3skGkNa8yY4Oz0 ck4QngW7BQJeDg4fBQkVMJSlAAoJEOz0ck4QngW7XCcH/RBVW3Nd0ezXtL9XSn5DHJxRTb5q 6ZVIBQgVIMcH2DVzO/aCs3o1ECONHAazVGQ9b6cwHCtPWJpM0ENGx7DERa/Ay4vDeKXc1TEX VuukdGrX2zWOaFHDT/oU1SEg0C+f3JGnaTwYQ7i2KXkFuYNmqROkB+Z0PDaLu4biCYdjhkIm Yu3frzySHhEX2VVMcJA6lcqdBTE3j2+ywQ7icpiWUcvLuhCeuFER1JjTRchcXwtuiOAKPQCZ BM9B70Q73hiKKK4ylNjhLFKGomkWDqsQ6sAENn6YkWyBuXNr5Y66uFxFS0VY938o/ZoXw4tb qUIdBzMnHkHxxiNUUBb6dPkaEGO5AQ0EUmgCigEIAMD+u4fBiVDul2Mljq3CRlwyZ52RA0vq vm00F5CTBWu+K1SMdMoqKmPEHaQSRRmjE+AwjWHv96cOtWUwwyqrpEgnzof7LHXfM0hk0GUl +ZUeAePtNPyylroD+ohxx2IhE2wVW+W8XGkfyxONVsd89h7Ft05HmQellZPNjE3JUtcwrmN6 fQHgr6+NuAUkC+ygt/MtnkHPeRvp2m7FQ3OqEPKGTn9Q9oIgW9lYG2JEqaSo/ASrwbZowmrl nhKvwJGSmgwHbmvEI9LxH4HKIfGmr5TyYq6o9WDUsnNwDuEeaazxoE3qXFKVvIqfMSDwBaCV 37r7GUle7lT9+oMAKVOPmZ8AEQEAAYkBPAQYAQoAJgIbDBYhBDHXWI3skGkNa8yY4Oz0ck4Q ngW7BQJeM+W5BQkPjlg/AAoJEOz0ck4QngW7a+IIANBU7R3t17LKflQo3nSUoqMBLkjxo9/e yzKAb3u0Fjb5md+9ESrFb03w1ZUkKLh/b6leTFq50IJbfxgDlVgkTn/j0XPOmIHpfDtVYPnA /rI5sqMzjb3qFOPFZFX9Til360uv9Zc5mlkJcM57X4aLRl7wSGRXPqh7v356s+JlvLF8rBtZ 7LU5SrCWeoWZu/7NvqW+UNEOOP2xAlOId4BeYWflkpzNcSPkhAkD2Xvw/GmyOm24Im7Ef2O5 scQhEO/dG+3jU4QnSGFtLXHndHpNM20vD6T+uWUpyp5g27KrIHApWq9M3o6KR68pTOLJrMxc th8xmHLOpuWVAKEABNQRDfE= Message-ID: <53024e78-83f9-299c-a98d-e0232ec4e14d@outer-planes.net> Date: Tue, 28 Jul 2020 07:20:11 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [COSE] IETF-108 Session - 2020-07-29 @ 13:00 UTC 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, 28 Jul 2020 13:20:44 -0000 Hello COSE WG, A reminder the session is Wednesday (tomorrow)! Where: Meetecho When: 2020-07-29 @ 13:00-13:50 UTC * Notes: https://codimd.ietf.org/notes-ietf-108-cose * Jabber: xmpp:cose@jabber.ietf.org?join * Meetecho: https://meetings.conf.meetecho.com/ietf108/?group=cose&short=&item=1 The updated agenda is below and at: https://www.ietf.org/proceedings/108/agenda/agenda-108-cose-03 Some Meetecho tips we recommend, based on our experiences: * If you want to queue “at the mic”, always Request Audio - Request Video is optional * If you are speaking, first state your name * If you are taking or tracking notes, open in a new tab/window - Windows (Chrome/Firefox/Edge): CTRL + left_click - MacOS (Chrome/Firefox/Safari): ⌘ + left_click - Linux (Chrome/Firefox): CTRL + left_click """ ## 0. Administrivia (Chairs) - 5 minutes (13:00 - 13:05) * ~Bluesheets~ * Note taker(s) * Jabber Scribe * Agenda + Bartering ## 1. Document Status (Chairs) - 5 minutes (13:05 - 13:10) * https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorithms/ * https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ * https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ * https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ### 1.1 Struct Discuss (Jim Schaad) - 10 minutes (13:10 - 13:20) * https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ * https://mailarchive.ietf.org/arch/msg/cose/yjKTObY8Gb387p6V4gwAFHts72g/ ## 2. Cert Compression (Joel Höglund) - 10 minutes (13:20 - 13:30) * https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-01 ## 3. More Algorithms (Jim Schaad) - 5 minutes (13:30 - 13:35) * https://tools.ietf.org/html/draft-schaad-cose-more-algs-01 ## 4. Chartering (Chairs) - 15 minutes (13:35 - 13:50) * (WIP) https://github.com/cose-wg/Charter/blob/master/Charter.md """ - Ivaylo & Matthew COSE WG Chairs From nobody Tue Jul 28 06:26: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 1131B3A0C6F for ; Tue, 28 Jul 2020 06:26:40 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-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=outer-planes-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 V_n80mq_2fKK for ; Tue, 28 Jul 2020 06:26:38 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 E3E2A3A0C49 for ; Tue, 28 Jul 2020 06:26:37 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id u24so7556395oiv.7 for ; Tue, 28 Jul 2020 06:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=13GosP1W6CU++1XtAbpzyIzN4FbqCThbETwGrDkJMJM=; b=ftnAvcsIw06/4cM+Nv5RM2Pi6+TrQim9SCIPHKbgWDo2hnBG3D68+wQASkmnCJfHgz HQfqBCNwBVDz4ZzuVeEaF6rz3LXMsYNY26Tq8/8fpH6SOTr2sa+mhuwyyvhVm32ysQGu a4++r0vLOq8ieMyxuIj14LIyt7EDhjM2xRlgCfVK/sTc/V5a5TNkQMAdvkrwZHZwDXHs DQ4btt7WPoJQ/r2/KSV+vvsx+JH97E0LcXf8kUfpVG+Agb3NkrmTQCPUR0ctrVtqgaqG K7dsdOp0MYXY8KtoGkK1P7x+uj+jnfq4q8IO1+awG527zWOLbFYsaU5lTleJQ0OCvMWO KE+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=13GosP1W6CU++1XtAbpzyIzN4FbqCThbETwGrDkJMJM=; b=Rdq40PyoSXDXvJ3DK0lZMES6nTzrFF7EollUNLEQe1HQ1QpSr1pLokfnfI3WmsWviP P1mhvXFdf/sqhJTheMMd09aep4Zx7wwgwMqCaaKWUn8STvStoIVjqbmO7Q48L0xp+KWD PDxy42o37vXMaPTzfDVuKdDrQryTdag3FDvWuqe/lRZ0x/SW81AoFHL4izL959jCDqXx vpIhiG7K8Kn2woY++YWffsHuHFoEzwJUidtL9jCjvffSq/5pfAAHuNEjCEAku2nMKhpk GILJoiJQfcDQwIx4OHZsHGq/cXUBPtD5k5T6RQGk8T3NLTEO9i32qkx6u1UpD9HZWvDM Nn0Q== X-Gm-Message-State: AOAM5320KTYMaXPZ2PhAgjFiWqSlwn5uQrsTRGhlpVf+sIa1czwWlxNR /D48Zco6X9l2wbcUbe07eakKhG+r5MM= X-Google-Smtp-Source: ABdhPJzsYDDc5qpQfilKztBdYlAfIdSicg7cvvC/AGZRTrDm2sMzxfTG5TYXoVXuTlpfvrvwLQqOqg== X-Received: by 2002:aca:d7c2:: with SMTP id o185mr3330826oig.50.1595942796570; Tue, 28 Jul 2020 06:26:36 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:d80b:ad93:39ea:4d5f]) by smtp.gmail.com with ESMTPSA id c26sm3942450otr.26.2020.07.28.06.26.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jul 2020 06:26:35 -0700 (PDT) To: cose@ietf.org References: <53024e78-83f9-299c-a98d-e0232ec4e14d@outer-planes.net> From: "Matthew A. Miller" Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBDHXWI3skGkNa8yY4Oz0 ck4QngW7BQJeDg4fBQkVMJSlAAoJEOz0ck4QngW7XCcH/RBVW3Nd0ezXtL9XSn5DHJxRTb5q 6ZVIBQgVIMcH2DVzO/aCs3o1ECONHAazVGQ9b6cwHCtPWJpM0ENGx7DERa/Ay4vDeKXc1TEX VuukdGrX2zWOaFHDT/oU1SEg0C+f3JGnaTwYQ7i2KXkFuYNmqROkB+Z0PDaLu4biCYdjhkIm Yu3frzySHhEX2VVMcJA6lcqdBTE3j2+ywQ7icpiWUcvLuhCeuFER1JjTRchcXwtuiOAKPQCZ BM9B70Q73hiKKK4ylNjhLFKGomkWDqsQ6sAENn6YkWyBuXNr5Y66uFxFS0VY938o/ZoXw4tb qUIdBzMnHkHxxiNUUBb6dPkaEGO5AQ0EUmgCigEIAMD+u4fBiVDul2Mljq3CRlwyZ52RA0vq vm00F5CTBWu+K1SMdMoqKmPEHaQSRRmjE+AwjWHv96cOtWUwwyqrpEgnzof7LHXfM0hk0GUl +ZUeAePtNPyylroD+ohxx2IhE2wVW+W8XGkfyxONVsd89h7Ft05HmQellZPNjE3JUtcwrmN6 fQHgr6+NuAUkC+ygt/MtnkHPeRvp2m7FQ3OqEPKGTn9Q9oIgW9lYG2JEqaSo/ASrwbZowmrl nhKvwJGSmgwHbmvEI9LxH4HKIfGmr5TyYq6o9WDUsnNwDuEeaazxoE3qXFKVvIqfMSDwBaCV 37r7GUle7lT9+oMAKVOPmZ8AEQEAAYkBPAQYAQoAJgIbDBYhBDHXWI3skGkNa8yY4Oz0ck4Q ngW7BQJeM+W5BQkPjlg/AAoJEOz0ck4QngW7a+IIANBU7R3t17LKflQo3nSUoqMBLkjxo9/e yzKAb3u0Fjb5md+9ESrFb03w1ZUkKLh/b6leTFq50IJbfxgDlVgkTn/j0XPOmIHpfDtVYPnA /rI5sqMzjb3qFOPFZFX9Til360uv9Zc5mlkJcM57X4aLRl7wSGRXPqh7v356s+JlvLF8rBtZ 7LU5SrCWeoWZu/7NvqW+UNEOOP2xAlOId4BeYWflkpzNcSPkhAkD2Xvw/GmyOm24Im7Ef2O5 scQhEO/dG+3jU4QnSGFtLXHndHpNM20vD6T+uWUpyp5g27KrIHApWq9M3o6KR68pTOLJrMxc th8xmHLOpuWVAKEABNQRDfE= Message-ID: <7411ad0c-152f-be0e-653b-e211327e0e50@outer-planes.net> Date: Tue, 28 Jul 2020 07:26:34 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <53024e78-83f9-299c-a98d-e0232ec4e14d@outer-planes.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [COSE] IETF-108 Session - REQUESTING 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: Tue, 28 Jul 2020 13:26:46 -0000 As you may have noticed, the schedule is a little tight. To help get going more quickly, we are soliciting volunteers now for: * taking notes/minutes (grab action items) * scribing to Jabber (relay "MIC" comments from Jabber to meetecho, Please message < cose-chairs@ietf.org > if you can help. Thank you! - Ivaylo and Matthew COSE WG Chairs From nobody Wed Jul 29 05:21: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 274803A09F8; Wed, 29 Jul 2020 05:20:38 -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.11.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <159602523807.31642.14106188511559151282@ietfa.amsl.com> Date: Wed, 29 Jul 2020 05:20:38 -0700 Archived-At: Subject: [COSE] Magnus Westerlund's No Objection on draft-ietf-cose-rfc8152bis-struct-11: (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, 29 Jul 2020 12:20:39 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-cose-rfc8152bis-struct-11: 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: ---------------------------------------------------------------------- Thanks for addressing my issue with the IANA registration rules. From nobody Wed Jul 29 07:13: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 9D3EC3A0B68 for ; Wed, 29 Jul 2020 07:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Wf24GNsGy3TI for ; Wed, 29 Jul 2020 07:13:03 -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 831C43A0B72 for ; Wed, 29 Jul 2020 07:12:54 -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 4BGwVV2YXJzySN; Wed, 29 Jul 2020 16:12:50 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 617724769.677-6758b7bc73b3c69cc98580ee1fe65768 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 29 Jul 2020 16:12:49 +0200 Message-Id: To: cose@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [COSE] Countersignatures X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 14:13:06 -0000 So here is my revised proposed plan for handling countersignature: =E2=80=94 remove countersignature from -struct =E2=80=94 point out that RFC 8152 defines a form of countersignatures = with known (described) drawbacks; this is still registered, so not going = away - point out that draft-ietf-=E2=80=A6 defines an updated form of = countersignatures - write draft-ietf-=E2=80=A6 (well, get that adopted swiftly), pursue = early registration - progress -struct to IS as planned. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 29 07:18: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 AF6093A0BF1 for ; Wed, 29 Jul 2020 07:18:33 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 3_rw4Iyj7yHC for ; Wed, 29 Jul 2020 07:18:32 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3348F3A0C03 for ; Wed, 29 Jul 2020 07:18:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 73AB3300B20 for ; Wed, 29 Jul 2020 10:18:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VFXh_yFDIEbi for ; Wed, 29 Jul 2020 10:18:28 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 68E3E300AB1; Wed, 29 Jul 2020 10:18:28 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Russ Housley In-Reply-To: Date: Wed, 29 Jul 2020 10:18:29 -0400 Cc: cose@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [COSE] Countersignatures X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 14:18:34 -0000 Carsten: >=20 > So here is my revised proposed plan for handling countersignature: >=20 > =E2=80=94 remove countersignature from -struct > =E2=80=94 point out that RFC 8152 defines a form of countersignatures = with known (described) drawbacks; this is still registered, so not going = away > - point out that draft-ietf-=E2=80=A6 defines an updated form of = countersignatures > - write draft-ietf-=E2=80=A6 (well, get that adopted swiftly), pursue = early registration > - progress -struct to IS as planned. >=20 I think the reasons you gave for keeping the discussion all in the same = document are compelling. Russ From nobody Wed Jul 29 08:35:02 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 335543A0CDA for ; Wed, 29 Jul 2020 08:35:00 -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 gN8IVbzeR4ID for ; Wed, 29 Jul 2020 08:34:59 -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 0408A3A0CCD for ; Wed, 29 Jul 2020 08:34: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; Wed, 29 Jul 2020 08:34:39 -0700 From: Jim Schaad To: 'Barry Leiba' CC: Date: Wed, 29 Jul 2020 08:34:39 -0700 Message-ID: <028701d665bd$c6d4d6b0$547e8410$@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: AdZlvTssP5AGQG8fR/Sy6xJ9gi6Ppw== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] Review of the algorithm document for countersignature intersection 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, 29 Jul 2020 15:35:00 -0000 Barry, I have just done a read through on draft-ietf-cose-rfc8152bis-algs looking for potential conflicts with the changes in the Countersignature issue. I did not find any issues that should hold up the document from being pushed to the RFC Editor. Jim From nobody Wed Jul 29 11:41:29 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 AF8A13A0E11 for ; Wed, 29 Jul 2020 11:41:27 -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 XJR9OVpxlZue for ; Wed, 29 Jul 2020 11:41:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F344B3A0E03 for ; Wed, 29 Jul 2020 11:41:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1BD7138A16; Wed, 29 Jul 2020 14:20:51 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YI4H0oTz-_Tk; Wed, 29 Jul 2020 14:20:49 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3ADC0389C4; Wed, 29 Jul 2020 14:20:49 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E9A0A1AA; Wed, 29 Jul 2020 14:41:21 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , cose@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [COSE] Countersignatures X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 18:41:28 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > So here is my revised proposed plan for handling countersignature: > =E2=80=94 remove countersignature from -struct > =E2=80=94 point out that RFC 8152 defines a form of countersignatures= with known (described) drawbacks; this is still registered, so not going a= way > - point out that draft-ietf-=E2=80=A6 defines an updated form of coun= tersignatures > - write draft-ietf-=E2=80=A6 (well, get that adopted swiftly), pursue= early registration > - progress -struct to IS as planned. I initially preferred to delay the document and fix it, and have it all in one document. The interruption of the IS plan made me rethink things. The possibility to fix things, and cycle at PS, and then status change after implementation experience is appealing to me. However, after some thought (and lunch), I have come to think that the countersignatures are not worth holding the rest of the document. If we can point out the flaws and say where to look to get them right, than that's almost as good as having it in one document. Jim later said that the OSCORE use of countersignatures will not be affecte= d: the way they are using them they will identical in old and new formulation, because the differences do not affect them. Still, I think there is time for them to point to the new document. So I can live with Carsten's recommendation. I can also live with cycling at PS and doing a status change. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8hwtEACgkQgItw+93Q 3WXiZQf/RA8M8rr1gMSTFggB806C7bo0ipR84DvbSbsCsqdPGeU455DjbaBHhjaP dDp2VUcMCm9GKF2lGW4iYEeRTSJCb3xDM6uJ+15GZp5YdX3jOYH8Q7IPTJJU5Yw7 5Cgt7erKxAbM3T/KP/MqnM+MGx7RcJe6tKKdCSB955qrVjmR+71CDkubzMaiP76L vRnNh0pWly4DijfMzBrBrMmKGrP65+/UPR5aWQD8jA0PruSqDdTqNYj4kpBO3WYK 1glzMRdCh4mvsv+3O8YcQf/Ykbsh7/K2UeEyHPb6M4jPWqKWLHrMpUcPoMdUw3pi r1tWx05Y+gEUBVEmGnNBKUGfpAs7LA== =I1WU -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 29 12:05:00 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 F037F3A0E34; Wed, 29 Jul 2020 12:04: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.11.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <159604949893.26037.18440671888139753752@ietfa.amsl.com> Date: Wed, 29 Jul 2020 12:04:58 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-hash-algs-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, 29 Jul 2020 19:04: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): Hash Algorithms Author : Jim Schaad Filename : draft-ietf-cose-hash-algs-07.txt Pages : 12 Date : 2020-07-29 Abstract: The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods for using hash algorithms. 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. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-hash-algs-07 https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-hash-algs-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 Jul 29 12:11: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 EED6F3A0E49; Wed, 29 Jul 2020 12:11:04 -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.11.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <159604986490.26275.5128064194472784805@ietfa.amsl.com> Date: Wed, 29 Jul 2020 12:11:04 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-hash-algs-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: Wed, 29 Jul 2020 19:11:05 -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): Hash Algorithms Author : Jim Schaad Filename : draft-ietf-cose-hash-algs-08.txt Pages : 12 Date : 2020-07-29 Abstract: The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods for using hash algorithms. 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. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-hash-algs-08 https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-hash-algs-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 Wed Jul 29 12:13:09 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 D87FF3A0E3C for ; Wed, 29 Jul 2020 12:13:07 -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 IEKxypRBuFnU for ; Wed, 29 Jul 2020 12:13:05 -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 8F4AB3A0E3B for ; Wed, 29 Jul 2020 12:13:05 -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, 29 Jul 2020 12:12:59 -0700 From: Jim Schaad To: 'Murray Kucherawy' CC: References: <159604986490.26275.5128064194472784805@ietfa.amsl.com> In-Reply-To: <159604986490.26275.5128064194472784805@ietfa.amsl.com> Date: Wed, 29 Jul 2020 12:12:58 -0700 Message-ID: <02e201d665dc$46d987c0$d48c9740$@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: AQL3F9ayyrbPpvS29ex2cZTN4KDfaKbdiKoQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] FW: I-D Action: draft-ietf-cose-hash-algs-08.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: Wed, 29 Jul 2020 19:13:08 -0000 Murray, I am feeling slightly stupid at the moment. I was sure that I had uploaded this version of the document to the Datatracker and after the meeting today I looked and found out that I hadn't. I think this version addresses all of the IESG comments along with anything else that was floating around. And of course as soon as I had posted the last version I remembered that I had not made an edit that was highlighted by Russ. Jim -----Original Message----- From: COSE On Behalf Of internet-drafts@ietf.org Sent: Wednesday, July 29, 2020 12:11 PM To: i-d-announce@ietf.org Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-hash-algs-08.txt 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): Hash Algorithms Author : Jim Schaad Filename : draft-ietf-cose-hash-algs-08.txt Pages : 12 Date : 2020-07-29 Abstract: The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods for using hash algorithms. 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. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-hash-algs-08 https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-hash-algs-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/ _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Wed Jul 29 12:27:14 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 2DF1E3A0E49 for ; Wed, 29 Jul 2020 12:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 BoGnik3j_FWr for ; Wed, 29 Jul 2020 12:27:11 -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 634273A0E45 for ; Wed, 29 Jul 2020 12:27:11 -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 06TJR2b7006306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jul 2020 15:27:04 -0400 Date: Wed, 29 Jul 2020 12:27:02 -0700 From: Benjamin Kaduk To: Jim Schaad Cc: "'Murray Kucherawy'" , cose@ietf.org Message-ID: <20200729192702.GE92412@kduck.mit.edu> References: <159604986490.26275.5128064194472784805@ietfa.amsl.com> <02e201d665dc$46d987c0$d48c9740$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02e201d665dc$46d987c0$d48c9740$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] FW: I-D Action: draft-ietf-cose-hash-algs-08.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: Wed, 29 Jul 2020 19:27:13 -0000 Hi Jim, Perhaps I should be feeling slightly stupid, but was the -07 intended to do anything other than update the version of some references (which is what it looks like from here)? Thanks, Ben On Wed, Jul 29, 2020 at 12:12:58PM -0700, Jim Schaad wrote: > Murray, > > I am feeling slightly stupid at the moment. I was sure that I had uploaded > this version of the document to the Datatracker and after the meeting today > I looked and found out that I hadn't. I think this version addresses all of > the IESG comments along with anything else that was floating around. > > And of course as soon as I had posted the last version I remembered that I > had not made an edit that was highlighted by Russ. > > Jim > > > > -----Original Message----- > From: COSE On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, July 29, 2020 12:11 PM > To: i-d-announce@ietf.org > Cc: cose@ietf.org > Subject: [COSE] I-D Action: draft-ietf-cose-hash-algs-08.txt > > > 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): Hash > Algorithms > Author : Jim Schaad > Filename : draft-ietf-cose-hash-algs-08.txt > Pages : 12 > Date : 2020-07-29 > > Abstract: > The CBOR Object Signing and Encryption (COSE) syntax > [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods > for using hash algorithms. 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. This document > defines a set of hash algorithms that are identified by COSE > Algorithm Identifiers. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-cose-hash-algs-08 > https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-hash-algs-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/ > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Wed Jul 29 13:05: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 9A3303A0EBB for ; Wed, 29 Jul 2020 13:05:31 -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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-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 8IuS_cag8p06 for ; Wed, 29 Jul 2020 13:05:30 -0700 (PDT) Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) (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 65A913A0EAB for ; Wed, 29 Jul 2020 13:05:30 -0700 (PDT) Received: by mail-il1-f175.google.com with SMTP id c16so8725095ils.8 for ; Wed, 29 Jul 2020 13:05:30 -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=09LYgBq6fljUbapf0108+X9UhwP30JFNnk1eJEu6ShE=; b=PJzSc3//SgNyH/cScm3ottl+zSRxcQctrUE/jw2PZbSKdNLoLn21Eaq6V24HkQ+8Y8 VwOCWroP+B58vlLumEizpcvIDwe+a+RNc695DHCjBWt7hn4zz/4q3seiifd3EHdVt0uz qJ4DLrzcaYS1HBRUpeIwTRUs4kE619iH8V9rfTRi7YTPLrIXfPPPjbVeorHFKZG9Okgc +VDGl7bn7qB1hols2vTNLeEyV+RVMq7k1gLlx15FsHC3UqQYC7hkv1QsHspRYllgbY6l BX8bOl+nd+Aq6d5BWlMZCAAbVTOrqEELRLK2iIbR8I++q2dAQxP/4KAtAVzinEJcUG+v 7QJQ== X-Gm-Message-State: AOAM530Xsr1B1ROx78rjc8qQbj6Drq856mv2DVSpNGOMiqfgy4NOozJ/ YZmvd565JlwsSofsqzftR7JOSX+fj+0wH4HNgfw15A== X-Google-Smtp-Source: ABdhPJw+fgekQXoR6v1SGEXC5NUdcTclDNbD37Nf6ZU6zJsGxjlmKlolHbMisqjszudB+WfCeq/QEo/oVlDmk1tTbyI= X-Received: by 2002:a92:2008:: with SMTP id j8mr27647473ile.277.1596053129572; Wed, 29 Jul 2020 13:05:29 -0700 (PDT) MIME-Version: 1.0 References: <028701d665bd$c6d4d6b0$547e8410$@augustcellars.com> In-Reply-To: <028701d665bd$c6d4d6b0$547e8410$@augustcellars.com> From: Barry Leiba Date: Wed, 29 Jul 2020 16:05:18 -0400 Message-ID: To: Jim Schaad Cc: cose@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [COSE] Review of the algorithm document for countersignature intersection 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, 29 Jul 2020 20:05:32 -0000 Ack; thanks. I had been holding algs in wait for struct. Should I go ahead and send algs up, even if struct needs more work... and even if it needs to stay at PS? b On Wed, Jul 29, 2020 at 11:35 AM Jim Schaad wrote: > > Barry, > > I have just done a read through on draft-ietf-cose-rfc8152bis-algs looking > for potential conflicts with the changes in the Countersignature issue. I > did not find any issues that should hold up the document from being pushed > to the RFC Editor. > > Jim > > From nobody Wed Jul 29 18:00:52 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 0A7A53A0B25 for ; Wed, 29 Jul 2020 18:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 UrVlzG7D9HRU for ; Wed, 29 Jul 2020 18:00:49 -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 AFD6A3A0B24 for ; Wed, 29 Jul 2020 18:00:49 -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 06U10f5Q013534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jul 2020 21:00:43 -0400 Date: Wed, 29 Jul 2020 18:00:40 -0700 From: Benjamin Kaduk To: Barry Leiba Cc: Jim Schaad , cose@ietf.org Message-ID: <20200730010040.GR92412@kduck.mit.edu> References: <028701d665bd$c6d4d6b0$547e8410$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] Review of the algorithm document for countersignature intersection 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, 30 Jul 2020 01:00:51 -0000 Since -algs is Informational either way, it's not clear that it would depend on whether -struct is PS or IS. (Right?) -Ben On Wed, Jul 29, 2020 at 04:05:18PM -0400, Barry Leiba wrote: > Ack; thanks. > I had been holding algs in wait for struct. Should I go ahead and > send algs up, even if struct needs more work... and even if it needs > to stay at PS? > > b > > On Wed, Jul 29, 2020 at 11:35 AM Jim Schaad wrote: > > > > Barry, > > > > I have just done a read through on draft-ietf-cose-rfc8152bis-algs looking > > for potential conflicts with the changes in the Countersignature issue. I > > did not find any issues that should hold up the document from being pushed > > to the RFC Editor. > > > > Jim > > > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Thu Jul 30 04:55: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 40E423A1069 for ; Thu, 30 Jul 2020 04:55:16 -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 ARGKk6ZepxkP for ; Thu, 30 Jul 2020 04:55:13 -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 58E7D3A0DFA for ; Thu, 30 Jul 2020 04:55:13 -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, 30 Jul 2020 04:55:07 -0700 From: Jim Schaad To: 'Benjamin Kaduk' , 'Barry Leiba' CC: References: <028701d665bd$c6d4d6b0$547e8410$@augustcellars.com> <20200730010040.GR92412@kduck.mit.edu> In-Reply-To: <20200730010040.GR92412@kduck.mit.edu> Date: Thu, 30 Jul 2020 04:55:05 -0700 Message-ID: <034001d66668$45e86b60$d1b94220$@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: AQLwLTYExACyKlDi7IPdVAVUG96j6wFCQ4ZXAnFEjtGmztmJAA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Review of the algorithm document for countersignature intersection 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, 30 Jul 2020 11:55:17 -0000 -algs has a normative dependency on -struct so it gets held in the RFC Editor queue. But no it should not care what the status is. I think it can be released because that is a better reflection of the work status. -----Original Message----- From: Benjamin Kaduk Sent: Wednesday, July 29, 2020 6:01 PM To: Barry Leiba Cc: Jim Schaad ; cose@ietf.org Subject: Re: [COSE] Review of the algorithm document for countersignature intersection Since -algs is Informational either way, it's not clear that it would depend on whether -struct is PS or IS. (Right?) -Ben On Wed, Jul 29, 2020 at 04:05:18PM -0400, Barry Leiba wrote: > Ack; thanks. > I had been holding algs in wait for struct. Should I go ahead and > send algs up, even if struct needs more work... and even if it needs > to stay at PS? > > b > > On Wed, Jul 29, 2020 at 11:35 AM Jim Schaad wrote: > > > > Barry, > > > > I have just done a read through on draft-ietf-cose-rfc8152bis-algs > > looking for potential conflicts with the changes in the > > Countersignature issue. I did not find any issues that should hold > > up the document from being pushed to the RFC Editor. > > > > Jim > > > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Thu Jul 30 07:45: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 3D8FF3A125C for ; Thu, 30 Jul 2020 07:45:33 -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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-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 g8q18U4NNGYC for ; Thu, 30 Jul 2020 07:45:29 -0700 (PDT) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (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 735F23A1228 for ; Thu, 30 Jul 2020 07:45:13 -0700 (PDT) Received: by mail-io1-f53.google.com with SMTP id w12so14840060iom.4 for ; Thu, 30 Jul 2020 07:45:13 -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=w1RumBuvYAYzcXhiAWkLbPVJmXCsb9fC8CNmmjF690M=; b=qV0PHUmrQEUUzp8Rvi0cuxVZmuJdmEiHiiz/SPB9V/P9jBFOj+1R3Vams8VvYrHRdk a8aO9JEL6itLzVwY1BDk4eLRHiF5SHxNY+dipu9C17Jc1BjUjOtfyp05439NGMCF/tM0 MO0x6s3av2BmX2/idAA3GWJhkEKGsEvXjVo5GLTieVqU1xaHCFCXcX9pvkqeQ/t8G+mh 8TodMnkK1e80LYNhTZBNrNc8Rz3H291NUNPNYjMTc2GN2KKXP6B2z1vMhrnSYHX6yo7v V6PPTaxHD3HgJpqcA4eQyIkWEyGOIxjUT/4WjBKmdLXsjMDDaRH84xsYpevUau5lgwsw rhcQ== X-Gm-Message-State: AOAM530Pj152nLlwMK6WuD/pqDCAUTRWfTWpGOfUTYIJqDZcLzPYLeBs fW7YKTvJmZaImYhSVeYwOCFx6D3cfbR1gQWC2+4= X-Google-Smtp-Source: ABdhPJzRiLXnGqGYJ64/21pG9XQR3wFf/E+0hyshzoHZ/wsKJUPC5N4WW42ykN305LvZlLqrNUyNi3kEwgL6/SP1Obg= X-Received: by 2002:a5e:dd02:: with SMTP id t2mr25017050iop.90.1596120312563; Thu, 30 Jul 2020 07:45:12 -0700 (PDT) MIME-Version: 1.0 References: <028701d665bd$c6d4d6b0$547e8410$@augustcellars.com> <20200730010040.GR92412@kduck.mit.edu> <034001d66668$45e86b60$d1b94220$@augustcellars.com> In-Reply-To: <034001d66668$45e86b60$d1b94220$@augustcellars.com> From: Barry Leiba Date: Thu, 30 Jul 2020 10:45:01 -0400 Message-ID: To: Jim Schaad Cc: Benjamin Kaduk , cose@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [COSE] Review of the algorithm document for countersignature intersection 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, 30 Jul 2020 14:45:39 -0000 Ack; releasing it now. b On Thu, Jul 30, 2020 at 7:55 AM Jim Schaad wrote: > > -algs has a normative dependency on -struct so it gets held in the RFC > Editor queue. But no it should not care what the status is. > > I think it can be released because that is a better reflection of the work > status. > > -----Original Message----- > From: Benjamin Kaduk > Sent: Wednesday, July 29, 2020 6:01 PM > To: Barry Leiba > Cc: Jim Schaad ; cose@ietf.org > Subject: Re: [COSE] Review of the algorithm document for countersignature > intersection > > Since -algs is Informational either way, it's not clear that it would depend > on whether -struct is PS or IS. (Right?) > > -Ben > > On Wed, Jul 29, 2020 at 04:05:18PM -0400, Barry Leiba wrote: > > Ack; thanks. > > I had been holding algs in wait for struct. Should I go ahead and > > send algs up, even if struct needs more work... and even if it needs > > to stay at PS? > > > > b > > > > On Wed, Jul 29, 2020 at 11:35 AM Jim Schaad > wrote: > > > > > > Barry, > > > > > > I have just done a read through on draft-ietf-cose-rfc8152bis-algs > > > looking for potential conflicts with the changes in the > > > Countersignature issue. I did not find any issues that should hold > > > up the document from being pushed to the RFC Editor. > > > > > > Jim > > > > > > > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > From nobody Thu Jul 30 07:54:58 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 B804D3A044A; Thu, 30 Jul 2020 07:54:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Cc: cose-chairs@ietf.org, rfc-editor@rfc-editor.org, cose@ietf.org, barryleiba@gmail.com, The IESG , draft-ietf-cose-rfc8152bis-algs@ietf.org, linuxwolf+ietf@outer-planes.net, Matthew Miller MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <159612089570.23306.16624832534711317488@ietfa.amsl.com> Date: Thu, 30 Jul 2020 07:54:55 -0700 Archived-At: Subject: [COSE] Document Action: 'CBOR Object Signing and Encryption (COSE): Initial Algorithms' to Informational RFC (draft-ietf-cose-rfc8152bis-algs-11.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, 30 Jul 2020 14:54:56 -0000 The IESG has approved the following document: - 'CBOR Object Signing and Encryption (COSE): Initial Algorithms' (draft-ietf-cose-rfc8152bis-algs-11.txt) as Informational RFC This document is the product of the CBOR Object Signing and Encryption Working Group. The IESG contact persons are Barry Leiba, Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ Technical Summary The document draft-ietf-rfc8152bis-algs is an update to CBOR Object Signing and Encryption (COSE) to addressing outstanding errata, make other clarifications and fixes. This is part of a set — this for the algorithms, the other detailing the structure and process — that together obsolete RFC 8152. Working Group Summary This -algs document is intended to be published as informational, rather than as Internet Standard as is its -struct counterpart. This is intentional: cryptographic algorithms become obsolete over time as improvements in computing and mathematics can realize vulnerabilities and deficiencies not possible when first published. Publishing as Information marks the state of consensus at the time of publication, and allows for the flexibility to deprecate and obsolete in the future. This document received wide review from various implementers, including those used in real-world deployments. There were a number of editorial comments and some substantive commentary, with consensus to publish. Document Quality Additional care during editing and review of this document and draft-ietf-cose-rfc8152bis-struct were taken to ensure as best as possible that various (internal) references made in the original RFC 8152 have proper (external) references. All errata from RFC 8152 that is relevant to the COSE algorithms has been addressed therein. The CryptoForum Research Group (CFRG) published algorithm documents as Informational; the normative references are expected and exist in the Downref Registry. The only exception is RFC 8439 (ChaCha20/Poly1035), which ought to be added to the Downref Registry. The normatively referenced documents from NIST and SECG are the authoritative description for those algorithms; these "downrefs" are expected. This document and draft-ietf-cose-rfc8152bis-algs are to be published in lockstep, and so references here to -struct (and references to this document in -struct) are expected to be updated as part of publication. The referent to draft-ietf-cose-hash-sig, which is already in the RFC Editor's queue, is also expected to be updated as part of publication. Personnel This work is a product of the COSE Working Group. The document shepherd is Matthew Miller, and the responsible Area Director is Barry Leiba. From nobody Thu Jul 30 07:57: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 3E1E73A07C4 for ; Thu, 30 Jul 2020 07:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_TONAME_EQ_TOLOCAL_SHORT=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-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 tP9BSgoEgmP3 for ; Thu, 30 Jul 2020 07:57:38 -0700 (PDT) Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 DB3553A0544 for ; Thu, 30 Jul 2020 07:57:37 -0700 (PDT) Received: by mail-oo1-xc2a.google.com with SMTP id k63so2440198oob.1 for ; Thu, 30 Jul 2020 07:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:autocrypt:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=uo56NcxNTOtzs74pyQf7Yj5W7Oj0odPhWMn5O811zZI=; b=OrCyVKSZxL/d8zjB1Ak9pDm7s+qwOyg2sygu9n2+zHM6Rj3vw5e3zmrR03TnmuK++O 5QDp3ouxTpCfCUBVvlgaQTfFkD4fD8xp/56HK+DRw7lhtfP7TDdlXTFnMOAxETKTWQsx xh56EXpkqnlAPhboDF8e/4rwGfTy4ZJ0fdL77mDi7Ork/d07o8XBcOmafv69oru6yAj6 QAgAyynE7aI61McXPl3bAt/+yw7dp0Vxu27zpbGP9Ca5RYsfyse5Mxoq+vspkjBjhx+Y Gy3IpDDG1t6elYDJ4YysiP83m3+gEnPQIc9JsuGHvGdtTfz8B17ZZlGXv4LZVerLAYOq XRug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:autocrypt:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=uo56NcxNTOtzs74pyQf7Yj5W7Oj0odPhWMn5O811zZI=; b=tAbEsQi1y4D7FlBiT+4g+CLWvYlLy2RreROoteupvK0GhLEkx/CJlevH0MOjGlp7ma hbZXiIukyRmaW8oMRN0QTkjVmCCOBy5ij9C78aLMpnCC+D0FIwmMVMNXYiZTaemRlm7B vyuBjthRxLi+9wJ4RVKgfg9sRN3MAxnVjaUjswqc4p1T17xHP9qlAEM1EalSD/ZCpxCR FzcRCugrJYNs6pYh/BAk+DkG+h2Q9FuymZfn6sbiUttqjiF7/luGG+ch657c9H+H10ww GmdXnJnnKN6IBJx4FRtQVWcJjGNguoaPc/BQ5YyDg/ExRleUgKHKHYHbeeOoH1a5rPcO hyvA== X-Gm-Message-State: AOAM531OXwgQS03egvK0BFAtChy4DTnMFVtJcTzdONdzqmOLlOBcC+zf ZAJOIBfTcfNeberP91hBAT3OvFgac6Y= X-Google-Smtp-Source: ABdhPJzP/SsY2S7M9cBAatYvsfpDrlL4Op3qbA2OgF9WoQ4iYt79mZZpglSsSx11Zl+bfFCAvjtOMA== X-Received: by 2002:a4a:e9f7:: with SMTP id w23mr1332936ooc.56.1596121056451; Thu, 30 Jul 2020 07:57:36 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:8c63:32cf:6d29:1e05]) by smtp.gmail.com with ESMTPSA id k16sm934681otl.63.2020.07.30.07.57.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jul 2020 07:57:35 -0700 (PDT) To: cose From: "Matthew A. Miller" Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBDHXWI3skGkNa8yY4Oz0 ck4QngW7BQJeDg4fBQkVMJSlAAoJEOz0ck4QngW7XCcH/RBVW3Nd0ezXtL9XSn5DHJxRTb5q 6ZVIBQgVIMcH2DVzO/aCs3o1ECONHAazVGQ9b6cwHCtPWJpM0ENGx7DERa/Ay4vDeKXc1TEX VuukdGrX2zWOaFHDT/oU1SEg0C+f3JGnaTwYQ7i2KXkFuYNmqROkB+Z0PDaLu4biCYdjhkIm Yu3frzySHhEX2VVMcJA6lcqdBTE3j2+ywQ7icpiWUcvLuhCeuFER1JjTRchcXwtuiOAKPQCZ BM9B70Q73hiKKK4ylNjhLFKGomkWDqsQ6sAENn6YkWyBuXNr5Y66uFxFS0VY938o/ZoXw4tb qUIdBzMnHkHxxiNUUBb6dPkaEGO5AQ0EUmgCigEIAMD+u4fBiVDul2Mljq3CRlwyZ52RA0vq vm00F5CTBWu+K1SMdMoqKmPEHaQSRRmjE+AwjWHv96cOtWUwwyqrpEgnzof7LHXfM0hk0GUl +ZUeAePtNPyylroD+ohxx2IhE2wVW+W8XGkfyxONVsd89h7Ft05HmQellZPNjE3JUtcwrmN6 fQHgr6+NuAUkC+ygt/MtnkHPeRvp2m7FQ3OqEPKGTn9Q9oIgW9lYG2JEqaSo/ASrwbZowmrl nhKvwJGSmgwHbmvEI9LxH4HKIfGmr5TyYq6o9WDUsnNwDuEeaazxoE3qXFKVvIqfMSDwBaCV 37r7GUle7lT9+oMAKVOPmZ8AEQEAAYkBPAQYAQoAJgIbDBYhBDHXWI3skGkNa8yY4Oz0ck4Q ngW7BQJeM+W5BQkPjlg/AAoJEOz0ck4QngW7a+IIANBU7R3t17LKflQo3nSUoqMBLkjxo9/e yzKAb3u0Fjb5md+9ESrFb03w1ZUkKLh/b6leTFq50IJbfxgDlVgkTn/j0XPOmIHpfDtVYPnA /rI5sqMzjb3qFOPFZFX9Til360uv9Zc5mlkJcM57X4aLRl7wSGRXPqh7v356s+JlvLF8rBtZ 7LU5SrCWeoWZu/7NvqW+UNEOOP2xAlOId4BeYWflkpzNcSPkhAkD2Xvw/GmyOm24Im7Ef2O5 scQhEO/dG+3jU4QnSGFtLXHndHpNM20vD6T+uWUpyp5g27KrIHApWq9M3o6KR68pTOLJrMxc th8xmHLOpuWVAKEABNQRDfE= Message-ID: Date: Thu, 30 Jul 2020 08:57:34 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [COSE] COSE WG @ IETF-108 Minutes 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, 30 Jul 2020 14:57:46 -0000 Minutes from the COSE WG @ IETF-108 session are uploaded to datatracker. Please send any corrections and the minutes will be updated. * Minutes: < https://www.ietf.org/proceedings/108/minutes/minutes-108-cose-01.txt > A big thank you to Francesca Palombini for taking minutes. -- Ivaylo and Matthew COSE WG Chairs From nobody Fri Jul 31 05:55:09 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 C01A93A0B22 for ; Fri, 31 Jul 2020 05:55:06 -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 FnaXUc0_XR37 for ; Fri, 31 Jul 2020 05:55:04 -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 6ED423A0AE0 for ; Fri, 31 Jul 2020 05: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; Fri, 31 Jul 2020 05:54:55 -0700 From: Jim Schaad To: Date: Fri, 31 Jul 2020 05:54:54 -0700 Message-ID: <042401d66739$cab9a850$602cf8f0$@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: AdZnOPpgBbs2bHUEQxeKwSukSS5Wng== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] Possible future structure 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, 31 Jul 2020 12:55:07 -0000 One of the issues that I mentioned in the discussion was that there were possible structures that might be defined in the future, but I did not have a good idea of what one would look like. At the time I was thinking of the Hybrid Encryption document in CFRG, but a better example might be to look at the old PKCS#7 Sign and Encrypt structure. COSE_SignAndEncrypt ::= { Headers, // encryption headers Encryption Content Recipient array Headers, // Signed headers Signature } I defined two separate set of headers just to make things really complicated not because it is necessary. The problem with stripping the signature that caused it to be dropped from CMS can be solved by including the structure name as part of the signed and encryption process so you cannot convert this into just an encryption only item. If you try and compute a counter signature on this object you want to include * Encryption protected headers * Encryption content * Signed protected headers * Signature value This is a case where saying that we want to include all of the binary string objects in the structure as input to the countersignature process is what is desired. Jim From nobody Fri Jul 31 07:15: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 69BE53A1396 for ; Fri, 31 Jul 2020 07:15:19 -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 lwuDTV-Gfdoz for ; Fri, 31 Jul 2020 07:15:17 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693853A1363 for ; Fri, 31 Jul 2020 07:15:17 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id 4so9628882vsf.11 for ; Fri, 31 Jul 2020 07:15:17 -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=j1zYbhfZGUXcdX+mf8/TYUnwEDZl9o/Xx1VvwngCnOw=; b=R4kVQdGLsnpFXk9gmJNQ5FjW9B31PpLEwiBcgsTq4+Q9hmm/Aj4zAW5YRNqe6kOYDX NLGlRPo8Ip5AA3356oyJ0J6qgbLrbkcpwefooD79/Xv4ls6F7b9LrmM5/hxgVcdZ82k6 j3Wpd98fyza4LMTvsYrNymLWhQEjD24CMBxu2YgpyWJGjRJJjhETQPw16HaPeApRFBVX S4jszqjEhXClh+7jS5mQApE0YvPBZ2osu1A1fTS0FwMGhmsJKIbTHlBbkPk3oXJij4kO NzK+FWuZbnJ/48KUesUBooSdDjmQmBE7H+/7XOlavqGNQ7rXM2d4kgCeIaGlg18EezKD g0Jw== 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=j1zYbhfZGUXcdX+mf8/TYUnwEDZl9o/Xx1VvwngCnOw=; b=r++wb1YrObGXn5umrGWMO8Fl0OetqlWJ5NFQPkyBvF4/LJfcKodKWea5/oLDgAMd9s uyATtweoXJqxYn36/QxmMw/E2Fkz4j+xgBNoAwJK2r3GbOoM9ERtQz9xFW0bJIep/flx wCrrOhdGXGhOFnHUNY3gCy8mh2Tf7Da4PkQ7UQ/A6Wso44RfwNaZv/FXPHk7iE/SBWJB Nm6fdGAWMwbti1Vj63UErtpgt+8R6A5ehSU5VnJuYjUz4mnFKZxKqE0tOtSt94o8/dft dX1mkoQYPyawwaxuW9vlse4CYal49veRliEo+IieOk2epicj6INCR+UNj1mae+ok7Jj9 CTAQ== X-Gm-Message-State: AOAM5338Fm9ydFP32JPl48mD5aSL2hd57eEbEmpLcQh2mzTKaoaY+BLx LzLMDYOwooD6I4ybvnjCk0t4WtxBOkQq3DCuCUM= X-Google-Smtp-Source: ABdhPJwzSJ/QkkTy3aw4XNvgmMEELkqBY4GLkLcLB82S+UCd1fQqzssUF4emy6vrPsd6WUslCdsiR2UNP8cvFBmPeA0= X-Received: by 2002:a05:6102:1c9:: with SMTP id s9mr3345869vsq.13.1596204916315; Fri, 31 Jul 2020 07:15:16 -0700 (PDT) MIME-Version: 1.0 References: <159604986490.26275.5128064194472784805@ietfa.amsl.com> <02e201d665dc$46d987c0$d48c9740$@augustcellars.com> <20200729192702.GE92412@kduck.mit.edu> In-Reply-To: <20200729192702.GE92412@kduck.mit.edu> From: "Murray S. Kucherawy" Date: Fri, 31 Jul 2020 07:14:59 -0700 Message-ID: To: Benjamin Kaduk Cc: Jim Schaad , cose@ietf.org Content-Type: multipart/alternative; boundary="000000000000069b6d05abbd6bb2" Archived-At: Subject: Re: [COSE] FW: I-D Action: draft-ietf-cose-hash-algs-08.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, 31 Jul 2020 14:15:20 -0000 --000000000000069b6d05abbd6bb2 Content-Type: text/plain; charset="UTF-8" So are we back to "Revised I-D Needed" here, or is it ready? On Wed, Jul 29, 2020 at 12:27 PM Benjamin Kaduk wrote: > Hi Jim, > > Perhaps I should be feeling slightly stupid, but was the -07 intended to do > anything other than update the version of some references (which is what it > looks like from here)? > > Thanks, > > Ben > > On Wed, Jul 29, 2020 at 12:12:58PM -0700, Jim Schaad wrote: > > Murray, > > > > I am feeling slightly stupid at the moment. I was sure that I had > uploaded > > this version of the document to the Datatracker and after the meeting > today > > I looked and found out that I hadn't. I think this version addresses > all of > > the IESG comments along with anything else that was floating around. > > > > And of course as soon as I had posted the last version I remembered that > I > > had not made an edit that was highlighted by Russ. > > > > Jim > > > > > > > > -----Original Message----- > > From: COSE On Behalf Of internet-drafts@ietf.org > > Sent: Wednesday, July 29, 2020 12:11 PM > > To: i-d-announce@ietf.org > > Cc: cose@ietf.org > > Subject: [COSE] I-D Action: draft-ietf-cose-hash-algs-08.txt > > > > > > 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): Hash > > Algorithms > > Author : Jim Schaad > > Filename : draft-ietf-cose-hash-algs-08.txt > > Pages : 12 > > Date : 2020-07-29 > > > > Abstract: > > The CBOR Object Signing and Encryption (COSE) syntax > > [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods > > for using hash algorithms. 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. This document > > defines a set of hash algorithms that are identified by COSE > > Algorithm Identifiers. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-cose-hash-algs-08 > > https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs-08 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-hash-algs-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/ > > > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > --000000000000069b6d05abbd6bb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So are we back to "Revised I-D Needed" here, or = is it ready?

On Wed, Jul 29, 2020 at 12:27 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Jim,

Perhaps I should be feeling slightly stupid, but was the -07 intended to do=
anything other than update the version of some references (which is what it=
looks like from here)?

Thanks,

Ben

On Wed, Jul 29, 2020 at 12:12:58PM -0700, Jim Schaad wrote:
> Murray,
>
> I am feeling slightly stupid at the moment.=C2=A0 I was sure that I ha= d uploaded
> this version of the document to the Datatracker and after the meeting = today
> I looked and found out that I hadn't.=C2=A0 I think this version a= ddresses all of
> the IESG comments along with anything else that was floating around. >
> And of course as soon as I had posted the last version I remembered th= at I
> had not made an edit that was highlighted by Russ.
>
> Jim
>
>
>
> -----Original Message-----
> From: COSE <cose-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org
> Sent: Wednesday, July 29, 2020 12:11 PM
> To: i-d-ann= ounce@ietf.org
> Cc: cose@ietf.org
> Subject: [COSE] I-D Action: draft-ietf-cose-hash-algs-08.txt
>
>
> 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.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: CBOR Object Signing and Encryption (COSE): Hash
> Algorithms
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : Jim Schaad
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-cose-hash-algs-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 12
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2020-07-29
>
> Abstract:
>=C2=A0 =C2=A0 The CBOR Object Signing and Encryption (COSE) syntax
>=C2=A0 =C2=A0 [I-D.ietf-cose-rfc8152bis-struct] does not define any dir= ect methods
>=C2=A0 =C2=A0 for using hash algorithms.=C2=A0 There are, however, circ= umstances where
>=C2=A0 =C2=A0 hash algorithms are used, such as indirect signatures whe= re the hash
>=C2=A0 =C2=A0 of one or more contents are signed, and X.509 certificate= or other
>=C2=A0 =C2=A0 object identification by the use of a fingerprint.=C2=A0 = This document
>=C2=A0 =C2=A0 defines a set of hash algorithms that are identified by C= OSE
>=C2=A0 =C2=A0 Algorithm Identifiers.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/dra= ft-ietf-cose-hash-algs/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-= cose-hash-algs-08
> https://datatracker.ietf.org/= doc/html/draft-ietf-cose-hash-algs-08
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-cose-hash-algs-08
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/
>
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose
--000000000000069b6d05abbd6bb2-- From nobody Fri Jul 31 09:46: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 932B73A07F2 for ; Fri, 31 Jul 2020 09:46:43 -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 QPqv22rGAC3Y for ; Fri, 31 Jul 2020 09:46:40 -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 0831F3A07CA for ; Fri, 31 Jul 2020 09:46:39 -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, 31 Jul 2020 09:46:34 -0700 From: Jim Schaad To: "'Murray S. Kucherawy'" , 'Benjamin Kaduk' CC: References: <159604986490.26275.5128064194472784805@ietfa.amsl.com> <02e201d665dc$46d987c0$d48c9740$@augustcellars.com> <20200729192702.GE92412@kduck.mit.edu> In-Reply-To: Date: Fri, 31 Jul 2020 09:46:32 -0700 Message-ID: <045d01d6675a$26ee0920$74ca1b60$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_045E_01D6671F.7A91C930" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQL3F9ayyrbPpvS29ex2cZTN4KDfaAJacG7TAHwZNTwCe73yiqa18kiA X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] FW: I-D Action: draft-ietf-cose-hash-algs-08.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, 31 Jul 2020 16:46:44 -0000 ------=_NextPart_000_045E_01D6671F.7A91C930 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think it is ready with -08 =20 From: Murray S. Kucherawy =20 Sent: Friday, July 31, 2020 7:15 AM To: Benjamin Kaduk Cc: Jim Schaad ; cose@ietf.org Subject: Re: [COSE] FW: I-D Action: draft-ietf-cose-hash-algs-08.txt =20 So are we back to "Revised I-D Needed" here, or is it ready? =20 On Wed, Jul 29, 2020 at 12:27 PM Benjamin Kaduk > wrote: Hi Jim, Perhaps I should be feeling slightly stupid, but was the -07 intended to = do anything other than update the version of some references (which is what = it looks like from here)? Thanks, Ben On Wed, Jul 29, 2020 at 12:12:58PM -0700, Jim Schaad wrote: > Murray, >=20 > I am feeling slightly stupid at the moment. I was sure that I had = uploaded > this version of the document to the Datatracker and after the meeting = today > I looked and found out that I hadn't. I think this version addresses = all of > the IESG comments along with anything else that was floating around. >=20 > And of course as soon as I had posted the last version I remembered = that I > had not made an edit that was highlighted by Russ. >=20 > Jim >=20 >=20 >=20 > -----Original Message----- > From: COSE > On = Behalf Of internet-drafts@ietf.org =20 > Sent: Wednesday, July 29, 2020 12:11 PM > To: i-d-announce@ietf.org =20 > Cc: cose@ietf.org =20 > Subject: [COSE] I-D Action: draft-ietf-cose-hash-algs-08.txt >=20 >=20 > 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. >=20 > Title : CBOR Object Signing and Encryption (COSE): = Hash > Algorithms > Author : Jim Schaad > Filename : draft-ietf-cose-hash-algs-08.txt > Pages : 12 > Date : 2020-07-29 >=20 > Abstract: > The CBOR Object Signing and Encryption (COSE) syntax > [I-D.ietf-cose-rfc8152bis-struct] does not define any direct = methods > for using hash algorithms. 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. This document > defines a set of hash algorithms that are identified by COSE > Algorithm Identifiers. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-cose-hash-algs-08 > https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-hash-algs-08 >=20 >=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 = . >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org =20 > https://www.ietf.org/mailman/listinfo/cose >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org =20 > https://www.ietf.org/mailman/listinfo/cose ------=_NextPart_000_045E_01D6671F.7A91C930 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I think it = is ready with -08

 

From: Murray S. Kucherawy = <superuser@gmail.com>
Sent: Friday, July 31, 2020 7:15 = AM
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Jim = Schaad <ietf@augustcellars.com>; cose@ietf.org
Subject: = Re: [COSE] FW: I-D Action: = draft-ietf-cose-hash-algs-08.txt

 

So are = we back to "Revised I-D Needed" here, or is it = ready?

 

On = Wed, Jul 29, 2020 at 12:27 PM Benjamin Kaduk <kaduk@mit.edu> = wrote:

Hi = Jim,

Perhaps I should be feeling slightly stupid, but was the -07 = intended to do
anything other than update the version of some = references (which is what it
looks like from = here)?

Thanks,

Ben

On Wed, Jul 29, 2020 at = 12:12:58PM -0700, Jim Schaad wrote:
> Murray,
>
> I = am feeling slightly stupid at the moment.  I was sure that I had = uploaded
> this version of the document to the Datatracker and = after the meeting today
> I looked and found out that I = hadn't.  I think this version addresses all of
> the IESG = comments along with anything else that was floating around.
> =
> And of course as soon as I had posted the last version I = remembered that I
> had not made an edit that was highlighted by = Russ.
>
> Jim
>
>
>
> = -----Original Message-----
> From: COSE <cose-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org
> Sent: Wednesday, = July 29, 2020 12:11 PM
> To: i-d-announce@ietf.org
> Cc: cose@ietf.org
> Subject: [COSE] I-D Action: = draft-ietf-cose-hash-algs-08.txt
>
>
> 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): Hash
> = Algorithms
>         Author    =       : Jim Schaad
>      =  Filename        : = draft-ietf-cose-hash-algs-08.txt
>      =  Pages           : 12
>  =      Date            : = 2020-07-29
>
> Abstract:
>    The CBOR = Object Signing and Encryption (COSE) syntax
>    = [I-D.ietf-cose-rfc8152bis-struct] does not define any direct = methods
>    for using hash algorithms.  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.  This document
>    defines a set of = hash algorithms that are identified by COSE
>    = Algorithm Identifiers.
>
>
> The IETF datatracker = status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-cose-hash-a= lgs/
>
> There are also htmlized versions available = at:
> https://tools.ietf.org/html/draft-ietf-cose-hash-algs-0= 8
> https://datatracker.ietf.org/doc/html/draft-ietf-cose-h= ash-algs-08
>
> A diff from the previous version is = available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-has= h-algs-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/
> =
>
> = _______________________________________________
> COSE mailing = list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
> =
> _______________________________________________
> COSE = mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

------=_NextPart_000_045E_01D6671F.7A91C930-- From nobody Fri Jul 31 10:14: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 0EEC63A0B97 for ; Fri, 31 Jul 2020 10:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 hZl--ldiEjV9 for ; Fri, 31 Jul 2020 10:14:00 -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 2690A3A0B95 for ; Fri, 31 Jul 2020 10:13:59 -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 06VHDpFo022628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Jul 2020 13:13:53 -0400 Date: Fri, 31 Jul 2020 10:13:51 -0700 From: Benjamin Kaduk To: Jim Schaad Cc: "'Murray S. Kucherawy'" , cose@ietf.org Message-ID: <20200731171351.GQ92412@kduck.mit.edu> References: <159604986490.26275.5128064194472784805@ietfa.amsl.com> <02e201d665dc$46d987c0$d48c9740$@augustcellars.com> <20200729192702.GE92412@kduck.mit.edu> <045d01d6675a$26ee0920$74ca1b60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <045d01d6675a$26ee0920$74ca1b60$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] FW: I-D Action: draft-ietf-cose-hash-algs-08.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, 31 Jul 2020 17:14:02 -0000 I spot checked my comments on the -06 and don't see changes to address them. I would guess that you fixed a different working copy than what got uploaded. (In particular, the false statement about "when computing a shorter SHAKE hash value, the value is not a prefix of the result of computing the longer hash.) -Ben On Fri, Jul 31, 2020 at 09:46:32AM -0700, Jim Schaad wrote: > I think it is ready with -08 > > > > From: Murray S. Kucherawy > Sent: Friday, July 31, 2020 7:15 AM > To: Benjamin Kaduk > Cc: Jim Schaad ; cose@ietf.org > Subject: Re: [COSE] FW: I-D Action: draft-ietf-cose-hash-algs-08.txt > > > > So are we back to "Revised I-D Needed" here, or is it ready? > > > > On Wed, Jul 29, 2020 at 12:27 PM Benjamin Kaduk > wrote: > > Hi Jim, > > Perhaps I should be feeling slightly stupid, but was the -07 intended to do > anything other than update the version of some references (which is what it > looks like from here)? > > Thanks, > > Ben > > On Wed, Jul 29, 2020 at 12:12:58PM -0700, Jim Schaad wrote: > > Murray, > > > > I am feeling slightly stupid at the moment. I was sure that I had uploaded > > this version of the document to the Datatracker and after the meeting today > > I looked and found out that I hadn't. I think this version addresses all of > > the IESG comments along with anything else that was floating around. > > > > And of course as soon as I had posted the last version I remembered that I > > had not made an edit that was highlighted by Russ. > > > > Jim > > > > > > > > -----Original Message----- > > From: COSE > On Behalf Of internet-drafts@ietf.org > > Sent: Wednesday, July 29, 2020 12:11 PM > > To: i-d-announce@ietf.org > > Cc: cose@ietf.org > > Subject: [COSE] I-D Action: draft-ietf-cose-hash-algs-08.txt > > > > > > 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): Hash > > Algorithms > > Author : Jim Schaad > > Filename : draft-ietf-cose-hash-algs-08.txt > > Pages : 12 > > Date : 2020-07-29 > > > > Abstract: > > The CBOR Object Signing and Encryption (COSE) syntax > > [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods > > for using hash algorithms. 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. This document > > defines a set of hash algorithms that are identified by COSE > > Algorithm Identifiers. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-cose-hash-algs-08 > > https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-algs-08 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-hash-algs-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/ > > > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose