From nobody Mon Oct 5 06:07:32 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA203A0A25; Mon, 5 Oct 2020 06:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95IBGpWjohIW; Mon, 5 Oct 2020 06:07:24 -0700 (PDT) Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) (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 A05863A0A24; Mon, 5 Oct 2020 06:07:24 -0700 (PDT) Received: by mail-vs1-f45.google.com with SMTP id u74so1618737vsc.2; Mon, 05 Oct 2020 06:07:24 -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:from:date:message-id:subject:to; bh=Q6cBkEXtcocSRs9VF7HVXtyn/s675WogKoZ/njDOaLM=; b=npoLoaDOLN7UqnyiYH4oHZyG/bwaQM497yZoGtbqMyC4TblBduHuCFu2Ai3Lmpw9FR qHKKs16tcZ/aBTBxz4XTVSbW49Yn60jFgdsLqx7wP0mHpT8i8O2DgkJQjhrATUJ3PBAG o8IdJLNMI72YcFVKZmMTVDCb9OxQ1lKxfpLvDc+e/dw/dAF/tDrhTunnqJKxi2tj/Mgj Az3XXC4Vf/6M0TDTsFjHlIU1iV9USNJMQWe5/xtmgyiKg3ae8QALo768XZI3CjADSLwq hlCLn0wjjxz6AvLJwO6pcReChEm2mR6uJSmRYTpjcuR5heQrxRgC4Cj5Ak0FQtR9S3l5 xKdg== X-Gm-Message-State: AOAM531FQ4yZ04QHvoV4KP1KhMyBGVo5eO1nPeWVZvkECEngOFY2HC9p ZwsGisUuRC5lk+Vw/4bulIE9ELHmX/0+wiERZGYXwZ6ikOpKpw== X-Google-Smtp-Source: ABdhPJxz7krhdj+k/3RsXb+DuSl3QP2KoWDQFHRGrWJaCxwrYuv1ckhrAXg7+/f671VwIhcZDUSmyVNZoeyPERb+VT8= X-Received: by 2002:a67:f9d6:: with SMTP id c22mr5883242vsq.49.1601903243138; Mon, 05 Oct 2020 06:07:23 -0700 (PDT) MIME-Version: 1.0 From: Barry Leiba Date: Mon, 5 Oct 2020 09:07:11 -0400 Message-ID: To: cbor@ietf.org, cose@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [COSE] Jim Schaad 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, 05 Oct 2020 13:07:27 -0000 CBOR and COSE working groups, It's with enormous sadness that I have to report the death, a few days ago, of our dear friend and colleague Jim Schaad. Jim was a much loved and highly respected IETF participant for many years, and I feel a huge personal and professional loss, as, I'm sure, will all of us. We can use this message thread to post memoriams for Jim, if people have things you would like to say. Barry ART AD From nobody Tue Oct 6 08:14: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 AF1E63A0AEB for ; Tue, 6 Oct 2020 08:14: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 owTptRUdzhPD for ; Tue, 6 Oct 2020 08:14:46 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 AFFE83A0AE1 for ; Tue, 6 Oct 2020 08:14:46 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id u6so13383865iow.9 for ; Tue, 06 Oct 2020 08:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=baaQRp7lvc8KXdVR987NPA3y3LxHeABzkAk7K/X8Pxk=; b=bfsCg9L4OA3DN73kRUOxKGX8fzB8vNXkszxs5tocSbtXD+pA+hDr79qsj/UN4OAyNP z5zoa+HD5jNs0e0P+45NAZ1+11ersJeBQNGt9XvqJk7fBMQ7nQS0uB2cAUbXJBOw8GdR 9/xuChQidQ3tCy7dhDnyMAW8GNkfTEsX7rtbow14JIngJ3EKDCwivBx3e3UbnlYPPsyl L1lLsYg/JJRJCwKISjrQXrQRUa7gw5Mi40enhpfIwXvHIWv2K6FS5TorM2SpGtVT+EtV /PuZZXPo1AN3mkx4Uh1+U64+b19tz5CH/uzg2XHKvUjEan3mm3lMRGEmBBYQ76ZZnM7A KmYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=baaQRp7lvc8KXdVR987NPA3y3LxHeABzkAk7K/X8Pxk=; b=lM5d6rklO8VvFA0kw2FakUJcFSEO4SrfUyFlxIV3ovJYn9UkbhsGWjNBEOdyghfQy0 yrEuvzQsbdNEM5CvjqfRjlcwimvUCkFJz/GoW3uSM7AHrvuqJLmnQfrsrx6ePYpAVmXm ZXvQoJbKhZb3bCT1ppnxLagHzR8vQbSzMSKs2ZewMnTZspPEITNXDY0s9p2IgD+w1zqK GQiTYUGAvl5SzQ01s8xG3bLTfl1yTykG62IGniKqmUSf6oVN6IE1sztJnLcu5rf5gAPB z2OqTwMrGJzBe2BKi7roMsjw9wqj1v5R8MmqYwFwKpvdQ76Lgkri8FHecAsPVTmnS5HX 3QLQ== X-Gm-Message-State: AOAM531vJ86a/xle2cu8vfVdxT2xI87XovT7wz1jf7rfYRtKVFPKBlpB 9r1JIdcVaVe2OtOhgQLcf1vnXsB3K68aMIbhFbw= X-Google-Smtp-Source: ABdhPJyOmql3QaSlUnX0s39A8Y7jkoh1r52e/hrbtk2w/rnaXFcKuwjYYYxA4+tp1+mZjI3XKJTP3w== X-Received: by 2002:a05:6602:2b03:: with SMTP id p3mr1543250iov.28.1601997285159; Tue, 06 Oct 2020 08:14:45 -0700 (PDT) Received: from [192.168.1.15] (c-24-8-164-51.hsd1.co.comcast.net. [24.8.164.51]) by smtp.gmail.com with ESMTPSA id r19sm1585289ioc.15.2020.10.06.08.14.44 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2020 08:14:44 -0700 (PDT) From: Matthew Miller Content-Type: multipart/alternative; boundary="Apple-Mail=_B6E1FF6C-4944-4E3A-9C5D-65C518D4A23E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Tue, 6 Oct 2020 09:14:43 -0600 To: cose X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [COSE] Jim Schaad 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, 06 Oct 2020 15:14:49 -0000 --Apple-Mail=_B6E1FF6C-4944-4E3A-9C5D-65C518D4A23E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jim Schaad passed away recently. His loss is felt heavily, and will be = felt for a very long time. This working group and its products would = likely not exist -- in either iterations -- without Jim's efforts. The COSE WG still has a interim scheduled for tomorrow (10-07), and we = are reserving as much time as the working group wishes to remember Jim. Jim was responsible for all of the working group's remaining documents, = and while no one can replace his work, the chairs and ADs have worked = out some form of succession on those documents: * draft-ietf-cose-countersign will be edited by Russ Housley. An = updated draft noting this and including a memorial will be uploaded = sometime soon. * draft-ietf-cose-rfc8152bis-struct will be continued by Matthew Miller = (uncredited); this document is awaiting another IETF LC. * draft-ietf-cose-x509 will be continued by Ivaylo Petrov (uncredited); = this document is on the IESG telechat for 10-22, and needs some = editorial changes. * draft-ietf-cose-rfc8152bis-algs is in the RFC Editors' queue. The WG = will be asked to help address any issues that arise from the editing = process, as needed. * draft-ietf-cose-hash-algs is n the RFC Editors' queue. The WG will be = asked to help address any issues that arise from the editing process, as = needed. Thank you again, Russ, for volunteering to edit. Sincerely, - Ivaylo and Matthew COSE WG Chairs - m&m Matthew A. Miller= --Apple-Mail=_B6E1FF6C-4944-4E3A-9C5D-65C518D4A23E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Jim Schaad passed away = recently.  His loss is felt heavily, and will be felt for a very = long time.  This working group and its products would likely not = exist -- in either iterations -- without Jim's efforts.

The COSE WG still has a = interim scheduled for tomorrow (10-07), and we are reserving as much = time as the working group wishes to remember Jim.
Jim was responsible for all of the = working group's remaining documents, and while no one can replace his = work, the chairs and ADs have worked out some form of succession on = those documents:

* draft-ietf-cose-countersign will be edited by Russ Housley. =  An updated draft noting this and including a memorial will be = uploaded sometime soon.
* = draft-ietf-cose-rfc8152bis-struct will be continued by Matthew Miller = (uncredited); this document is awaiting another IETF LC.
* draft-ietf-cose-x509 will be continued by Ivaylo Petrov = (uncredited); this document is on the IESG telechat for 10-22, and needs = some editorial changes.
* = draft-ietf-cose-rfc8152bis-algs is in the RFC Editors' queue.  The = WG will be asked to help address any issues that arise from the editing = process, as needed.
* draft-ietf-cose-hash-algs is = n the RFC Editors' queue.  The WG will be asked to help address any = issues that arise from the editing process, as needed.

Thank you again, Russ, for volunteering = to edit.


Sincerely,

- Ivaylo and Matthew
COSE WG Chairs

- m&m
Matthew= A. Miller
= --Apple-Mail=_B6E1FF6C-4944-4E3A-9C5D-65C518D4A23E-- From nobody Tue Oct 6 22:33: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 BA5793A1620; Tue, 6 Oct 2020 22:33:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Matthew Miller , linuxwolf+ietf@outer-planes.net X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160204883573.26847.11501294022082441021@ietfa.amsl.com> Date: Tue, 06 Oct 2020 22:33:55 -0700 Archived-At: Subject: [COSE] Benjamin Kaduk's Yes on draft-ietf-cose-rfc8152bis-struct-14: (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, 07 Oct 2020 05:33:56 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-cose-rfc8152bis-struct-14: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-struct/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Mostly just nits left, though the lingering errata report and the IANA updates seem somewhat significant. (It would probably be fine to leave the nits for the RFC Editor.) It seems that https://www.rfc-editor.org/errata/eid5066 needs to be incorporated still (and the report verified, presuming it is correct). Section 1 providing security services. The use of COSE, like JOSE and CMS, is only for use in store and forward or offline protocols. The use of nit: we probably can just start the sentence with "COSE", since the "use in" has moved to later in the sentence. additional data fields as part of the structure. A one such application-specific element would be to include a URI or other nit: s/A one/One/. Section 1.5 The presence a label that is neither a a text string or an integer, nit: s/a a/a/ Section 2 layer. The content layer contains the plaintext is encrypted and information about the encrypted message. The recipient layer contins nit: s/plaintext is encrypted/encrypted plaintext/ (or similar?) the content encryption key (CEK) is encrypted and information about how it is encrypted for each recipient. A single layer version of nit: s/content encryption key (CEK) is encrypted/encrypted content encryption key (CEK)/. Section 4.1 parameter. An examples of a header parameter about the signature nit: s/An examples/An example/ Note: When a signature with a message recovery algorithm is used (Section 8.1), the maximum number of bytes that can be recovered is the length of the original payload. The size of the encoded payload is reduced by the number of bytes that will be recovered. If all of the bytes of the original payload are consumed, then the transmitted payload is encoded as a zero-length byte string rather than as being absent. I guess this is where the difficulty that Jim mentioned comes in -- the signature recovery scheme gives you the intended recovered content but also some of the other framing and such that was added as input to the signature algorithm, and you have to properly figure out where the end of the actual payload is. (I'm not sure whether it would be useful to try to have text about the issue in this location, though.) Section 8.1 consume the same bytes of message content. This means that the mixing of the signature with message recovery and signature with appendix schemes in a single message is not supported, and if a recovery signature scheme is used. nit: this sentence just trails off .... I think it would be okay to just end the sentence after "is not supported", since we covered the "must recover the same [number of] bytes" previously. integrating message recovery signature algorithms. The first algorithm defined is going to need to make decisions about these issues and those decisions re likely to be binding on any further algorithms defined. nit: s/ re / are / Some of the issue2 that have already been identified are: nit: s/issue2/issues/ Section 8.5.2, 8.5.3, 8.5.4, 8.5.5 I see that a bunch of things were changed from COSE_Encrypt to COSE_Recipient, apparently prompted by my earlier review. I would feel more comfortable if someone confirmed that each change is correct, as I have lost some of the context here. Section 10 comparable for the desired security functionality. Additional guidence can be found in [BCP201]. nit: s/guidence/guidance/ Section 11 We lost the section about the "CBOR Tags" registry (where we were previously allocating a codepoint for COSE_Signature). I think we need to bring back a stub section with the directive to update the references from 8152 to this document. [Noting here for convenience that as of the -12 of -algs, the Header Algorithm Parameters registry has not been added as a target for reference updates; it still needs to be listed there.] Acknowledgments nit: Göran's name doesn't seem to have made it through some step of the process (eve in the native HTML output). From nobody Wed Oct 7 06:14: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 73E253A099E; Wed, 7 Oct 2020 06:14: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, 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 vSerUjIh0kzq; Wed, 7 Oct 2020 06:14:18 -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 734FD3A098E; Wed, 7 Oct 2020 06:14:18 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4C5vtc4B1rz1070; Wed, 7 Oct 2020 15:14:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <160204883573.26847.11501294022082441021@ietfa.amsl.com> Date: Wed, 7 Oct 2020 15:14:16 +0200 Cc: The IESG , draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, linuxwolf+ietf@outer-planes.net, cose@ietf.org X-Mao-Original-Outgoing-Id: 623769256.01201-c8910876d41e15f07d67599f2fad4c9e Content-Transfer-Encoding: quoted-printable Message-Id: References: <160204883573.26847.11501294022082441021@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Yes on draft-ietf-cose-rfc8152bis-struct-14: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 13:14:21 -0000 On 2020-10-07, at 07:33, Benjamin Kaduk via Datatracker = wrote: >=20 > It seems that https://www.rfc-editor.org/errata/eid5066 needs to be > incorporated still (and the report verified, presuming it is correct). COSE_KDF_Context is defined in -algs, not -struct. -algs has Section 9, which implements the addition intended by the = errata. (-struct has its own Section 9, covering the other structures). So it seems the errata report is applied in -algs. It could also be verified for RFC 8152. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Oct 7 08:52:37 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 4C3DA3A0EEC for ; Wed, 7 Oct 2020 08:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 kI_SfCVsBrb8 for ; Wed, 7 Oct 2020 08:52:24 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 0C1ED3A0DD8 for ; Wed, 7 Oct 2020 08:52:12 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id b2so2751133ilr.1 for ; Wed, 07 Oct 2020 08:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=4oBKTLehdXQSQ8PrYUTq12B2Cg70/DKn2JIshvjlDtc=; b=f9SR34Thr3nUsYldICwDdX3F4xWuHF0kpUOD3Zun5V50tWn5xuGeCX525SP6GTQk0A nDTAJIGmg0NCzy2oRRJuwWEnNU60D+kIkq7HtvkisbJuceJwvlvFtSMJ4z3oRV4NiraA Rb52Y7u9oXuZOMCh+tQGlpdOi8dqtejaDEPFhtmNMKsBw5dtAJ1/VJpBER5oyOPGFNvg QTMIGVQXLoIZHMsE1MK1nYs5c1Is6fYq/XL8vqVEZ0GPVdMgBaIl7GYfJDm1iSViVhCr tZWZEKFPqgHZPgbNsRiFsz8Wjo5KSmYSWKhbHikX99JhmGyY5kYYP/J1hSxk4rUnLnVf 1x/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=4oBKTLehdXQSQ8PrYUTq12B2Cg70/DKn2JIshvjlDtc=; b=iKxZ+67R9I7MsmbX+SzAh3cL6mhYM7B26gPCcoeDAyglVMb459FOtfF8xOPSAn4uvi JwOwIFPUyC8L3f6kpoXUfUCa7ae3CpAUPdPL9f9tBGC1N5sgP1O9uCTtZCnxzJnC6BMi ga07ps9HuacGUUmj30ZN9hNwA9xinVkzWBz1tGMmJsBaZlgcmmoErJjSjYuB/VEFpa2e ZRF7iymwaxK9roI6tHrMtsI56rwKKknPI53L4KW0uFXHbiB/wCLMwNQWr1y4Kf9KgeCc rlo8/VriMqj4OC3ZXZ+dYT5Orch+BctVevzNNYOEhh3AHCplQ9uBdxf9Ug/N0f2PvuuX QpdQ== X-Gm-Message-State: AOAM533/GkeyJ0gHB9J13nuTrL4BCnxtxZuEgkzhL2ccI90ZVk52AFIT FeV7WiDxbFe89iOLGxilCCXyqePXNhwGlQ== X-Google-Smtp-Source: ABdhPJzpWS6o/BhIEDWy7Od+mzh7oDbKPckrzW78FuSeaNexIOfRJvcarHUFRoU0u6tXkEhvERaOBg== X-Received: by 2002:a92:770e:: with SMTP id s14mr3420326ilc.130.1602085931636; Wed, 07 Oct 2020 08:52:11 -0700 (PDT) Received: from [192.168.1.15] (c-24-8-164-51.hsd1.co.comcast.net. [24.8.164.51]) by smtp.gmail.com with ESMTPSA id c2sm1041586ioc.29.2020.10.07.08.52.10 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Oct 2020 08:52:10 -0700 (PDT) From: Matthew Miller Content-Type: multipart/alternative; boundary="Apple-Mail=_C75FA7FB-DAA1-41EC-B3AE-BD2DE5AA801E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Wed, 7 Oct 2020 09:52:09 -0600 To: cose X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [COSE] Virtual Interim 2020-10-07 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, 07 Oct 2020 15:52:36 -0000 --Apple-Mail=_C75FA7FB-DAA1-41EC-B3AE-BD2DE5AA801E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A late reminder of our virtual interim, starting in approximately 10 = minutes. Webex: = https://ietf.webex.com/ietf-en/j.php?MTID=3Dm3cb392c16a42d21894298ba0dea94= 2d2 Minutes: = https://codimd.ietf.org/notes-ietf-interim-2020-cose-05-cose?edit - m&m Matthew A. Miller --Apple-Mail=_C75FA7FB-DAA1-41EC-B3AE-BD2DE5AA801E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii A late reminder of our virtual interim, starting in approximately 10 minutes.


- m&m
Matthew A. Miller

--Apple-Mail=_C75FA7FB-DAA1-41EC-B3AE-BD2DE5AA801E-- From nobody Wed Oct 7 08:53: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 047243A0E4B for ; Wed, 7 Oct 2020 08:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 CxmeJI3g8e2S for ; Wed, 7 Oct 2020 08:52:51 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CFA3A0A9C for ; Wed, 7 Oct 2020 08:52:29 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id u6so2838780iow.9 for ; Wed, 07 Oct 2020 08:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pq1t4tCwdFXShOBpEGkT6e/a75Wwrg68dBVn/xxgLMs=; b=OptbWwotcZmzgT6oNYiPqmWOpDnKy0Sv37pV+BuJ130QK+g7d90wLDKjsuvZ0q9Vyt WQAzF8Ewaf1KOlbuprFt168p74b/09pspCOtwyLz64o65UanufIcgmZCxjSM2ojnl8Jo zzfP5J6qWFyJOonk4iy9NA/qYAzUAsg5lW/SfnTkxRxfkiVgyB0H+kRavvCDOv4jQyfw lX4dPoqcMRxsMxbIaysFNAQsPe7cQGeGUrJmFyfRa3w7zz5IuOpFIqz7vC4F0nTIlcX/ beY0jRuGpxShqU+dDj0+ej9ihJ7bWDHstWygdr1VRckVDxouiQaoACfQmAi5eB303hsw B64Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pq1t4tCwdFXShOBpEGkT6e/a75Wwrg68dBVn/xxgLMs=; b=o55onweuJ4+ZSMn5jutbW7YjhAHvcvZ2iF5b5vl90RyM3JgHQkhamfm2DkdBItaD6b eTbKoAvHWTKCoKqVxzqHO4eS1cl+5QV0QUle7wnkpDC4SIXBGGubN41PJQh1xA4qYZfK 4UFHwPTY3Lxso2/xkt3e1Fz5wk25B/O4sbZ38muGydNoZ2NoaWp9ZFOcyJpUgfm8QDnP oVLjhbwTNtjMuH5NDEelSFM51bDXNcDKu1Q1WUdthcEDdZMzkpOUXSieqiLiRFk1wJG9 9bvo5l/BL21MmHKzksY6+LhWkONekr4n3Rizya3uwDlr8SXjGCvilGfhlIG6g5kX1gbK CAyA== X-Gm-Message-State: AOAM531S2MGIeYi/HQx/1LvgaW125liuiRKjNaAV2l5fZSGWFJzZ5ntF rmeMICETujPUJbVGC9p8kKZaWQ== X-Google-Smtp-Source: ABdhPJwGCApLDJK29LhokBIwkssMElmRZjJkAqooSYS/N23ik04F92vnD1Q0jI1M4tKJIEWWp9mhfQ== X-Received: by 2002:a5d:9717:: with SMTP id h23mr2776497iol.7.1602085948406; Wed, 07 Oct 2020 08:52:28 -0700 (PDT) Received: from [192.168.1.15] (c-24-8-164-51.hsd1.co.comcast.net. [24.8.164.51]) by smtp.gmail.com with ESMTPSA id c2sm1041586ioc.29.2020.10.07.08.52.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Oct 2020 08:52:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Matthew Miller In-Reply-To: Date: Wed, 7 Oct 2020 09:52:26 -0600 Cc: Benjamin Kaduk , The IESG , draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, cose Content-Transfer-Encoding: quoted-printable Message-Id: <4920FB90-3F45-4050-8205-2B09D4B84265@outer-planes.net> References: <160204883573.26847.11501294022082441021@ietfa.amsl.com> To: Carsten Bormann X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Yes on draft-ietf-cose-rfc8152bis-struct-14: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 15:52:54 -0000 > On Oct 7, 2020, at 7:14 AM, Carsten Bormann wrote: >=20 > On 2020-10-07, at 07:33, Benjamin Kaduk via Datatracker = wrote: >>=20 >> It seems that https://www.rfc-editor.org/errata/eid5066 needs to be >> incorporated still (and the report verified, presuming it is = correct). >=20 > COSE_KDF_Context is defined in -algs, not -struct. >=20 > -algs has Section 9, which implements the addition intended by the = errata. > (-struct has its own Section 9, covering the other structures). >=20 > So it seems the errata report is applied in -algs. > It could also be verified for RFC 8152. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 Carsten's interpretation of this errata looks correct to me: = -rfc1852bis-algs defines the COSE_KDF_Context struct and =C2=A7 9 = discusses the encoding restrictions for that structure. This erratum should be marked verified. - m&m Matthew A. Miller From nobody Wed Oct 7 09:10: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 A26B93A0AE1; Wed, 7 Oct 2020 09:10: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 qSGAY9hGa7Sc; Wed, 7 Oct 2020 09:10:21 -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 068413A0AD0; Wed, 7 Oct 2020 09:10:20 -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 097GAETE016099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 7 Oct 2020 12:10:17 -0400 Date: Wed, 7 Oct 2020 09:10:14 -0700 From: Benjamin Kaduk To: Matthew Miller Cc: Carsten Bormann , The IESG , draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, cose Message-ID: <20201007161014.GP89563@kduck.mit.edu> References: <160204883573.26847.11501294022082441021@ietfa.amsl.com> <4920FB90-3F45-4050-8205-2B09D4B84265@outer-planes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4920FB90-3F45-4050-8205-2B09D4B84265@outer-planes.net> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Yes on draft-ietf-cose-rfc8152bis-struct-14: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 16:10:23 -0000 On Wed, Oct 07, 2020 at 09:52:26AM -0600, Matthew Miller wrote: > > > On Oct 7, 2020, at 7:14 AM, Carsten Bormann wrote: > > > > On 2020-10-07, at 07:33, Benjamin Kaduk via Datatracker wrote: > >> > >> It seems that https://www.rfc-editor.org/errata/eid5066 needs to be > >> incorporated still (and the report verified, presuming it is correct). > > > > COSE_KDF_Context is defined in -algs, not -struct. > > > > -algs has Section 9, which implements the addition intended by the errata. > > (-struct has its own Section 9, covering the other structures). > > > > So it seems the errata report is applied in -algs. > > It could also be verified for RFC 8152. > > > > Gre, Carsten > > > > > Carsten's interpretation of this errata looks correct to me: -rfc1852bis-algs defines the COSE_KDF_Context struct and 9 discusses the encoding restrictions for that structure. > > This erratum should be marked verified. Thanks for confirming, and thanks Carsten for pointing out that it went to -algs. I will go ahead and mark it as verified. I did take a look at the respective parts of -algs and -struct, which shows a bit of skew: -Encoding MUST be done using definite lengths and values MUST be the minimum possible length. This means that the integer 1 is encoded as "0x01" and not "0x1801". +Encoding MUST be done using definite lengths and the length of the MUST be the minimum possible length. This means that the integer 1 is encoded as "0x01" and not "0x1801". ("values" vs "the length of the") I think that -algs should be adjusted to match -struct. -Ben From nobody Wed Oct 7 09:12:11 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 D8F063A0AE1; Wed, 7 Oct 2020 09:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 9YTKS5Y5XCGD; Wed, 7 Oct 2020 09:12:04 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D43E3A0AD0; Wed, 7 Oct 2020 09:12:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EFA5AF406D0; Wed, 7 Oct 2020 09:11:52 -0700 (PDT) To: ietf@augustcellars.com, ietf@augustcellars.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: kaduk@mit.edu, iesg@ietf.org, cose@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20201007161152.EFA5AF406D0@rfc-editor.org> Date: Wed, 7 Oct 2020 09:11:52 -0700 (PDT) Archived-At: Subject: [COSE] [Errata Verified] RFC8152 (5066) 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, 07 Oct 2020 16:12:06 -0000 The following errata report has been verified for RFC8152, "CBOR Object Signing and Encryption (COSE)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5066 -------------------------------------- Status: Verified Type: Technical Reported by: Jim Schaad Date Reported: 2017-07-11 Verified by: Benjamin Kaduk (IESG) Section: 14 Original Text ------------- o The restriction applies to the encoding of the Sig_structure, the Enc_structure, and the MAC_structure. Corrected Text -------------- o The restriction applies to the encoding of the COSE_KDF_Context, Sig_structure, the Enc_structure, and the MAC_structure. Notes ----- When listing the set of structure that need to be canonically encoded, I missed this one. Verifier Notes: this is being fixed in draft-ietf-cose-rfc8152bis-algs. -------------------------------------- RFC8152 (draft-ietf-cose-msg-24) -------------------------------------- Title : CBOR Object Signing and Encryption (COSE) Publication Date : July 2017 Author(s) : J. Schaad Category : PROPOSED STANDARD Source : CBOR Object Signing and Encryption Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Oct 7 10:26:53 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 31C733A0D44; Wed, 7 Oct 2020 10:26:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-cose-x509@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov , ivaylo@ackl.io X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <160209160818.12838.15929178240331409569@ietfa.amsl.com> Date: Wed, 07 Oct 2020 10:26:48 -0700 Archived-At: Subject: [COSE] Martin Duke's No Objection on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 17:26:48 -0000 Martin Duke has entered the following ballot position for draft-ietf-cose-x509-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I see that it's in the charter as such, but I have no idea why this is otherwise an Informational RFC, as it extends a Standard RFC and has some normative language in it for interoperability. I am not a fan of the passive voice in Section 2: "Certificates obtained from any of these methods MUST still be validated." Who has to validate it? It sounds like we are not requiring constrained devices to do this validation, so the document really ought to pin the responsibility on the system. From nobody Wed Oct 7 12:44:55 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 C32173A0A22; Wed, 7 Oct 2020 12:44:53 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <160209989374.20785.14889766194687137600@ietfa.amsl.com> Date: Wed, 07 Oct 2020 12:44:53 -0700 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-countersign-01.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, 07 Oct 2020 19:44:54 -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): Countersignatures Authors : Jim Schaad Russ Housley Filename : draft-ietf-cose-countersign-01.txt Pages : 20 Date : 2020-10-07 Abstract: Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-countersign/ There is also an HTML version available at: https://www.ietf.org/id/draft-ietf-cose-countersign-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-countersign-01 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 Oct 7 13:22: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 016603A1345 for ; Wed, 7 Oct 2020 13:22:38 -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 lydExpsb4ItS for ; Wed, 7 Oct 2020 13:22:36 -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 5188C3A1343 for ; Wed, 7 Oct 2020 13:22:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BA49D300B7F for ; Wed, 7 Oct 2020 16:22:33 -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 qP_Lc648-5C7 for ; Wed, 7 Oct 2020 16:22:32 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 7B0A0300B7C for ; Wed, 7 Oct 2020 16:22:32 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Wed, 7 Oct 2020 16:22:33 -0400 References: To: cose In-Reply-To: Message-Id: <947BBD8D-7BF0-477A-8954-1EFCEBC7170E@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [COSE] Jim Schaad 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, 07 Oct 2020 20:22:38 -0000 I just posted draft-ietf-cose-countersign-01. Russ > On Oct 6, 2020, at 11:14 AM, Matthew Miller = wrote: >=20 > Jim Schaad passed away recently. His loss is felt heavily, and will = be felt for a very long time. This working group and its products would = likely not exist -- in either iterations -- without Jim's efforts. >=20 > The COSE WG still has a interim scheduled for tomorrow (10-07), and we = are reserving as much time as the working group wishes to remember Jim. >=20 > Jim was responsible for all of the working group's remaining = documents, and while no one can replace his work, the chairs and ADs = have worked out some form of succession on those documents: >=20 > * draft-ietf-cose-countersign will be edited by Russ Housley. An = updated draft noting this and including a memorial will be uploaded = sometime soon. > * draft-ietf-cose-rfc8152bis-struct will be continued by Matthew = Miller (uncredited); this document is awaiting another IETF LC. > * draft-ietf-cose-x509 will be continued by Ivaylo Petrov = (uncredited); this document is on the IESG telechat for 10-22, and needs = some editorial changes. > * draft-ietf-cose-rfc8152bis-algs is in the RFC Editors' queue. The = WG will be asked to help address any issues that arise from the editing = process, as needed. > * draft-ietf-cose-hash-algs is n the RFC Editors' queue. The WG will = be asked to help address any issues that arise from the editing process, = as needed. >=20 > Thank you again, Russ, for volunteering to edit. >=20 >=20 > Sincerely, >=20 > - Ivaylo and Matthew > COSE WG Chairs From nobody Wed Oct 7 15:14: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 B3CDB3A144E for ; Wed, 7 Oct 2020 15:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZIrBS_5Me0r for ; Wed, 7 Oct 2020 15:14:43 -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 1F53A3A144D for ; Wed, 7 Oct 2020 15:14:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 86A32389DF; Wed, 7 Oct 2020 18:20: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 iJETLrPVnucD; Wed, 7 Oct 2020 18:20:03 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F14B389DE; Wed, 7 Oct 2020 18:20:03 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 35F107B7; Wed, 7 Oct 2020 18:14:39 -0400 (EDT) From: Michael Richardson To: Russ Housley , cose In-Reply-To: <947BBD8D-7BF0-477A-8954-1EFCEBC7170E@vigilsec.com> References: <947BBD8D-7BF0-477A-8954-1EFCEBC7170E@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: [COSE] 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, 07 Oct 2020 22:14:45 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Russ Housley wrote: > I just posted draft-ietf-cose-countersign-01. Thanks for taking on this editing Russ. I had read -00 before the last virtual interim meeting. I see you updated the github repo. A gap that I think we need to talk about as a WG is the question of the exa= mples. Jim didn't just edit the documents, he wrote code to generate the examples. 1) can someone take over those examples? {I use some of them in some them via gitmodule in my RFC8366 library to validate my COSE code, but I don't have competence on the modes I don't = use} 2) do we need/want new examples for the new countersignature modes? I certainly didn't really understand the specification well enough to argue until I wrote code. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9+Pc4ACgkQgItw+93Q 3WXBKgf+PEIpGgwwM0ptAOX0vPRa51UIX8CTPaqBI+MZYE9FmiWc04opbTrCHfp1 3puJOtn1m0lPXNv9IBCoeiRJHsKX517YniZv5X1nm+udaE4gpde6GW4DTKL7yFMH Iff3CEY4s6FIdXzLyo6+xsBO8gySNZMsLekKzuvgOdmdzYc4ZuQwgTA2P08efpHP cEZ7sFusQ8T3MHDr7vtO0o451kD8nVwpTLmG78gVWjWlYlO63GL36AKF+NyxffJ+ 7q35cDfhCETE9DaAWoFli5ryMoif0d3wEfEiVeEi8lsYKPJENHYWIIVScRn8sw9F n13rxzXQ90ndTI61eS9soivdM1I9lw== =9NFa -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 8 07:36:03 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EBE3A0E0F for ; Thu, 8 Oct 2020 07:36:01 -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 h8-13ALN-A6P for ; Thu, 8 Oct 2020 07:36:00 -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 01D7C3A0E06 for ; Thu, 8 Oct 2020 07:36:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 655A2300B9C for ; Thu, 8 Oct 2020 10:35: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 fTRjNHJ1Jdlp for ; Thu, 8 Oct 2020 10:35:56 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 35B0D300AFF; Thu, 8 Oct 2020 10:35:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: <10020.1602108879@localhost> Date: Thu, 8 Oct 2020 10:35:57 -0400 Cc: cose Content-Transfer-Encoding: quoted-printable Message-Id: <5E50CD24-FA0D-431A-BD1A-CFCFD2441732@vigilsec.com> References: <947BBD8D-7BF0-477A-8954-1EFCEBC7170E@vigilsec.com> <10020.1602108879@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [COSE] 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: Thu, 08 Oct 2020 14:36:02 -0000 Michael: > Russ Housley wrote: >> I just posted draft-ietf-cose-countersign-01. >=20 > Thanks for taking on this editing Russ. > I had read -00 before the last virtual interim meeting. I did not make any changes to the body of the document. > I see you updated the github repo. >=20 > A gap that I think we need to talk about as a WG is the question of = the examples. > Jim didn't just edit the documents, he wrote code to generate the = examples. Indeed. I'm pleased to work with someone on examples. I think that = Jim's code is available. If we do not have someone that cares to help produce a particular = example, then we can move forward with an incomplete set. > I certainly didn't really understand the specification well enough to = argue > until I wrote code. This is typical of Jim's approach. I recall a document a few years ago, = he was asked if a document was complete, and he said it had enough = detail for him to write code that validated the test vectors. Russ From nobody Sat Oct 10 15:36: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 C54763A09DE for ; Sat, 10 Oct 2020 15:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgSrjAlVmg0A for ; Sat, 10 Oct 2020 15:36: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 2DE5B3A09D5 for ; Sat, 10 Oct 2020 15:36:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BDFF3389A0; Sat, 10 Oct 2020 18:41:47 -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 hoC59-zJuYNf; Sat, 10 Oct 2020 18:41:47 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2B2FD3899F; Sat, 10 Oct 2020 18:41:47 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6F5D840A; Sat, 10 Oct 2020 18:36:11 -0400 (EDT) From: Michael Richardson To: Russ Housley , cose In-Reply-To: <5E50CD24-FA0D-431A-BD1A-CFCFD2441732@vigilsec.com> References: <947BBD8D-7BF0-477A-8954-1EFCEBC7170E@vigilsec.com> <10020.1602108879@localhost> <5E50CD24-FA0D-431A-BD1A-CFCFD2441732@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] 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: Sat, 10 Oct 2020 22:36:16 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Russ Housley wrote: >> A gap that I think we need to talk about as a WG is the question of = the examples. >> Jim didn't just edit the documents, he wrote code to generate the ex= amples. > Indeed. I'm pleased to work with someone on examples. I think that = Jim's code is available. > If we do not have someone that cares to help produce a particular > example, then we can move forward with an incomplete set. It takes two implementers to be sure, so getting Jim's code runnable somewhere would be a good thing.... who has some fourth-year students? :-) >> I certainly didn't really understand the specification well enough t= o argue >> until I wrote code. > This is typical of Jim's approach. I recall a document a few years > ago, he was asked if a document was complete, and he said it had enou= gh > detail for him to write code that validated the test vectors. :-) We had some users of the old-style countersignature. I think it was in ACE, but I can't recall. If they have library code =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+CN1sACgkQgItw+93Q 3WWzwQgAhiSVGIgwnF/zjo9qUZinJmrPbVBbF/lIF4RryIPJxKrZSlGAQ/xk0HJg j1xNrooZ9t/bzHBvqyBPnBiV6PPmHMI4N27ODLu2Awr/ddseQ5B3nTBdZ7noZbmB oK4eDFAiG+tFJIOH4TPNm7bJjgVq3RLyug9aJh57mtRrD7ODGsEvzyE4BPzT+iBy MF8xL09aSnpkuJFl52X7gydmOFuiSg0BjiteGaX8LE81lN1SyoRewHAqcq/Garm5 2lRQnAw21VML34wjKyx11iPQlwyUbHmsgXsl+NDLGdHpwCX2AfHGdclXtHQnwPxI ZAdv78KQqmWwMSFo+oCWMCv8YwhINg== =NTH+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Oct 11 08:31: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 1F4603A0E8A for ; Sun, 11 Oct 2020 08:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0ma0FWqOczO for ; Sun, 11 Oct 2020 08:31:26 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 249E33A0E89 for ; Sun, 11 Oct 2020 08:31:25 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id t9so16056509wrq.11 for ; Sun, 11 Oct 2020 08:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YCfitgNn5usJHTUHSuFBJHWiX2gtAnefSi9UOVzACJQ=; b=lcD5z/cqc4w3W2t//tkaBd/lCVP3NqdiQYrzYtQMBRHMeSLBpj7SKGNVGvwz19NYBz 9+KPLUpoL3u7bIrbpwy8pgbkOf8mikiToqVsIDYo2Ch1tQyLc+LAvjwgR75qserNMzZB I26EBULw0PLdTvq/p0TpUViCd8JMeEJiWAminXzXW6yLyVjnD+T/umukiUnHMHKOEwfy YkX05ZoooXNJYWPNLmx61u3gsAV+LWO9nZppQO1a1DUImcaOGBFZZKP++aCm+nDIzFrP kiRINwzZqKl93k/sAaCEAgV44jtrdqE5EZJDXUvLgwJP0wrqR0zw01EwS6HdLCQX9+hk GTMg== 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=YCfitgNn5usJHTUHSuFBJHWiX2gtAnefSi9UOVzACJQ=; b=YKXpFwzJFUwVghyxy6LajFyCOSMUJXwQg4rV4XxbT+3AbQW+o8/jupFy3kWhotb9PK qrCuVruOuT++CzDtjXhgxFYb/zfV9VXd42Ct5H1FoaDm+jyILPANErTB1/vz4nG+xBPQ puREpuuiXo5qRg+iI5RsybP3KBmJMUcHlZDY8EY9UWusgCAyyyoLrxvrQZ5pDezfzrL8 AeS/XoBSz9qCtpjllAd8Esb8ndXhvU32TYqO/EKpFQPM0d1qbvgr2Szi4b14K0U57hLE 8XsBFG93W+tYtTLmz2aykajPqcIs4NGwc3pVub34NtHTAp3OTV3myVk2ga60mCa4UbH7 R8IQ== X-Gm-Message-State: AOAM530JRQaO6DKObhy7FO2mXNZratkP0P+KNHI6ZBU9qk69mXU9meag lhYO6BORhyDQxtdKVk5Kin0wTHtIV3vAOOsvnPlg3w== X-Google-Smtp-Source: ABdhPJw4laXb9iNbVzAQg9TpI5JjMB98dNkbsD5+k7LIWNJMm6E0OluqwHZqQbuGPMmNkP1uOxHoJw/4VkDYIic/t+E= X-Received: by 2002:adf:fa41:: with SMTP id y1mr26694411wrr.213.1602430284128; Sun, 11 Oct 2020 08:31:24 -0700 (PDT) MIME-Version: 1.0 References: <160036825659.25366.10563141238331695427@ietfa.amsl.com> <0AA2BF46-BEBD-4BC4-92B6-84B83CB175AC@vigilsec.com> In-Reply-To: <0AA2BF46-BEBD-4BC4-92B6-84B83CB175AC@vigilsec.com> From: Ivaylo Petrov Date: Sun, 11 Oct 2020 18:30:58 +0300 Message-ID: To: Russ Housley Cc: last-call@ietf.org, Cose Chairs Wg , cose , draft-ietf-cose-x509@ietf.org Content-Type: multipart/alternative; boundary="000000000000dcf5cc05b166df8a" Archived-At: Subject: Re: [COSE] Last Call: (CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificates) to Informational RFC 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, 11 Oct 2020 15:31:28 -0000 --000000000000dcf5cc05b166df8a Content-Type: text/plain; charset="UTF-8" Hi Russ, Thank you for your comment! I believe the intention was to delete the following 2 paragraphs and that is what I put in the version that I am working on (already in github). I expect to publish the new draft version here shortly. Thanks, Ivaylo On Thu, Sep 17, 2020 at 10:03 PM Russ Housley wrote: > I read the document, and it is ready, except for the note to the RFC > Editor. It is clear where to start deleting, bit it is not obvious where > to stop. > > Russ > > > > On Sep 17, 2020, at 2:44 PM, The IESG wrote: > > > > The IESG has received a request from the CBOR Object Signing and > Encryption > > WG (cose) to consider the following document: - 'CBOR Object Signing and > > Encryption (COSE): Header parameters for > > carrying and referencing X.509 certificates' > > as Informational RFC > > > > The IESG plans to make a decision in the next few weeks, and solicits > final > > comments on this action. Please send substantive comments to the > > last-call@ietf.org mailing lists by 2020-10-01. Exceptionally, comments > may > > be sent to iesg@ietf.org instead. In either case, please retain the > beginning > > of the Subject line to allow automated sorting. > > > > Abstract > > > > > > The CBOR Signing And Encrypted Message (COSE) structure uses > > references to keys in general. For some algorithms, additional > > properties are defined which carry parts of keys as needed. The COSE > > Key structure is used for transporting keys outside of COSE messages. > > This document extends the way that keys can be identified and > > transported by providing attributes that refer to or contain X.509 > > certificates. > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ > > > > No IPR declarations have been submitted directly on this I-D. > > --000000000000dcf5cc05b166df8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Russ,

T= hank you for your comment! I believe the intention=C2=A0was to delete the f= ollowing 2 paragraphs and that is what I put in the version that I am worki= ng on (already in github). I expect to publish the new draft version here s= hortly.

Thanks,
Ivaylo
<= /div>


On Thu, Sep 17, 2020 at 10:03 PM Russ Housley <housley@vigilsec.com> wrote:
I read the document, a= nd it is ready, except for the note to the RFC Editor.=C2=A0 It is clear wh= ere to start deleting, bit it is not obvious where to stop.

Russ


> On Sep 17, 2020, at 2:44 PM, The IESG <iesg-secretary@ietf.org> wrote:
>
> The IESG has received a request from the CBOR Object Signing and Encry= ption
> WG (cose) to consider the following document: - 'CBOR Object Signi= ng and
> Encryption (COSE): Header parameters for
>=C2=A0 =C2=A0carrying and referencing X.509 certificates'
>=C2=A0 <draft-ietf-cose-x509-07.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits = final
> comments on this action. Please send substantive comments to the
> last-call@ietf= .org mailing lists by 2020-10-01. Exceptionally, comments may
> be sent to iesg@iet= f.org instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>=C2=A0 =C2=A0The CBOR Signing And Encrypted Message (COSE) structure us= es
>=C2=A0 =C2=A0references to keys in general.=C2=A0 For some algorithms, = additional
>=C2=A0 =C2=A0properties are defined which carry parts of keys as needed= .=C2=A0 The COSE
>=C2=A0 =C2=A0Key structure is used for transporting keys outside of COS= E messages.
>=C2=A0 =C2=A0This document extends the way that keys can be identified = and
>=C2=A0 =C2=A0transported by providing attributes that refer to or conta= in X.509
>=C2=A0 =C2=A0certificates.
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ie= tf-cose-x509/
>
> No IPR declarations have been submitted directly on this I-D.

--000000000000dcf5cc05b166df8a-- From nobody Sun Oct 11 09:29:36 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 B01A33A0EC2 for ; Sun, 11 Oct 2020 09:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEM8_p1xQIju for ; Sun, 11 Oct 2020 09:29:33 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 CB9363A0EC1 for ; Sun, 11 Oct 2020 09:29:32 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id d3so14977670wma.4 for ; Sun, 11 Oct 2020 09:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=becUmC5xAMI8yQy4JAFjHPw1bv0InOo9J8Hsf6suAX0=; b=CkXQplwGJlhivoBvr9qbwr68JUrfOMuZVXO4VxrwHGrth9OX/0hn4MKUKcB4IQlnLZ TEF2ytZWxHW29ukAdmsx6ahcJzzOw0Rt0CSwZpsNuK7yrS9l357JYvFqdenkbAWINgLU iG506gKl4UQ+h7PpqNpMW6tkrzzKYpt4s21UMM3F4HOYKfPmiYuSnyyIMGd1tfKznXeE FfuqMOZZwHLoGwCVLQRe9ees3PNPG0XWGTzoosUiP9SrFI6qieRh9iuRoXAxDt2x4POA uk98FzyyoSCyc7MI6EJQo4Q3uNT4L1Eglo70m6K/PMFuPon6/BndqR8vsjzMZclHTFbM tAhw== 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=becUmC5xAMI8yQy4JAFjHPw1bv0InOo9J8Hsf6suAX0=; b=rIQFI7qGCv9qmQ1iarA4pO3Ay+ZyU24W9deuek7bUI2eFn1iyGmfadwZ79bJv5ZiEY w7HY42oGtqSV2DMy9KTmNzHsRgWNKulRTvQKblRQdY+MzpDudPAyVR44NzqgFz3yaT66 K6DkSe/DAiXqCMZ+yJPOQOkl4Xkd5fVKbxyKbz5tDbeZNr/mzZiKSwZ4TLhCGPwtruhN vPQ6Ac5yZbaQgp/2z56+kNEBw5CHBbAgWwlrgiQNWBOeIn5HV/R7ifsGX05r1OxpXf+D 8cB6Pfj9THZpSW8eDSHipQVFROF6znC9yvSGoOJH0njgDOhL3JxlNkHb7EKlQxHsAZp0 B+6g== X-Gm-Message-State: AOAM532ueS2VeizVAyIjFFMFFF0KJziUAgwQJvhqrH3NMJtVAeLMoief jLpT4Q6kdlVPTa094Dw80Zc8flK9zsXQTRHb5Qna5w== X-Google-Smtp-Source: ABdhPJx4QSoyIj1fopFlzw8lalqS+CXoDV9z/J947FFF0qcZKM9PTVDcawor8V0zmVFsUjlRo1nTN2ziOPw4GeiX+80= X-Received: by 2002:a1c:df08:: with SMTP id w8mr7286101wmg.93.1602433770352; Sun, 11 Oct 2020 09:29:30 -0700 (PDT) MIME-Version: 1.0 References: <160209160818.12838.15929178240331409569@ietfa.amsl.com> In-Reply-To: <160209160818.12838.15929178240331409569@ietfa.amsl.com> From: Ivaylo Petrov Date: Sun, 11 Oct 2020 19:29:04 +0300 Message-ID: To: Martin Duke Cc: The IESG , draft-ietf-cose-x509@ietf.org, Cose Chairs Wg , cose Content-Type: multipart/alternative; boundary="000000000000a8875105b167afb6" Archived-At: Subject: Re: [COSE] Martin Duke's No Objection on draft-ietf-cose-x509-07: (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, 11 Oct 2020 16:29:35 -0000 --000000000000a8875105b167afb6 Content-Type: text/plain; charset="UTF-8" Hello Martin, Thank you for your comments! I am not sure if you are aware, but I am going to be handing some editorial changes to this document until publication. I will also try to answer your questions inline. On Wed, Oct 7, 2020 at 8:26 PM Martin Duke via Datatracker wrote: > Martin Duke has entered the following ballot position for > draft-ietf-cose-x509-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I see that it's in the charter as such, but I have no idea why this is > otherwise an Informational RFC, as it extends a Standard RFC and has some > normative language in it for interoperability. > [IP]: From my point of view this has been a decision made during the last rechartering. You can see it in the current charter [1] or this email [2]. One possible reason for that decision is that initially the draft contained hash algorithms as well, which if I understand correctly are usually published in informational drafts. To the best of my knowledge no one has voiced concerns about this document being Informational. If anyone has more context, please chime in. I am not a fan of the passive voice in Section 2: > "Certificates obtained from any of these methods MUST still be validated." > > Who has to validate it? It sounds like we are not requiring constrained > devices > to do this validation, so the document really ought to pin the > responsibility > on the system. > [IP]: My understanding is that the recipient should have enough information to obtain and validate the certificate, while the sender might not have the complete certificate. For example, one possibility is that only part of the certificate chain is sent and the message recipient needs to validate the certificate (possibly using pre-provisioned certificates for building the complete certificate chain), in order to know if it can trust it. Another example is a sender that only has a hash of the certificate along with the private key. In this case the recipient is expected to be able to obtain the correct certificate and validate the message using the appropriate key, probably verifying that the certificate is not revoked, etc. Would the following wording work better for you? Recipients MUST validate the certificate obtained from any of the following four methods. > > > > [1]: https://datatracker.ietf.org/doc/charter-ietf-cose/ [2]: https://mailarchive.ietf.org/arch/msg/cose/YE8-De30lEk52p9bY9oxB74x0BE/ Thanks, Ivaylo --000000000000a8875105b167afb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Martin,

=
Thank you for your comments! I am not sure if you are aware,= but I am going to be handing some editorial changes to this document until= publication. I will also try to answer your questions inline.
<= br>
On Wed,= Oct 7, 2020 at 8:26 PM Martin Duke via Datatracker <noreply@ietf.org> wrote:
Martin Duke has entered = the following ballot position for
draft-ietf-cose-x509-07: No Objection

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


Please refer to https://www.ietf.org/iesg/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-ietf-co= se-x509/



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

I see that it's in the charter as such, but I have no idea why this is<= br> otherwise an Informational RFC, as it extends a Standard RFC and has some normative language in it for interoperability.

[IP]: From my point of view this has been a decision mad= e during the last rechartering. You can see it in the current charter [1] o= r this email [2]. One possible reason for that decision is that initially t= he draft contained hash algorithms as well, which if I understand correctly= are usually published in informational drafts. To the best of my knowledge= no one has voiced concerns about this document being Informational. If any= one has more context, please chime in.

I am not a fan of the passive voice in Section 2:
"Certificates obtained from any of these methods MUST still be validat= ed."

Who has to validate it? It sounds like we are not requiring constrained dev= ices
to do this validation, so the document really ought to pin the responsibili= ty
on the system.

=
[IP]: My understanding is that the recipient=C2=A0should ha= ve enough information to obtain and validate the certificate, while the sen= der might not have the complete certificate. For example, one possibility i= s that only part of the certificate chain is sent and the message recipient= needs to validate the=C2=A0certificate (possibly using pre-provisioned cer= tificates for building the complete certificate chain), in order to know if= it can trust it. Another example is a sender that only has a hash of the c= ertificate along with the private key. In this case the recipient is expect= ed to be able to obtain the correct certificate and validate the message us= ing the appropriate key, probably verifying that the certificate is not rev= oked, etc. Would the following wording work better for you?

Recipients= MUST validate the certificate obtained from any of the following four meth= ods.
=C2=A0
=



--000000000000a8875105b167afb6-- From nobody Mon Oct 12 07:51:06 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE093A1542; Mon, 12 Oct 2020 07:51:01 -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 tRE06toLzVwo; Mon, 12 Oct 2020 07:50:59 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 246303A1541; Mon, 12 Oct 2020 07:50:59 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id l8so17869579ioh.11; Mon, 12 Oct 2020 07:50:59 -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=jgNvOb3Gn6dR1NiXfYVjJpZ+azGmUohS0udFCzZ+3c0=; b=d7pjWjtS4AE4S8mToZ1RMW4Nkz2+JvM7sVhakN0ksBRVLwBU1Ko+S40opnzpGct8YO mku9+Z4v4lvHjuiJ6pZBN4flrHHnCzUMEFWAHv5dFdT+vqreNVV0nj6RlMw7GdzLWH4S oA0DGr1YCY0rk+trd+1MaGQ6bv61xF01lvqWCmzv5PNf1OvTdaO4wmPAyteTun+TGlGc 7U6o5dzblvB4i2kwEiyo/yyxLj88k1fidA1rO1u5uvuXgx+mkQMlI2zMkSzEQoUncj8U /fV/SHTweXT7TdPBdsQ7T8RGpSR0x6KtzvudBvtOZHYP8LChRpUcCxKS8hLj1MAa0vIJ 337w== 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=jgNvOb3Gn6dR1NiXfYVjJpZ+azGmUohS0udFCzZ+3c0=; b=I/NFwAfxLKIRuvI6GyXPKy7c4UDMbcsQ2Ncbu2KZXv5Yl1pdSNjvY4NRFjhqehcl13 iHu5T/0g4ptQm7zdIEKyERrW/OgWIazfTebQ3PRjjHo+Zoy4p3XN3QAf45iA4pOCfqaC Ghw7v1ouCyC0tMLOtzLy9qSeh9+Y+xEDaCJnD2x9QFsN3OlobnsP2hb7GpmsqCvxIyFm fLR8i4G/LOjsY5NQirFJI0pt+gUzof0vDpMO/1wORw1w5+Q4Hj3v9ylULUGrZ3YIQhbF BDrRDtQchaJLj4TUGQcTOGf20WO7g8D4OHQ0XPjOBXrx8y8UMjOk4PyH7jfiTwrlBftK STXg== X-Gm-Message-State: AOAM531Tn7ltgjkfphWnYCtwEGHpGdsNfFewcHWMq8bZaYqQ9vyPlZgD rK1JGkPEAC77mSKJxyYjB6/2cMtPsiOYEaaS3wgYX3l0/Mu8eA== X-Google-Smtp-Source: ABdhPJyWbnpo+tpcKdg5+SEhKEdFbR4yCqsx24fV5jrPKnNZd36HHmxkaZ6fGLrgboRNQCgw8HmWoagT851N738i8MI= X-Received: by 2002:a05:6602:2fc2:: with SMTP id v2mr8112796iow.19.1602514258206; Mon, 12 Oct 2020 07:50:58 -0700 (PDT) MIME-Version: 1.0 References: <160209160818.12838.15929178240331409569@ietfa.amsl.com> In-Reply-To: From: Martin Duke Date: Mon, 12 Oct 2020 07:50:50 -0700 Message-ID: To: Ivaylo Petrov Cc: The IESG , draft-ietf-cose-x509@ietf.org, Cose Chairs Wg , cose Content-Type: multipart/alternative; boundary="0000000000001ba62a05b17a6d96" Archived-At: Subject: Re: [COSE] Martin Duke's No Objection on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 14:51:02 -0000 --0000000000001ba62a05b17a6d96 Content-Type: text/plain; charset="UTF-8" Hi Ivaylo, Thank you very much for taking on this document after the dreadful news. Your proposed sentence is an improvement, but I'm not sure how it combines with the earlier sentence "It is not necessarily expected that constrained devices themselves will evaluate and process of X.509 certificates". Is "evaluate and process" a different action than "validating" it? Or is the suggestion here that the constrained device is given a certificate to authenticate itself that it does not bother to verify, but hosts that connect to it *would* validate the certificate? Martin On Sun, Oct 11, 2020, 09:29 Ivaylo Petrov wrote: > Hello Martin, > > Thank you for your comments! I am not sure if you are aware, but I am > going to be handing some editorial changes to this document until > publication. I will also try to answer your questions inline. > > On Wed, Oct 7, 2020 at 8:26 PM Martin Duke via Datatracker < > noreply@ietf.org> wrote: > >> Martin Duke has entered the following ballot position for >> draft-ietf-cose-x509-07: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I see that it's in the charter as such, but I have no idea why this is >> otherwise an Informational RFC, as it extends a Standard RFC and has some >> normative language in it for interoperability. >> > > [IP]: From my point of view this has been a decision made during the last > rechartering. You can see it in the current charter [1] or this email [2]. > One possible reason for that decision is that initially the draft contained > hash algorithms as well, which if I understand correctly are usually > published in informational drafts. To the best of my knowledge no one has > voiced concerns about this document being Informational. If anyone has more > context, please chime in. > > I am not a fan of the passive voice in Section 2: >> "Certificates obtained from any of these methods MUST still be validated." >> >> Who has to validate it? It sounds like we are not requiring constrained >> devices >> to do this validation, so the document really ought to pin the >> responsibility >> on the system. >> > > [IP]: My understanding is that the recipient should have enough > information to obtain and validate the certificate, while the sender might > not have the complete certificate. For example, one possibility is that > only part of the certificate chain is sent and the message recipient needs > to validate the certificate (possibly using pre-provisioned certificates > for building the complete certificate chain), in order to know if it can > trust it. Another example is a sender that only has a hash of the > certificate along with the private key. In this case the recipient is > expected to be able to obtain the correct certificate and validate the > message using the appropriate key, probably verifying that the certificate > is not revoked, etc. Would the following wording work better for you? > > Recipients MUST validate the certificate obtained from any of the > following four methods. > > > >> >> >> >> > [1]: https://datatracker.ietf.org/doc/charter-ietf-cose/ > [2]: > https://mailarchive.ietf.org/arch/msg/cose/YE8-De30lEk52p9bY9oxB74x0BE/ > > > Thanks, > Ivaylo > --0000000000001ba62a05b17a6d96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ivaylo,

Thank you very mu= ch for taking on this document after the dreadful news.

Your proposed sentence is an improvement, but I'm not sure how it= combines with the earlier sentence "It is not necessarily expected th= at constrained devices themselves will evaluate and process of X.509 certif= icates". Is "evaluate and process" a different action than &= quot;validating" it?

Or is the suggestion her= e that the constrained device is given a certificate=C2=A0to authenticate i= tself that it does not bother to verify, but hosts that connect to it *woul= d* validate the certificate?

Martin

=

On Sun, Oct 11, 2020, 09:29 Ivaylo Petrov <= ;ivaylo@ackl.io>= wrote:
Hello Martin,

Thank you for your comments! I am not sure if y= ou are aware, but I am going to be handing some editorial changes to this d= ocument until publication. I will also try to answer your questions inline.=

On Wed, Oct 7, 2020 at 8:26 PM Martin Duke via Datatracker <noreply@= ietf.org> wrote:
Martin Duke has entered the following ballot position for
draft-ietf-cose-x509-07: No Objection

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


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


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



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

I see that it's in the charter as such, but I have no idea why this is<= br> otherwise an Informational RFC, as it extends a Standard RFC and has some normative language in it for interoperability.

[IP]: From my point of view this has been a decision mad= e during the last rechartering. You can see it in the current charter [1] o= r this email [2]. One possible reason for that decision is that initially t= he draft contained hash algorithms as well, which if I understand correctly= are usually published in informational drafts. To the best of my knowledge= no one has voiced concerns about this document being Informational. If any= one has more context, please chime in.

I am not a fan of the passive voice in Section 2:
"Certificates obtained from any of these methods MUST still be validat= ed."

Who has to validate it? It sounds like we are not requiring constrained dev= ices
to do this validation, so the document really ought to pin the responsibili= ty
on the system.

=
[IP]: My understanding is that the recipient=C2=A0should ha= ve enough information to obtain and validate the certificate, while the sen= der might not have the complete certificate. For example, one possibility i= s that only part of the certificate chain is sent and the message recipient= needs to validate the=C2=A0certificate (possibly using pre-provisioned cer= tificates for building the complete certificate chain), in order to know if= it can trust it. Another example is a sender that only has a hash of the c= ertificate along with the private key. In this case the recipient is expect= ed to be able to obtain the correct certificate and validate the message us= ing the appropriate key, probably verifying that the certificate is not rev= oked, etc. Would the following wording work better for you?

Reci= pients MUST validate the certificate obtained from any of the following fou= r methods.
= =C2=A0




--0000000000001ba62a05b17a6d96-- From nobody Mon Oct 12 14:32: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 3D9C73A09FC; Mon, 12 Oct 2020 14:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 VOKOCZYDCsIf; Mon, 12 Oct 2020 14:32:06 -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 2C19F3A09F8; Mon, 12 Oct 2020 14:32:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0FECB38994; Mon, 12 Oct 2020 17:37:47 -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 STMBEDUSxbIY; Mon, 12 Oct 2020 17:37:46 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 93EE138992; Mon, 12 Oct 2020 17:37:46 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7FB2E490; Mon, 12 Oct 2020 17:32:03 -0400 (EDT) From: Michael Richardson To: Martin Duke cc: Ivaylo Petrov , Cose Chairs Wg , draft-ietf-cose-x509@ietf.org, The IESG , cose In-Reply-To: References: <160209160818.12838.15929178240331409569@ietfa.amsl.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] Martin Duke's No Objection on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 21:32:08 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Martin Duke wrote: > Your proposed sentence is an improvement, but I'm not sure how it com= bines > with the earlier sentence "It is not necessarily expected that constr= ained > devices themselves will evaluate and process of X.509 certificates". = Is > "evaluate and process" a different action than "validating" it? Validating is a well defined, complex process (RFC6125, etc.) involving pat= h validation, etc. Evaluate might mean something less, such as extracting the public key and comparing against some known value. We don't expect any of that. > Or is the suggestion here that the constrained device is given a > certificate to authenticate itself that it does not bother to verify,= but > hosts that connect to it *would* validate the certificate? Yes, generally, that is what a lot of us have in mind. The constrained device has a credential, if in the form of an IDevID or LDevID certificate, then it would use this specification to places it into the COSE object as a blob. It has the private key side in a format that is more convenient for processing (perhaps even in a secure enclave of some kind) which it uses to sign. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+Ey1MACgkQgItw+93Q 3WVs5Af+JxAzOwHczF+k/PtVhzJb4YlNceZLxhFOI9vw8CP9AQ0JOlcm6WqlknYn Qpdp/Q03H11UfDKgEJ7uW0isqgbTo3NGJyk26nBSiMd51e4t9tPj7+hCPE+KcwdC VvUeOMgGxlMX/gPebyr4fWf44HGdN1L5qvMM9Axtj38/fUIyDSAMejqJKHDd6k3K fTk8BfLwlO9fgYpRn+i7i+WhBiKBV6qXdisnrkbTxchqxAEi2sPKwazjPuXFPq/R 5PMPEtUViDNgRqyEVI2vUfMTv8nGyhX6SGl3c5ndDHoejQC60YxFYJ3Ea7MT5Dqs GU9Csk7cflCSuMxNtuPf/ue8RX+uJA== =Fivy -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 13 07:54: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 A93F43A0891 for ; Tue, 13 Oct 2020 07:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsAU-pxBjDVP for ; Tue, 13 Oct 2020 07:54:45 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 8F1AA3A0880 for ; Tue, 13 Oct 2020 07:54:44 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id e2so259290wme.1 for ; Tue, 13 Oct 2020 07:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tc5Ic8c3O+DazP9E+226qMST+wS67u8HCDwGh0y1YWs=; b=RyoXsmdQt5QXU8aS8W1pBH1HU9j5Jv0qJD7KQgiG0DEXrPmDsKLvkP5tBeYZdFvnm8 NcAGYV8y3UkXDT3ez6+XAsPMGxIEJAtV1URbZy7CauSep3/bNDvM400cbCnbk7FB6now Uxj9zXHNcjbCcsIdhyILcZPPb0otcpsCZOwJN0TUdhERKal5EMO+c+6BQwYWvkNnuDpx e67o7pOrHfgoLikSGpPx3vA3MdAb9LOtHqMzqWVq/mYxtMeYXp9K5BOuZjPqSL4ppyoY fwevlqYkheh8vtUcBBfibNBtVLjyFkDHnFPKmaWItVED8C25oGRgmbGGqsaS3agbCc7Q toEw== 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=Tc5Ic8c3O+DazP9E+226qMST+wS67u8HCDwGh0y1YWs=; b=sZwNXKcbfA3niH44hJyg3guDymeKhh8uHDXP2Z0s+pRuyXXaJhM3O9FwM6Yew+C3LC EzKI7oR+7Mj9CRJDZsgeqDP9OoHf0UyniyBAfMCrZEzR/TSUvDRTpqHMapVEQdp2AKEi i7fDPbrmYJkIYwcEzBYSD18XTUhQoWLnhc/L3VYAwNRKH3hsa3H0eAoUlt0YLZZa+wlQ UZ0m2Qw7bKdT26XR1bMtZngyIfrkyU07inD+LA0LRxwjlEWysCOPwYGkRVJ8uRVANvAK T0JxntW4CTRsrqTeBLsz15gKj329NlxZuww02pHxGxqlX8XQUSfo/SJ1C6ECs1+OvePc Z59w== X-Gm-Message-State: AOAM530vXek3GRnRB/a2pK/FPQiP4l3c7VIaMm7iPgA+B6LXdYzneCCM RDa229FT6mx9ja7BxNzyud7nfIMWZVzMmi46vQ0gig== X-Google-Smtp-Source: ABdhPJzdA8HHv0ix4yV5rvfGMm2T5yqzJXS+9znws/kO1zFcJE3ZnhlBOycfhYVs/ZBBLLHfYNrdrj5SNGgo5bvjjuQ= X-Received: by 2002:a05:600c:608:: with SMTP id o8mr261696wmm.86.1602600882606; Tue, 13 Oct 2020 07:54:42 -0700 (PDT) MIME-Version: 1.0 References: <160209160818.12838.15929178240331409569@ietfa.amsl.com> <21362.1602538323@localhost> In-Reply-To: <21362.1602538323@localhost> From: Ivaylo Petrov Date: Tue, 13 Oct 2020 16:54:16 +0200 Message-ID: To: Michael Richardson Cc: Martin Duke , Cose Chairs Wg , draft-ietf-cose-x509@ietf.org, The IESG , cose Content-Type: multipart/alternative; boundary="0000000000005329a805b18e98d9" Archived-At: Subject: Re: [COSE] Martin Duke's No Objection on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 14:54:48 -0000 --0000000000005329a805b18e98d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Michael! That is also my understanding. On Mon, Oct 12, 2020 at 11:32 PM Michael Richardson wrote: > > Martin Duke wrote: > > Your proposed sentence is an improvement, but I'm not sure how it > combines > > with the earlier sentence "It is not necessarily expected that > constrained > > devices themselves will evaluate and process of X.509 certificates"= . > Is > > "evaluate and process" a different action than "validating" it? > > Validating is a well defined, complex process (RFC6125, etc.) involving > path validation, etc. > Evaluate might mean something less, such as extracting the public key and > comparing against some known value. We don't expect any of that. > > > Or is the suggestion here that the constrained device is given a > > certificate to authenticate itself that it does not bother to > verify, but > > hosts that connect to it *would* validate the certificate? > > Yes, generally, that is what a lot of us have in mind. > > The constrained device has a credential, if in the form of an IDevID or > LDevID certificate, then it would use this specification to places it int= o > the COSE object as a blob. > > It has the private key side in a format that is more convenient for > processing (perhaps even in a secure enclave of some kind) which it uses = to > sign. > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > --0000000000005329a805b18e98d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Michael! That is also my understanding.
=


On Mon, Oct 12, 2020 at 11:32 PM Michael = Richardson <mcr+ietf@sandelman.ca> wrote:

Martin Duke <martin.h.duke@gmail.com> wrote:
=C2=A0 =C2=A0 > Your proposed sentence is an improvement, but I'm no= t sure how it combines
=C2=A0 =C2=A0 > with the earlier sentence "It is not necessarily ex= pected that constrained
=C2=A0 =C2=A0 > devices themselves will evaluate and process of X.509 ce= rtificates". Is
=C2=A0 =C2=A0 > "evaluate and process" a different action than= "validating" it?

Validating is a well defined, complex process (RFC6125, etc.) involving pat= h validation, etc.
Evaluate might mean something less, such as extracting the public key and comparing against some known value.=C2=A0 We don't expect any of that.<= br>
=C2=A0 =C2=A0 > Or is the suggestion here that the constrained device is= given a
=C2=A0 =C2=A0 > certificate to authenticate itself that it does not both= er to verify, but
=C2=A0 =C2=A0 > hosts that connect to it *would* validate the certificat= e?

Yes, generally, that is what a lot of us have in mind.

The constrained device has a credential, if in the form of an IDevID or
LDevID certificate, then it would use this specification to places it into<= br> the COSE object as a blob.

It has the private key side in a format that is more convenient for
processing (perhaps even in a secure enclave of some kind) which it uses to=
sign.

--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide
--0000000000005329a805b18e98d9-- From nobody Tue Oct 13 08:54:03 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78303A03F5 for ; Tue, 13 Oct 2020 08:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FE5FIgiGogT for ; Tue, 13 Oct 2020 08:54:01 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 DB4123A03F1 for ; Tue, 13 Oct 2020 08:54:00 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id d3so153884wma.4 for ; Tue, 13 Oct 2020 08:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ZQpH8j6ki1LT1vVnu7B4SAP/w79XB8DitdnpL/JEYjQ=; b=GLshVrY89oE7p7Gz2rbrYPUTqQXZDsdiwzu2PtBA1US/r1tUlAWG6NxRkY10mCEoz0 I/nifeFm2P8WIAHeAI258z1lntDOuoga3BNDB0Xv4yVV/kDvHFV4fQyDM2fCHzSEbIH5 ZqIWoqNQCfsE8CYr4HgTE6FdBfD3u6CIFifHETmkYrcZsly+VWEwfioobh5uOHaBCA3H atyA4CMFU4GcyrNb0/YZGJT2+tX24pwd5k1FddpfuCG2LlHBurkEVKCfoYn7xF9vAQYe /CaeIUOytPSXUsh8rYV6mFcnAIIagjGwUPpCRwVxYt6/W0bp4h7yiar0eLW706ngxStx CvuQ== 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=ZQpH8j6ki1LT1vVnu7B4SAP/w79XB8DitdnpL/JEYjQ=; b=Vmn/aCQltP/vyPmY3x6BR8gddUcFJookzKqsEA1Xjv/5njQfdey/4uWUonGi92mlhK CQ3JeLuLTOiS8Q8NhFJK2dOnOSByVE0/TLKOfz9hjU7M0d0lipPm9i2GMB5q6uYSIBdY 6+uajDQ9HDnaIDbgm8CQVhCFR3GFaLdMqqWVEUrR1Iq1rPmIAm6OdcG/zJ4Y+GlmMkYA E/IoRJLF7W0FTlwYX+1efGGmcDJcf8VJSnPe9YcP8bW0u0Js/gzDeuCgEbD11XM2doUE ZM7eLLn2sEGzBH5zZz+KgfSCLRK+W3vLQdTa63c7IURfn/jfV5YKV8WsBSxDF4FXCkyd uDFQ== X-Gm-Message-State: AOAM530SxKa2AbXRPewvE2jyTvuI3VgVIY4GC8G8w9IGqNFAB0J2Yn+P /AXo/L0x1ZHINPFolbDc09zmnUpQhqrbR+2hXIuZgDG7gEhXhanm X-Google-Smtp-Source: ABdhPJxp4r18/o4ueHIQdn6mR9ThaAdnH7vLfXit6VWNqVNxb2bt7iPA4gbjEq0V9fFf0oMcZINF69c1Kh+GCSxqnlU= X-Received: by 2002:a1c:4887:: with SMTP id v129mr524658wma.13.1602604438698; Tue, 13 Oct 2020 08:53:58 -0700 (PDT) MIME-Version: 1.0 From: Ivaylo Petrov Date: Tue, 13 Oct 2020 17:53:32 +0200 Message-ID: To: cose Content-Type: multipart/alternative; boundary="00000000000048d74e05b18f6c57" Archived-At: Subject: [COSE] Minutes and Recording from 2020-10-07 Interim 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, 13 Oct 2020 15:54:03 -0000 --00000000000048d74e05b18f6c57 Content-Type: text/plain; charset="UTF-8" Dear all, The minutes have been uploaded to datatracker: < https://datatracker.ietf.org/doc/minutes-interim-2020-cose-05-202010071600/ > The recording is also available: < https://www.youtube.com/watch?v=P0WoNKp5WNI > Please send any corrections to this list or to cose-chairs@ietf.org. See you soon, - Matthew & Ivaylo COSE WG Chairs --00000000000048d74e05b18f6c57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

The=C2=A0minutes=C2=A0have been uploaded to datatracker: <=C2=A0<= a href=3D"https://datatracker.ietf.org/doc/minutes-interim-2020-cose-05-202= 010071600/">https://datatracker.ietf.org/doc/minutes-interim-2020-cose-05-2= 02010071600/ >

The recording is also available: <=C2= =A0https://www.yo= utube.com/watch?v=3DP0WoNKp5WNI=C2=A0>

Please send any = corrections to this list or to=C2=A0cose-chairs@ietf.org.

See you soon,

- Matthew & Ivaylo
COSE WG Chairs
<= div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature= ">
--00000000000048d74e05b18f6c57-- From nobody Fri Oct 16 16:32:40 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 91DA13A0965; Fri, 16 Oct 2020 16:32: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=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 ZOlLTV6HgEJt; Fri, 16 Oct 2020 16:32:21 -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 1596E3A0978; Fri, 16 Oct 2020 16:32:19 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4CCj9Y6g7szyX6; Sat, 17 Oct 2020 01:32:17 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 624583937.127264-88b71d10106123a895c57d7ea3ef9d06 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 17 Oct 2020 01:32:17 +0200 Message-Id: To: ace@ietf.org, "core@ietf.org WG (core@ietf.org)" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [COSE] Constrained Node/Network Cluster @ IETF109: DRAFT AGENDA X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 23:32:23 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF109. Remember that there is still quite some potential for changes. The conflicts that meet the eye this time seem to impact generalists = only. Great scheduling job! All times *on my agenda* are in UTC (the default page is UTC+0700). https://datatracker.ietf.org/meeting/agenda-utc might be handy. Note that both EU and US are on winter time (standard time) then. Gr=C3=BC=C3=9Fe, Carsten MONDAY, November 9, 2020 0500-0700 Hackathon Kickoff Rm 1 GEN hackathon Hackathon FRIDAY, November 13, 2020 0500-0700 Hackathon Closing Rm 1 GEN hackathon Hackathon MONDAY, November 16, 2020 0500-0700 Session I Rm 1 ART dispatch Dispatch WG - Joint with ARTAREA Rm 3 IRTF qirg Quantum Internet Research Group Rm 5 RTG raw Reliable and Available Wireless WG Rm 6 SEC *** lake Lightweight Authenticated Key Exchange = WG 0730-0830 Session II Rm 3 INT add Adaptive DNS Discovery WG Rm 4 IRTF maprg Measurement and Analysis for Protocols Rm 7 SEC *** cose CBOR Object Signing and Encryption WG 0900-1100 Session III Rm 1 ART jsonpath JSON Path WG Rm 6 SEC secdispatch Security Dispatch WG Rm 7 TSV tsvwg Transport Area Working Group WG TUESDAY, November 17, 2020 0500-0700 Session I Rm 1 ART *** core Constrained RESTful Environments WG Rm 2 INT 6man IPv6 Maintenance WG Rm 7 SEC gnap Grant Negotiation and Authorization = Protocol WG 0730-0830 Session II Rm 5 RTG babel Babel routing protocol WG Rm 6 SEC tls Transport Layer Security WG 0900-1100 Session III Rm 1 ART *** asdf A Semantic Definition Format for Data = and Interactions of Things WG Rm 2 IRTF irtfopen IRTF Open Meeting Rm 4 RTG apn Application-aware Networking BOF Rm 7 SEC *** rats Remote ATtestation ProcedureS WG WEDNESDAY, November 18, 2020 0500-0700 Session I Rm 3 INT madinas MAC Address Device Identification for = Network and Application Services BOF Rm 5 RTG bier Bit Indexed Explicit Replication WG Rm 7 SEC *** ace Authentication and Authorization for = Constrained Environments WG Rm 8 TSV quic QUIC WG 0730-0830 Session II Rm 3 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Rm 4 INT *** drip Drone Remote ID Protocol WG Rm 7 SEC *** teep Trusted Execution Environment = Provisioning WG Rm 8 TSV tsvwg Transport Area Working Group WG THURSDAY, November 19, 2020 0500-0700 Session I Rm 3 IRTF coinrg Computing in the Network Research Group Rm 7 SEC saag Security Area Open Meeting 0730-0830 Session II Rm 1 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Rm 2 INT intarea Internet Area Working Group WG Rm 3 RTG detnet Deterministic Networking WG Rm 5 SEC acme Automated Certificate Management = Environment WG 0900-1100 Session III Rm 4 OPS v6ops IPv6 Operations WG Rm 6 RTG *** roll Routing Over Low power and Lossy = networks WG Rm 7 SEC mls Messaging Layer Security WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG FRIDAY, November 20, 2020 0500-0700 Session I Rm 2 INT add Adaptive DNS Discovery WG Rm 6 RTG rift Routing In Fat Trees WG Rm 7 SEC emu EAP Method Update WG 0730-0830 Session II Rm 1 ART httpapi Building Blocks for HTTP APIs WG Rm 2 INT *** lwig Light-Weight Implementation Guidance WG Rm 3 OPS anima Autonomic Networking Integrated Model = and Approach WG Rm 6 SEC *** suit Software Updates for Internet of Things = WG Rm 7 TSV tsvarea Transport Area Open Meeting 0900-1100 Session III Rm 1 ART *** core Constrained RESTful Environments WG Rm 2 INT 6man IPv6 Maintenance WG Rm 4 IRTF cfrg Crypto Forum Rm 7 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG From nobody Mon Oct 19 10:45:40 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 018843A0EC4 for ; Mon, 19 Oct 2020 10:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.006 X-Spam-Level: X-Spam-Status: No, score=0.006 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 NQGBPPpXisyo for ; Mon, 19 Oct 2020 10:45:37 -0700 (PDT) Received: from p3plsmtpa07-09.prod.phx3.secureserver.net (p3plsmtpa07-09.prod.phx3.secureserver.net [173.201.192.238]) (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 43A023A0EC3 for ; Mon, 19 Oct 2020 10:45:37 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id UZDzkiBiOZigzUZDzkVseX; Mon, 19 Oct 2020 10:45:36 -0700 X-CMAE-Analysis: v=2.3 cv=IOt89TnG c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=l70xHGcnAAAA:8 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=CI9HjJ-QkOq-AAOFsxsA:9 a=DU5BY7Wam8pebX3E:21 a=2jmbSVgzKEt9oGN8:21 a=QEXdDO2ut3YA:10 a=2ggvodTJGCP04rzRnNgA:9 a=DVpTptuQkvggA9uB:21 a=9qX8XmUltI7ECh9-:21 a=fKoK4CbnZ2SET555:21 a=_W_S_7VecoQA:10 a=JtN_ecm89k2WOvw5-HMO:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <0ABC7267-6534-44CD-9ACA-E4F568CD07AE@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_69183E4C-48FB-42D1-BE58-DAC10576EF9B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Mon, 19 Oct 2020 10:45:35 -0700 In-Reply-To: <21362.1602538323@localhost> Cc: Martin Duke , cose , Cose Chairs Wg , draft-ietf-cose-x509@ietf.org, The IESG , Ivaylo Petrov To: Michael Richardson References: <160209160818.12838.15929178240331409569@ietfa.amsl.com> <21362.1602538323@localhost> X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4wfNyQpAcP/+7Re262a0k0oZcnG9l374FZeeRsElXuT4iivPGN/RT29DHcbLbt9jZvMSNilDlKWHflrQB2wGZq3xlqG9kpSiUzmXSRohWCXEob57eRwK1O 2H7eIg0rFKjA6m71jRKtOj7hZ7/50sV32gzDnmmWPY4SObGWif76yv9vrWkfJu6w4/eh2RPt2JmKATonK784VaHXbYt6ZGJj0j5aGr0unbipDmic3X+SXbeW fVF1pHzYILaFY8Wqg2CDlErmuDdVDp1e75Ir75wQxm2nszPSPSdeGRRrGr+1LSepaHEcMo9mTIyunhf0DbYyZAMtUIHqkCBRIOtCwB1JAn3kZ6uCulsDCctl eA/LZCc9 Archived-At: Subject: Re: [COSE] Martin Duke's No Objection on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 17:45:39 -0000 --Apple-Mail=_69183E4C-48FB-42D1-BE58-DAC10576EF9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is true, right? The relying party (the receiver) always has to = validate the certificate chain up to a trust anchor even if it is a = constrained device. The sender only has to insert certificates into the = header, not validate, even if it is a non-constrained device. This is = true of CMS, TLS and so on. There is nothing new or unique here right? For example, if a constrained device is verifying code signatures, = trusted boot chains or SUIT manifests, it has to fully validate the = certificate chain up to a trust anchor.=20 This paragraph is true for some use cases like CWT and Attestation, but = not all use cases. It is not necessarily expected that constrained devices will fully support the evaluation and processing of X.509 certificates, it is perfectly reasonable for a certificate to be assigned to a device which it can then provide to a relying party along with a signature or encrypted message, the relying party not being a constrained device. It is the requirements and design of the end-end system that determines = what the constrained device has to do or not do, not the design of these = headers. Probably it is an overreach to discuss end-end system designs. = Maybe it is just better to remove this paragraph? LL > On Oct 12, 2020, at 2:32 PM, Michael Richardson = wrote: >=20 >=20 > Martin Duke wrote: >> Your proposed sentence is an improvement, but I'm not sure how it = combines >> with the earlier sentence "It is not necessarily expected that = constrained >> devices themselves will evaluate and process of X.509 certificates". = Is >> "evaluate and process" a different action than "validating" it? >=20 > Validating is a well defined, complex process (RFC6125, etc.) = involving path validation, etc. > Evaluate might mean something less, such as extracting the public key = and > comparing against some known value. We don't expect any of that. >=20 >> Or is the suggestion here that the constrained device is given a >> certificate to authenticate itself that it does not bother to verify, = but >> hosts that connect to it *would* validate the certificate? >=20 > Yes, generally, that is what a lot of us have in mind. >=20 > The constrained device has a credential, if in the form of an IDevID = or > LDevID certificate, then it would use this specification to places it = into > the COSE object as a blob. >=20 > It has the private key side in a format that is more convenient for > processing (perhaps even in a secure enclave of some kind) which it = uses to > sign. >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_69183E4C-48FB-42D1-BE58-DAC10576EF9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = is true, right? The relying party (the receiver) always has to validate = the certificate chain up to a trust anchor even if it is a constrained = device. The sender only has to insert certificates into the header, not = validate, even if it is a non-constrained device. This is true of CMS, = TLS and so on. There is nothing new or unique here right?

For = example, if a constrained device is verifying code signatures, trusted = boot chains or SUIT manifests, it has to fully validate the certificate = chain up to a trust anchor. 

This paragraph is true for some use = cases like CWT and Attestation, but not all use cases.

   It is not necessarily =
expected that constrained devices will fully
   support the evaluation and processing of X.509 certificates, it is
   perfectly reasonable for a certificate to be assigned to a device
   which it can then provide to a relying party along with a signature
   or encrypted message, the relying party not being a constrained
   device.

It is the requirements and design of the end-end system that = determines what the constrained device has to do or not do, not the = design of these headers. Probably it is an overreach to discuss end-end = system designs. Maybe it is just better to remove this = paragraph?

LL


On Oct = 12, 2020, at 2:32 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Martin Duke <martin.h.duke@gmail.com> wrote:
Your proposed sentence = is an improvement, but I'm not sure how it combines
with = the earlier sentence "It is not necessarily expected that constrained
devices themselves will evaluate and process of X.509 = certificates". Is
"evaluate and process" a different = action than "validating" it?

Validating is a well defined, complex process (RFC6125, etc.) = involving path validation, etc.
Evaluate might mean = something less, such as extracting the public key and
comparing against some known value.  We don't expect any = of that.

Or is the suggestion here that the constrained device is = given a
certificate to authenticate itself that it does = not bother to verify, but
hosts that connect to it *would* = validate the certificate?

Yes, = generally, that is what a lot of us have in mind.

The constrained device has a credential, if in the form of an = IDevID or
LDevID certificate, then it would use this = specification to places it into
the COSE object as a = blob.

It has the private key side in a = format that is more convenient for
processing (perhaps = even in a secure enclave of some kind) which it uses to
sign.

--
Michael = Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 I=C3=B8T= consulting )
=           Sandelman = Software Works Inc, Ottawa and Worldwide
_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

= --Apple-Mail=_69183E4C-48FB-42D1-BE58-DAC10576EF9B-- From nobody Mon Oct 19 11:40:37 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 0FD893A0FB0 for ; Mon, 19 Oct 2020 11:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 zM87nZgwJWjq for ; Mon, 19 Oct 2020 11:40:35 -0700 (PDT) Received: from p3plsmtpa12-07.prod.phx3.secureserver.net (p3plsmtpa12-07.prod.phx3.secureserver.net [68.178.252.236]) (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 0DA873A0FAF for ; Mon, 19 Oct 2020 11:40:34 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id Ua5BkamsxvGI2Ua5BkppQt; Mon, 19 Oct 2020 11:40:33 -0700 X-CMAE-Analysis: v=2.3 cv=XvuExmN9 c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=taBwYWCNA6xjU3mLkucA:9 a=QEXdDO2ut3YA:10 a=pHzHmUro8NiASowvMSCR:22 a=nt3jZW36AmriUCFCBwmW:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Message-Id: <9284FE68-45D9-4282-8526-78914C3E3043@island-resort.com> Date: Mon, 19 Oct 2020 11:40:33 -0700 To: cose X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4wfJ2Mg6Xbq9xx22Sps/nHAYwhQCWKPwKmMmhcUy2u+VbDzbtfo3ugv7VbllDgXLDlDmg5nYS07kd8uvCHUISvX2ISTxLtMzm024K93CDy+aaS4PD249tv 7QIYDnC1okMy3DGUAJjQf+QkR9yrIMHPsR1qdBvXe0ZJK1TB9CjiSjwV Archived-At: Subject: [COSE] draft-ietf-cose-x509-07 and x5u header 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, 19 Oct 2020 18:40:36 -0000 I=E2=80=99m trying to understand why the x5u header must be a COSE = protected header parameter and in general what the expected use of this = header is. My understanding is that it the relying party that is validating the = cert chain is the one doing the HTTP fetching. In the case of application/pkix-cert, then only one DER cert is returned = and that is the end-entity cert. My expectation for the way this would work is: - The relying party would use HTTP to with the x5u URL to fetch the = end-entity cert - The relying party would have a trust anchor previously configured - The certs in the chain between the end-entity are either already = possess by the relying party or are in the x5bag header - Then it is just a straight forward chain formation and validation.=20= In this use, there is no requirement for security of the URL or for use = of TLS to fetch it. All the necessary security is provided by standard = chain validation. So why is there a requirement that the header be protected and that = TLS/DTLS be used? Further, wouldn't the header protection be a form of self signing since = the private key used to sign the header corresponds to the public key = that is being fetched? But maybe I am grossly misunderstanding the intended use of x5u? Thanks, LL From nobody Mon Oct 19 12:11:25 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6E03A1065 for ; Mon, 19 Oct 2020 12:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 XGAP01NM8NYt for ; Mon, 19 Oct 2020 12:11:22 -0700 (PDT) Received: from p3plsmtpa12-04.prod.phx3.secureserver.net (p3plsmtpa12-04.prod.phx3.secureserver.net [68.178.252.233]) (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 0C1303A1062 for ; Mon, 19 Oct 2020 12:11:21 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id UaYyk0jswfROfUaYykVTm0; Mon, 19 Oct 2020 12:11:20 -0700 X-CMAE-Analysis: v=2.3 cv=Ubovt5aN c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=NeJZvmmVAAAA:20 a=0fGRx5Cg8MAgNvnAU68A:9 a=QEXdDO2ut3YA:10 a=cMHXkdK_To_S8wdj9G8A:9 a=_W_S_7VecoQA:10 a=WQnItmPV2fbdzLaCP6-h:22 a=sGdjRKYcF6ZcXPNQMhXj:22 a=p-dnK0njbqwfn1k4-x12:22 a=qxG4R2aHmpcNjmqRPJKJ:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_101C2FB2-4C11-4150-B98E-9D300F7C64B3" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Mon, 19 Oct 2020 12:11:20 -0700 References: <9284FE68-45D9-4282-8526-78914C3E3043@island-resort.com> To: cose In-Reply-To: <9284FE68-45D9-4282-8526-78914C3E3043@island-resort.com> Message-Id: <45E59EC6-AC14-4477-8BB0-10053BFD1C39@island-resort.com> X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4wfGIdxFsLkGYKAN+ghfwgmusxOFN1m3L7gZoQUAFas7ahu0M4GRKmNI2Brc9WHMBfR8Xm5eba99W8Ei7L7mAEgMvUGYr/Hpg2CK3Jm94UNBwDz/XwToDc 398u9QUXzVJBcecLhj5eMea9col1B8dcZvOEYqH9BpgCrZOrfQktTw2i Archived-At: Subject: [COSE] draft-ietf-cose-x509-07 examples 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, 19 Oct 2020 19:11:24 -0000 --Apple-Mail=_101C2FB2-4C11-4150-B98E-9D300F7C64B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 draft-ietf-cose-x509-07 says: Example COSE messages for the various header parameters defined below can be found at https://github.com/cose-wg/Examples = . When I looked, I couldn=E2=80=99t find any (to help me answer other = questions posted here). I grepped through all the JSON for 509, x5bag, = x5u=E2=80=A6 and got no hits. LL= --Apple-Mail=_101C2FB2-4C11-4150-B98E-9D300F7C64B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 draft-ietf-cose-x509-07= says:

   Example COSE messages for =
the various header parameters defined below
   can be found at https://github.com/cose-wg/Examples.


When I = looked, I couldn=E2=80=99t find any (to help me answer other questions = posted here). I grepped through all the JSON for 509, x5bag, x5u=E2=80=A6 = and got no hits.

LL
= --Apple-Mail=_101C2FB2-4C11-4150-B98E-9D300F7C64B3-- From nobody Mon Oct 19 12:18:35 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 32CFF3A106D; Mon, 19 Oct 2020 12:18:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-cose-x509@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov , ivaylo@ackl.io X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <160313511018.7246.11234492090901667420@ietfa.amsl.com> Date: Mon, 19 Oct 2020 12:18:30 -0700 Archived-At: Subject: [COSE] Robert Wilton's No Objection on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 19:18:30 -0000 Robert Wilton has entered the following ballot position for draft-ietf-cose-x509-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would like to thank Jim Schaad for this document and all his other work at IETF. My only minor comment is that I was surprised by the name "x5bag", which in computing terms I generally understand to be defined as a data structure that is like a set but it can contain duplicate values (also known as a multiset). It wasn't clear to me that was the intended purpose here, but I seem to recall that 'bag' might take a slightly different meaning in security circles? Either way, it might be helpful to specify both for the x5bag and x5chain whether or not duplicate certificates are allowed to be present. Regards, Rob From nobody Mon Oct 19 14:31: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 B5CCE3A0AA9; Mon, 19 Oct 2020 14:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lryDJKd_gXK; Mon, 19 Oct 2020 14:31:14 -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 05DF23A0AA3; Mon, 19 Oct 2020 14:31:13 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4CFVLR4V44zyVf; Mon, 19 Oct 2020 23:31:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <20201007161014.GP89563@kduck.mit.edu> Date: Mon, 19 Oct 2020 23:31:11 +0200 Cc: Matthew Miller , The IESG , draft-ietf-cose-rfc8152bis-struct@ietf.org, cose-chairs@ietf.org, cose X-Mao-Original-Outgoing-Id: 624835871.1018341-8e6c33b87161084e77e083806ecfb386 Content-Transfer-Encoding: quoted-printable Message-Id: References: <160204883573.26847.11501294022082441021@ietfa.amsl.com> <4920FB90-3F45-4050-8205-2B09D4B84265@outer-planes.net> <20201007161014.GP89563@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Yes on draft-ietf-cose-rfc8152bis-struct-14: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 21:31:17 -0000 One terribly niggly nit: The examples in C.3.3 and C.5.4 say =E2=80=9CECHD=E2=80=9D in a comment = where they need to say =E2=80=9CECDH=E2=80=9D. (This is also a trivial errata report on the same appendixes in RFC 8152 = that I haven=E2=80=99t written up yet.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Oct 19 15:04:25 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 C958A3A0C0A; Mon, 19 Oct 2020 15:04:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carsten Bormann via Datatracker To: Cc: last-call@ietf.org, draft-ietf-cose-x509.all@ietf.org, cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160314506078.20558.15385106097623388280@ietfa.amsl.com> Reply-To: Carsten Bormann Date: Mon, 19 Oct 2020 15:04:20 -0700 Archived-At: Subject: [COSE] Iotdir telechat review of draft-ietf-cose-x509-07 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, 19 Oct 2020 22:04:21 -0000 Reviewer: Carsten Bormann Review result: Ready with Issues First, I would like to express my gratitude to Jim Schaad for having done this work (and all the work that led up to making this work possible). The draft fills a gap where COSE is being used in conjunction with infrastructure employing X.509-based validation of keys. JOSE defined the necessary parameters right away, while the use case for COSE was less clear initially. One criticism might be that the draft does not speculate on how constrained devices could share tasks that need to be performed in this use case with trusted less-constrained devices -- there are probably infinite ways of doing so, and the ones actually to be used should rather be discussed in the protocols that govern the constrained--less-constrained communication. The draft is ready with issues. ## Major Section 1: The draft points to examples to be found in the github repository https://github.com/cose-wg/Examples -- these are not in there. Either these examples need to be added or this sentence deleted. ## Minor Section 2: I'm not sure what "certificates of a chain length of..." actually means -- the chain length is not an intrinsic property of a certificate, but a function of what the application's roots are. Maybe rephrase: These rules apply when the validation succeeds in a single step as well as when certificate chains need to be built. The draft uses the term "bag" for what is meant to be a set. Maybe stick with the "x5bag" parameter name and the prose "certificate bag", but when saying what it is, say that it is a set. ## Nits https://github.com/cose-wg/X509/pull/28 From nobody Mon Oct 19 18:15:30 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 A77B53A078F; Mon, 19 Oct 2020 18:15:25 -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 cQtLHpdSKF9J; Mon, 19 Oct 2020 18:15:24 -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 85B593A064A; Mon, 19 Oct 2020 18:15:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 61B4338995; Mon, 19 Oct 2020 21:21:32 -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 4SE-WkueOQYf; Mon, 19 Oct 2020 21:21:31 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D687038993; Mon, 19 Oct 2020 21:21:31 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D3EF1976; Mon, 19 Oct 2020 21:15:21 -0400 (EDT) From: Michael Richardson To: Carsten Bormann , iot-directorate@ietf.org, last-call@ietf.org, draft-ietf-cose-x509.all@ietf.org, cose@ietf.org In-Reply-To: <160314506078.20558.15385106097623388280@ietfa.amsl.com> References: <160314506078.20558.15385106097623388280@ietfa.amsl.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] [Last-Call] Iotdir telechat review of draft-ietf-cose-x509-07 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, 20 Oct 2020 01:15:26 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you for the timely review! Carsten Bormann via Datatracker wrote: > These rules apply when the validation succeeds in a single step as > well as when certificate chains need to be built. > The draft uses the term "bag" for what is meant to be a set. > Maybe stick with the "x5bag" parameter name and the prose "certificate > bag", but when saying what it is, say that it is a set. I believe we use the term bag because it is permissible for a certificate artifact to appear more than once. Stupid maybe, but permissible. I think that some systems/libaries considered the Issuer/Subject to be the key for indexing the set, and then they got confused if there was more than one certificate in the bag. The additional object used a different signatu= re and/or hash. At least, I have some dim memory of some situation being described to me. I think that the names of the guilty parties were withhel= d. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+OOikACgkQgItw+93Q 3WWziAgAkp7nnlqbaNs1nca8sonbYK/ja3UNuKir8Onxd6RV8XrTU7MWeRP83kRf 1i1GFa5xfMkCG7hjWeQKLSy3n3sFClxg+M1K2wlRxKimmJ0yrIUwbrlMFJNCJXRu nL3myVQZs49qak0DyPn4OnKqAo2m8lXtLdnmWDeSEitldxeL2aJARZqv970l2WaK i2FiGi+U66E7FhayUxKTEEW+cgU5Y8KFgXwUEDm6lFGM8uHdiPIsu0O5OtvpO9LU 8mV4iW2zhUy3P4w04ahkXRO2iPVbJqr3n97XY5OR5Ot3WoezmsBotiq+NrftRD0+ 2ZBwZ1yZRjF5CpkvxnH9tve7Hm7VeA== =R1Xo -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 19 22:28:58 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D583A0EE8 for ; Mon, 19 Oct 2020 22:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FteVBDr-gxjM for ; Mon, 19 Oct 2020 22:28:55 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 A9F783A0EDF for ; Mon, 19 Oct 2020 22:28:54 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id e17so486484wru.12 for ; Mon, 19 Oct 2020 22:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NXcFSoG3/RI9Y9fVQRqafs0DvA3FZKAMhMgPs/cNOiI=; b=Ijr0BwnbRnfBHcA8+nHbEzUBIEXccDHepKtTl7TXz5moVvaTKYgwjo+mIds11i6j88 L9RnYXki1PKA+M7ytf9yI4SG9IYjEjeZWaeX4qs2OAgq8B2CS04+OZ/jhzIXE+rkjbtQ E95fCACFCPQ3kXrXdJByb+F6ZyHtC2hiI8jQGYD1p9AKnLT+fFpb1VEVI53al2W8o9oc LrDV85Ar1XMVKhj82pk4hAC3sW6KyDpfVZZtC+TkGJVphq1o4sVOilBJTRkMEvIb7G15 om/4tvUx4JCrGCGLqIELHpAqPak3nUKx6YzwVz5qIn2FULCHaZ5O0eZPdtrvD8l6kzbc Si/w== 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=NXcFSoG3/RI9Y9fVQRqafs0DvA3FZKAMhMgPs/cNOiI=; b=pm0PC+fDp/cG0feWd0OmguhdXdp2u4bmUX6IDDuzFovTMIMdtan7875pPs4pRS5hTa lTXP9sF2Ykd/fOiw3zJpOrlPC1VQxZ8XA6TasX0oL3Q9PGjolKY3wihopANQe1+KbH3m xdZltjOEfzhCS5orCX82OPeGJVR2JiEN/EsuVK6aLEICj9vt476YePWatZVFQge053SQ 0IS7uUoR248i0AG7Afde7tJ0W0OjeNR7kVGre+Fa10nEJPOEhQd/+KbE9VaVHWgeUiX5 fEU724fYGsD7RMaU+L+A6C25wJpsLgbBL3iub8FqJfLxMHA5vmQQ53zFWE0F+a5fcrqi 0gBA== X-Gm-Message-State: AOAM531g+1YsV1UMT46FTjFjFkd7wEmhUqeFA3gAW/qTikfKHGRt8gCb nFSBe54DzoQ0u791yK2BdGBarvnN4Z9fsgetlvE1LA== X-Google-Smtp-Source: ABdhPJyqTuGf1spiIcJ3xJuy/+mY2stjZWYcYxE3u469I09ZDBacsArNnx2uNy9VpIXJBREZAmUBd7XyB6xtvr0gKiM= X-Received: by 2002:adf:81f4:: with SMTP id 107mr1289666wra.272.1603171732818; Mon, 19 Oct 2020 22:28:52 -0700 (PDT) MIME-Version: 1.0 References: <160313511018.7246.11234492090901667420@ietfa.amsl.com> In-Reply-To: <160313511018.7246.11234492090901667420@ietfa.amsl.com> From: Ivaylo Petrov Date: Tue, 20 Oct 2020 08:28:26 +0300 Message-ID: To: Robert Wilton Cc: The IESG , draft-ietf-cose-x509@ietf.org, Cose Chairs Wg , cose Content-Type: multipart/alternative; boundary="000000000000a6221705b213813c" Archived-At: Subject: Re: [COSE] Robert Wilton's No Objection on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 05:28:57 -0000 --000000000000a6221705b213813c Content-Type: text/plain; charset="UTF-8" Thank you Robert for your review! From this discussion [1] it appears that indeed the intention of the usage of the term bag was not to make any assumptions about the uniqueness of the elements. I am taking a note to make that clear in the document regardless of the conclusion of that discussion. [1]: https://mailarchive.ietf.org/arch/msg/cose/VLv2E6wcGkC4YY-vFMRxnEAXrXo/ -- Best regards, Ivaylo On Mon, Oct 19, 2020 at 10:18 PM Robert Wilton via Datatracker < noreply@ietf.org> wrote: > Robert Wilton has entered the following ballot position for > draft-ietf-cose-x509-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I would like to thank Jim Schaad for this document and all his other work > at > IETF. > > My only minor comment is that I was surprised by the name "x5bag", which in > computing terms I generally understand to be defined as a data structure > that > is like a set but it can contain duplicate values (also known as a > multiset). > It wasn't clear to me that was the intended purpose here, but I seem to > recall > that 'bag' might take a slightly different meaning in security circles? > Either > way, it might be helpful to specify both for the x5bag and x5chain whether > or > not duplicate certificates are allowed to be present. > > Regards, > Rob > > > > --000000000000a6221705b213813c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Robert for your review! From this discu= ssion [1] it appears that indeed the intention of the usage of the term bag= was not to make any assumptions about the uniqueness=C2=A0of the elements.= I am taking a note to make that clear in the document regardless of the co= nclusion of that discussion.

[1]:=C2=A0https://mailarchive.ietf.org/arch/msg/cose/VLv2E6wcGkC4YY-vFMRxnEAXrX= o/

--
Best regards,<= /div>
Ivaylo


On Mon, Oct 19, 2020 at 10:18 PM Robert Wilton via D= atatracker <noreply@ietf.org>= wrote:
Robert W= ilton has entered the following ballot position for
draft-ietf-cose-x509-07: No Objection

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


Please refer to https://www.ietf.org/iesg/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-ietf-co= se-x509/



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

I would like to thank Jim Schaad for this document and all his other work a= t
IETF.

My only minor comment is that I was surprised by the name "x5bag"= , which in
computing terms I generally understand to be defined as a data structure th= at
is like a set but it can contain duplicate values (also known as a multiset= ).
It wasn't clear to me that was the intended purpose here, but I seem to= recall
that 'bag' might take a slightly different meaning in security circ= les?=C2=A0 Either
way, it might be helpful to specify both for the x5bag and x5chain whether = or
not duplicate certificates are allowed to be present.

Regards,
Rob



--000000000000a6221705b213813c-- From nobody Mon Oct 19 22:31: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 E719F3A0EDB for ; Mon, 19 Oct 2020 22:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1U_bnXavk61 for ; Mon, 19 Oct 2020 22:31:04 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 B4ABD3A0ED7 for ; Mon, 19 Oct 2020 22:31:03 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id a72so412259wme.5 for ; Mon, 19 Oct 2020 22:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2TvG8RnwucFiBdjrDLmDR3IMsVtJshO4uH1VRPZpIH0=; b=kFaotto2wA1+1mHNM82LeiGWjSu/HweJYL4Djukd7hD4rAwcntTY54iIx8AgZGAp48 pDK5GPR5aVuf21ODCeqpYf/Xc8UtDE47OpMfv0CzXnwGfMF0an49hBTzwGSYSi++UyAd 87L3ZRzUfnFrhGv7HLZLSItRz8c9g1vaNtMRo3B8fC9tghTdMEnQwlaz/WRYQGJxl2WB h6Yt11XCJx+5GcgvBEddIEA16EDNbYCs3+ucyPJOSSMhyKpyrMWvu8eJparbFFwK2AiK EH9S0V3znTf2v6oS+pjQ4F8DGBwHd+nZEiZQdI38EVjbUN2YjmyeiWmTiGwTDE97G9SU wVww== 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=2TvG8RnwucFiBdjrDLmDR3IMsVtJshO4uH1VRPZpIH0=; b=lql74iQu5AuwWK3qZKyjlsSOpmPny0S4Dttv8In+o36OHzfV65cQIlCXPjUcXdOsgX E6ZG+W+m0SFSULezqXaRNOrBdYK08Xi+RztL0ItKdEZgPxk2w/p2XcaLd+qXyBmL9Tdn E16RqCrEkPEcEurdjjmYK7AwXcnIwassw7otklmZAqPJVoO8s8nzOCHfoDpTQdvkqG7z iz2B08zc8PTghyZeAYYcg8aRe5AiucqPAcZ2bxgjlAiW9wYi73RxnJDdVSXHWyVeeoca blmPUD6VZn2qRR6po9KqIFlM6kmC3U4I6Ae33cLdq8g9rxzV2yvzsgCsV4gYsnERyMtj dZlg== X-Gm-Message-State: AOAM530XCmTDWQnR3xsUmaJneIgJF4zmGpGWkMyb4e5fkDziu8AgwUs/ yP1pADurGLlQq/cFS+V/jX1VmLQoSDe/oQ8ZHnXoLS2g21NMWw== X-Google-Smtp-Source: ABdhPJwxfi343PLE0tX7BQZG6xTQ/tVN49acaJBS9uIqK3PHi7xh3vQxRV9KtsKNUR5JTKTOWzguSTXwfD3gJ5x0BL4= X-Received: by 2002:a1c:1f89:: with SMTP id f131mr990400wmf.10.1603171861944; Mon, 19 Oct 2020 22:31:01 -0700 (PDT) MIME-Version: 1.0 References: <9284FE68-45D9-4282-8526-78914C3E3043@island-resort.com> <45E59EC6-AC14-4477-8BB0-10053BFD1C39@island-resort.com> In-Reply-To: <45E59EC6-AC14-4477-8BB0-10053BFD1C39@island-resort.com> From: Ivaylo Petrov Date: Tue, 20 Oct 2020 08:30:35 +0300 Message-ID: To: Laurence Lundblade Cc: cose Content-Type: multipart/alternative; boundary="000000000000586d8605b21389e2" Archived-At: Subject: Re: [COSE] draft-ietf-cose-x509-07 examples 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, 20 Oct 2020 05:31:07 -0000 --000000000000586d8605b21389e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Laurence for reporting this! If nobody is able to provide examples (validated with running code if possible), I intend to remove this paragraph. Best regards, Ivaylo On Mon, Oct 19, 2020 at 10:11 PM Laurence Lundblade wrote: > draft-ietf-cose-x509-07 says: > > Example COSE messages for the various header parameters defined below > can be found at https://github.com/cose-wg/Examples. > > > > When I looked, I couldn=E2=80=99t find any (to help me answer other quest= ions > posted here). I grepped through all the JSON for 509, x5bag, x5u=E2=80=A6= and got > no hits. > > LL > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --000000000000586d8605b21389e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Laurence for reporting this! If nobody = is able to provide examples (validated with running code if possible), I in= tend to remove this paragraph.

Best regard= s,
Ivaylo
<= div dir=3D"ltr">
=


On Mon, Oct 19, 2020 at 10:11 PM Laurence Lundblade <lgl@island-resort.com> wrote:
<= /div>
draft-ietf-cose-x509-07 says:

   Ex=
ample COSE messages for the various header parameters defined below
   can be found at https://github.com/cose-wg/Examples.

When I looked, I couldn=E2=80=99t find any (to help me answer other = questions posted here). I grepped through all the JSON for 509, x5bag, x5u= =E2=80=A6 and got no hits.

LL
_________= ______________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose
--000000000000586d8605b21389e2-- From nobody Mon Oct 19 23:58: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 8F8E53A1131; Mon, 19 Oct 2020 23:58: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 oUQmneiiRYuy; Mon, 19 Oct 2020 23:58:20 -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 3E5573A112F; Mon, 19 Oct 2020 23:58:18 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4CFkwm0wqczydL; Tue, 20 Oct 2020 08:58:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <0ABC7267-6534-44CD-9ACA-E4F568CD07AE@island-resort.com> Date: Tue, 20 Oct 2020 08:58:15 +0200 Cc: Michael Richardson , draft-ietf-cose-x509@ietf.org, Cose Chairs Wg , The IESG , cose , Martin Duke , Ivaylo Petrov X-Mao-Original-Outgoing-Id: 624869895.334186-7def3ebe270e3cb0b8e0b9e44c742b04 Content-Transfer-Encoding: quoted-printable Message-Id: References: <160209160818.12838.15929178240331409569@ietfa.amsl.com> <21362.1602538323@localhost> <0ABC7267-6534-44CD-9ACA-E4F568CD07AE@island-resort.com> To: Laurence Lundblade X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [COSE] Martin Duke's No Objection on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 06:58:23 -0000 On 2020-10-19, at 19:45, Laurence Lundblade = wrote: >=20 > It is the requirements and design of the end-end system that = determines what the constrained device has to do or not do, not the = design of these headers. Probably it is an overreach to discuss end-end = system designs. Maybe it is just better to remove this paragraph? The constrained device can delegate most of its tasks (=E2=80=9Cwhat is = has to do=E2=80=9D) to a (sufficiently trusted) less-constrained one = (the only tasks that it cannot delegate are the ones needed to properly = establish and maintain trust into that device and the communication with = it). The paragraph mostly serves as a reminder of how the task delegation = pattern can alleviate the concerns that led to the original COSE not = having X.509-related primitives. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Oct 20 03:25: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 F324A3A1125; Tue, 20 Oct 2020 03:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=VcdOFs6y; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=yb3+xVlh 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 yR62pYYZfPUn; Tue, 20 Oct 2020 03:25:16 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FCE3A1124; Tue, 20 Oct 2020 03:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3584; q=dns/txt; s=iport; t=1603189515; x=1604399115; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sJEFEn8ciKXrkcxvPtnMxcae5yj13bOUi5vmDLXo94w=; b=VcdOFs6yvGPAQbURffivQMlITOHtmKfbhRw215DV+UpaZgcsDtccf5I9 RBHugbo2wPrM8Ig+eWWi1qlckQTv0noybz/K8AdelV0+Y9DHw/JgDh47y Cwz3tvNE2zPxvIUCb+WyLwDe+usKfbz6Jm0X2l6ShSpLZ/1b+oic9dQP0 g=; IronPort-PHdr: =?us-ascii?q?9a23=3AmqylEhNUBB/760b3KUYl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw13kPbXMPc8f0Xw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoLVpUXsHkaA6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtEQCauo5f/4kNJK1gHQI9BQUECRa?= =?us-ascii?q?BUYFQIy4HcFkvLIQ9g0kDjVOYeoFCgREDVQsBAQENAQEYCwoCBAEBhEoCF4F?= =?us-ascii?q?uAiU4EwIDAQELAQEFAQEBAgEGBG2FYQyFcgEBAQEDAQEQEREMAQEsCwELBAI?= =?us-ascii?q?BCA4DAwECAwImAgICJQsUAQgIAgQBDQUigwQBgksDLgEOpDICgTmIaHaBMoM?= =?us-ascii?q?EAQEFgTMBg3QYghADBoEOKgGCcYNwhlYbgUE/gREnHIJNPoJcAQGBIT6DFzO?= =?us-ascii?q?CLJNUhzeceQqCaokEjGeFCQMfoVqTOYp0lUACBAIEBQIOAQEFgWsjgVdwFTs?= =?us-ascii?q?qAYI+UBcCDZIQhRSFQnQ4AgYBCQEBAwl8iwgtgThfAQE?= X-IronPort-AV: E=Sophos;i="5.77,396,1596499200"; d="scan'208";a="567280096" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Oct 2020 10:25:14 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 09KAPEGG019089 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2020 10:25:14 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 20 Oct 2020 05:25:14 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 20 Oct 2020 05:25:13 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 20 Oct 2020 06:25:13 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hF1XhV5uB0TOs+72K5Y0T7EeJ9UjzaJuMDO18ces/a3HR+pf3wwUHOxKIXZcP9c64mv/HMF4ahlcrTc/KFiaK3iBINCReLGxeXi0zh0WUa8fK32mzIeUp50R5kGdlSwNFVE0AEJ5gwmWw39l7HE7FT/Uazbc284g6Lj6RFjlbL8pwd+PFudP/2M4rE1vns3VhTe4WT+1bZgaHXUdWeaXK2lZ3JKCApp8ppL2Y0P8cOFD1Hw5KlPNCpwSZRfnnr1pRbR+fFMRTOnL07JJQ6HKqAYFd1aGaPKr74d4Oz6xwfV54GtUxEZHZflk+MBlzdDIcB4uVqDbtfW/Y5hlF90puw== 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=sJEFEn8ciKXrkcxvPtnMxcae5yj13bOUi5vmDLXo94w=; b=GfjeFU9gB9JlE6SQMGbqP8HeZiWKhAAwt7XherOWnQDhbG9hPtXnj1pda2yqPYqxVtMPj7+6a3Fuyxv9oc83FWGp2llUzLlm8wd7CdZzjT6sRoG89M5TLieR1ptmxJr3IJBQuN13iT3Q5KJSH3Vg46GCibNwlaaLSYsFglpqyC/6xOwKtIfniqiubKuA+hBiJNZ/lZ1lk5pbhFRbxcuiPvNWdFoeEbxad4LdMRZ/ad0OVf7ta9qrb7CtRe3Rcan69ZP8m53DNiTpO4OXsqYcXi45Xd0btPIg90sFN7AvNqir3F6/W0P6g/6wO/V8W1SVA25WW0FoTub7yPFPMSxRyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sJEFEn8ciKXrkcxvPtnMxcae5yj13bOUi5vmDLXo94w=; b=yb3+xVlhzdczd0r4xHfTq6GKITnlFQokkXHaPzVQQeTGeWi3FTSbXXGnaDZYOhBAvSnOBgYtO+NoaW2LHztqI8uDAUXXikOpT/xzf0sHJDBWEqyAt8TjRoycylLlGT5gEnw8p1ychUstX+vB/G3Foacue6T6wmUOhwzMvdbqjrc= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4856.namprd11.prod.outlook.com (2603:10b6:510:32::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Tue, 20 Oct 2020 10:25:12 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::453b:b2f5:ec29:410d]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::453b:b2f5:ec29:410d%7]) with mapi id 15.20.3499.018; Tue, 20 Oct 2020 10:25:12 +0000 From: "Eric Vyncke (evyncke)" To: Carsten Bormann , "iot-directorate@ietf.org" CC: "last-call@ietf.org" , "draft-ietf-cose-x509.all@ietf.org" , "cose@ietf.org" Thread-Topic: [Last-Call] Iotdir telechat review of draft-ietf-cose-x509-07 Thread-Index: AQHWpmPphFA5p0Q7Yk6BgsHMwp9XLamga1OA Date: Tue, 20 Oct 2020 10:25:12 +0000 Message-ID: <2628B079-990B-4B10-A4A2-EE1595D7946E@cisco.com> References: <160314506078.20558.15385106097623388280@ietfa.amsl.com> In-Reply-To: <160314506078.20558.15385106097623388280@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:e92e:ce7c:f781:8d9b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0a21ba32-d851-422e-9e02-08d874e26df1 x-ms-traffictypediagnostic: PH0PR11MB4856: 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: XSWCDMr5N1auoAIUbV/lydUbrj8n/oUAJdWtyDQT4C7RgAWIB77c9lEYmXTsvFCmLLirtD8i0jI+6Op3Ra8AWae0l+YEaqI9SkZ+hVpYxyyUlnKy/yYyR1/ZNO1uYKVYVpXeupPbw1WUWBOieYP4KPfw3PNBeMAtQijsGIQ/fGmWv57nmFnA3XwHQ1xFE3TEz1dm2IRV4oRbOCZWNYngFcOWBGc9QnsXf5L56OBaRps+tcFFbVNvuUjXa0hEcFf43K5v+cCtqljbjxY3GKSjSc074IszNwSyekdpjYC40SeKkvsgIheuW4pd3CXxmHB4Xy1MHa18clmlEuxPyTzLSZZ02A6H92BmJDGKKaVF+E/MMFIv1wiInr37W4o0YFBq58FxtuA9fC/bJnzrUVS8zw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(396003)(376002)(346002)(136003)(4326008)(2616005)(33656002)(83380400001)(966005)(71200400001)(478600001)(6486002)(53546011)(6506007)(316002)(110136005)(8936002)(5660300002)(6512007)(36756003)(8676002)(186003)(54906003)(64756008)(66556008)(66476007)(91956017)(86362001)(76116006)(66446008)(66946007)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: iAXN78uleOcJNBzo4/R6aResndq6xhbWvyO9fvczb43AYUVzgUtbYqs4sTBM4XCjqEmXcBmhGvDj8RWGtv7MDyx6uQQJ1LZiKPNX+J7dwvF10DWMsHvHIuF3vpVCR6lhc6tMNx037L1Zb/LdRs13jdd5b+gNHDI5NRT4kpdm/evzIWi9Smvr90k0JXcEO3kdiEhYHWp2yef4vO8DbKKyjYQWkvIBLWBGyyeqDafhaqu3lYnwUNpORl862TDxiaO5HSahNObocr0Y+4NHELl60YD/QvkAquHM/7ibCiBKI8kKWQ5jUvNPvR7PxwmjVrranuHC9A8M4JD+qSv0/W9Nbq6n3Kvgf7F+pmxMt0Ap3FzCQz6c8ZwnhQeEeAGZModcU2e2ncnuD/qEtFSLjLCreV6EveA59jzOjF05zjwPNd89CRLX0JTJRbNZFlG8hIz7/J0iy0WdwQqK/E/SyO0ZaqObNnDEQcBfeDoUYFW02JTv75NmxQemCZb/dsF2kNqEWN7dii32YiXaJ5M6KUcjp6vS7/8EyEBVlTGDFxd6xuohXgCsGknqwC96G0YX/mb1YhC+5irewNoRWbXBwaUIt4DI0lGlIz+cclOZZmvdDLYe5FQgvGiFAfSBONUqSOkw1fwpdxaKnlolX2p6kdz82pqplY5a39RKtoqplDTnzgXHB1leFMWP4o5ik28s1GrSuT+So4InqxrMO1eAtBH/MQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <8CE4F7765481074BB1B612570FACF577@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0a21ba32-d851-422e-9e02-08d874e26df1 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2020 10:25:12.6089 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: J3N4u3FODquBSbcXvrbkvgqVsyBdWVjOq7fSDJETzezb6CDug5thnACMD2eguas2+UNItG6RaDbvaJgL3yxcDg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4856 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [COSE] [Last-Call] Iotdir telechat review of draft-ietf-cose-x509-07 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, 20 Oct 2020 10:25:18 -0000 VGhhbmsgeW91IENhcnN0ZW4gZm9yIHRoaXMgcmV2aWV3IG9mIGluZGVlZCBhIHZlcnkgc3BlY2lh bCBJLUQuDQoNCkkgaGF2ZSB1c2VkIHlvdXIgSW9UIGRpcmVjdG9yYXRlIHJldmlldyB0byBlbnRl ciBteSBiYWxsb3QuDQoNClJlZ2FyZHMNCg0KLcOpcmljDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBsYXN0LWNhbGwgPGxhc3QtY2FsbC1ib3VuY2VzQGlldGYub3JnPiBv biBiZWhhbGYgb2YgQ2Fyc3RlbiBCb3JtYW5uIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRm Lm9yZz4NClJlcGx5LVRvOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4NCkRhdGU6IFR1 ZXNkYXksIDIwIE9jdG9iZXIgMjAyMCBhdCAwMDowNQ0KVG86ICJpb3QtZGlyZWN0b3JhdGVAaWV0 Zi5vcmciIDxpb3QtZGlyZWN0b3JhdGVAaWV0Zi5vcmc+DQpDYzogImxhc3QtY2FsbEBpZXRmLm9y ZyIgPGxhc3QtY2FsbEBpZXRmLm9yZz4sICJkcmFmdC1pZXRmLWNvc2UteDUwOS5hbGxAaWV0Zi5v cmciIDxkcmFmdC1pZXRmLWNvc2UteDUwOS5hbGxAaWV0Zi5vcmc+LCAiY29zZUBpZXRmLm9yZyIg PGNvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbTGFzdC1DYWxsXSBJb3RkaXIgdGVsZWNoYXQgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtY29zZS14NTA5LTA3DQoNCiAgICBSZXZpZXdlcjogQ2Fyc3RlbiBC b3JtYW5uDQogICAgUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBJc3N1ZXMNCg0KDQogICAgRmly c3QsIEkgd291bGQgbGlrZSB0byBleHByZXNzIG15IGdyYXRpdHVkZSB0byBKaW0gU2NoYWFkIGZv ciBoYXZpbmcNCiAgICBkb25lIHRoaXMgd29yayAoYW5kIGFsbCB0aGUgd29yayB0aGF0IGxlZCB1 cCB0byBtYWtpbmcgdGhpcyB3b3JrDQogICAgcG9zc2libGUpLg0KDQogICAgVGhlIGRyYWZ0IGZp bGxzIGEgZ2FwIHdoZXJlIENPU0UgaXMgYmVpbmcgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoDQog ICAgaW5mcmFzdHJ1Y3R1cmUgZW1wbG95aW5nIFguNTA5LWJhc2VkIHZhbGlkYXRpb24gb2Yga2V5 cy4gIEpPU0UgZGVmaW5lZA0KICAgIHRoZSBuZWNlc3NhcnkgcGFyYW1ldGVycyByaWdodCBhd2F5 LCB3aGlsZSB0aGUgdXNlIGNhc2UgZm9yIENPU0Ugd2FzDQogICAgbGVzcyBjbGVhciBpbml0aWFs bHkuDQoNCiAgICBPbmUgY3JpdGljaXNtIG1pZ2h0IGJlIHRoYXQgdGhlIGRyYWZ0IGRvZXMgbm90 IHNwZWN1bGF0ZSBvbiBob3cNCiAgICBjb25zdHJhaW5lZCBkZXZpY2VzIGNvdWxkIHNoYXJlIHRh c2tzIHRoYXQgbmVlZCB0byBiZSBwZXJmb3JtZWQgaW4NCiAgICB0aGlzIHVzZSBjYXNlIHdpdGgg dHJ1c3RlZCBsZXNzLWNvbnN0cmFpbmVkIGRldmljZXMgLS0gdGhlcmUgYXJlDQogICAgcHJvYmFi bHkgaW5maW5pdGUgd2F5cyBvZiBkb2luZyBzbywgYW5kIHRoZSBvbmVzIGFjdHVhbGx5IHRvIGJl IHVzZWQNCiAgICBzaG91bGQgcmF0aGVyIGJlIGRpc2N1c3NlZCBpbiB0aGUgcHJvdG9jb2xzIHRo YXQgZ292ZXJuIHRoZQ0KICAgIGNvbnN0cmFpbmVkLS1sZXNzLWNvbnN0cmFpbmVkIGNvbW11bmlj YXRpb24uDQoNCiAgICBUaGUgZHJhZnQgaXMgcmVhZHkgd2l0aCBpc3N1ZXMuDQoNCiAgICAjIyBN YWpvcg0KDQogICAgU2VjdGlvbiAxOg0KDQogICAgVGhlIGRyYWZ0IHBvaW50cyB0byBleGFtcGxl cyB0byBiZSBmb3VuZCBpbiB0aGUgZ2l0aHViIHJlcG9zaXRvcnkNCiAgICBodHRwczovL2dpdGh1 Yi5jb20vY29zZS13Zy9FeGFtcGxlcyAtLSB0aGVzZSBhcmUgbm90IGluIHRoZXJlLg0KICAgIEVp dGhlciB0aGVzZSBleGFtcGxlcyBuZWVkIHRvIGJlIGFkZGVkIG9yIHRoaXMgc2VudGVuY2UgZGVs ZXRlZC4NCg0KICAgICMjIE1pbm9yDQoNCiAgICBTZWN0aW9uIDI6DQoNCiAgICBJJ20gbm90IHN1 cmUgd2hhdCAiY2VydGlmaWNhdGVzIG9mIGEgY2hhaW4gbGVuZ3RoIG9mLi4uIiBhY3R1YWxseQ0K ICAgIG1lYW5zIC0tIHRoZSBjaGFpbiBsZW5ndGggaXMgbm90IGFuIGludHJpbnNpYyBwcm9wZXJ0 eSBvZiBhDQogICAgY2VydGlmaWNhdGUsIGJ1dCBhIGZ1bmN0aW9uIG9mIHdoYXQgdGhlIGFwcGxp Y2F0aW9uJ3Mgcm9vdHMgYXJlLg0KICAgIE1heWJlIHJlcGhyYXNlOg0KDQogICAgICAgVGhlc2Ug cnVsZXMgYXBwbHkgd2hlbiB0aGUgdmFsaWRhdGlvbiBzdWNjZWVkcyBpbiBhIHNpbmdsZSBzdGVw IGFzDQogICAgICAgd2VsbCBhcyB3aGVuIGNlcnRpZmljYXRlIGNoYWlucyBuZWVkIHRvIGJlIGJ1 aWx0Lg0KDQogICAgVGhlIGRyYWZ0IHVzZXMgdGhlIHRlcm0gImJhZyIgZm9yIHdoYXQgaXMgbWVh bnQgdG8gYmUgYSBzZXQuDQogICAgTWF5YmUgc3RpY2sgd2l0aCB0aGUgIng1YmFnIiBwYXJhbWV0 ZXIgbmFtZSBhbmQgdGhlIHByb3NlICJjZXJ0aWZpY2F0ZQ0KICAgIGJhZyIsIGJ1dCB3aGVuIHNh eWluZyB3aGF0IGl0IGlzLCBzYXkgdGhhdCBpdCBpcyBhIHNldC4NCg0KICAgICMjIE5pdHMNCg0K ICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3NlLXdnL1g1MDkvcHVsbC8yOA0KDQoNCg0KICAgIC0t IA0KICAgIGxhc3QtY2FsbCBtYWlsaW5nIGxpc3QNCiAgICBsYXN0LWNhbGxAaWV0Zi5vcmcNCiAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xhc3QtY2FsbA0KDQo= From nobody Tue Oct 20 03:25: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 D3DBA3A118B; Tue, 20 Oct 2020 03:25:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-cose-x509@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov , ivaylo@ackl.io, iot-directorate@ietf.org, cabo@tzi.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <160318952584.30404.16477513681210675311@ietfa.amsl.com> Date: Tue, 20 Oct 2020 03:25:25 -0700 Archived-At: Subject: [COSE] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-cose-x509-07=3A_=28with_COMMENT=29?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 10:25:32 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-cose-x509-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Strange feeling to review this Jim Schaad's document... Thank you Carsten for the IoT directorate review at: https://datatracker.ietf.org/doc/review-ietf-cose-x509-07-iotdir-telechat-bormann-2020-10-19/ The major issue found by Carsten (missing files in the github repo) should be resolved before publication. -éric From nobody Tue Oct 20 04:43: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 06C3A3A11A6; Tue, 20 Oct 2020 04:43:01 -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 084a0y64CW84; Tue, 20 Oct 2020 04:42:59 -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 8F4F33A11A9; Tue, 20 Oct 2020 04:42:56 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4CFsFB02Vmz1085; Tue, 20 Oct 2020 13:42:53 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <26102.1603156521@localhost> Date: Tue, 20 Oct 2020 13:42:53 +0200 Cc: iot-directorate@ietf.org, last-call@ietf.org, draft-ietf-cose-x509.all@ietf.org, cose@ietf.org X-Mao-Original-Outgoing-Id: 624886973.291835-f071e35de32d14c1f93b613a494a4fec Content-Transfer-Encoding: quoted-printable Message-Id: <38B4F6C0-6F7E-46DF-A1B7-24D6E83BFE92@tzi.org> References: <160314506078.20558.15385106097623388280@ietfa.amsl.com> <26102.1603156521@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [COSE] [Last-Call] Iotdir telechat review of draft-ietf-cose-x509-07 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, 20 Oct 2020 11:43:01 -0000 On 2020-10-20, at 03:15, Michael Richardson = wrote: >=20 > I believe we use the term bag because it is permissible for a = certificate > artifact to appear more than once. Stupid maybe, but permissible. >=20 > I think that some systems/libaries considered the Issuer/Subject to be = the > key for indexing the set, and then they got confused if there was more = than > one certificate in the bag. The additional object used a different = signature > and/or hash. At least, I have some dim memory of some situation being > described to me. I think that the names of the guilty parties were = withheld. I think we have a different perception of what =E2=80=9Cis=E2=80=9D = means. In my shopping bag, there *is* a difference between having one or two = yoghurts in there. In the x5bag, having the same certificate twice is exactly equivalent to = having it once. So it =E2=80=9Cis=E2=80=9D a (non-empty) set, not a bag, even if the = *representation* (as an array, with a special case for the singleton) = can actually have duplicates. Given the semantics, the question how one =E2=80=9Cfinds=E2=80=9D things = in that set is more of an implementation question. I don=E2=80=99t = think offering this as a multimap(*) with some arbitrarily chosen map = key is flexible enough. Normally, a simple iterator (so you get to see = any and all of the elements) will be the best solution, because the = implementation cannot know what the application-specific validation = process is looking for, and we are talking about a very small set. Gr=C3=BC=C3=9Fe, Carsten (*) Cannot be a map, as there is no guarantee of uniqueness of any key. From nobody Tue Oct 20 10:05: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 3D3383A12F8 for ; Tue, 20 Oct 2020 10:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 GXJiSnXFwo9O for ; Tue, 20 Oct 2020 10:05:38 -0700 (PDT) Received: from p3plsmtpa06-09.prod.phx3.secureserver.net (p3plsmtpa06-09.prod.phx3.secureserver.net [173.201.192.110]) (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 9F1943A1260 for ; Tue, 20 Oct 2020 10:05:31 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id Uv4kkrfHTZTOlUv4lkrdR7; Tue, 20 Oct 2020 10:05:31 -0700 X-CMAE-Analysis: v=2.3 cv=e554tph/ c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=gKmFwSsBAAAA:8 a=K6EGIJCdAAAA:8 a=E9yZJvomF8DtYBYUiLsA:9 a=QEXdDO2ut3YA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=L6pVIi0Kn1GYQfi8-iRI:22 X-SECURESERVER-ACCT: lgl@island-resort.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Laurence Lundblade In-Reply-To: Date: Tue, 20 Oct 2020 10:05:30 -0700 Cc: draft-ietf-cose-x509@ietf.org, Michael Richardson , Cose Chairs Wg , The IESG , Ivaylo Petrov , Martin Duke , cose Content-Transfer-Encoding: quoted-printable Message-Id: <72B2AEEB-D6D0-4E59-A3DE-CCEF015A0B47@island-resort.com> References: <160209160818.12838.15929178240331409569@ietfa.amsl.com> <21362.1602538323@localhost> <0ABC7267-6534-44CD-9ACA-E4F568CD07AE@island-resort.com> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4wfGjGLPRs3jIAVb1Fxv0uYlSZ+iUAOunfwL+zNQA27XR992Bf/eV/BJudzgHNKVeB7G7kHYDCXCAJ+DCF12hMv81esu/R1rBhdMJWZ7UT1SJuMcl4Dt0B Edpyxf8JAOTM2CMjC5WNRxsxb4MlBurS0OfHQqTSD3C60atTBLxiffUge3jh/ygAxmUVKoYYuPJ87U0gIZ0QnrKgx/fWLFOGr9cJuIMITt5BoCpU2XPkJ7l8 VF1rh9djFrf4CUVXa7a8EFaTYCY1P3FYmMNujsyU9JMtlJGEz5grlF2l3HVQrDexsIeYkfTi7DotkMFalvtL+7+2aSW8qsfb8tHgBJWWYdCHYJIK8MzmJhrv G7KJXI0oOdlOg6z7iEZz/eFKhSOLgA== Archived-At: Subject: Re: [COSE] Martin Duke's No Objection on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 17:05:45 -0000 > On Oct 19, 2020, at 11:58 PM, Carsten Bormann wrote: >=20 > On 2020-10-19, at 19:45, Laurence Lundblade = wrote: >>=20 >> It is the requirements and design of the end-end system that = determines what the constrained device has to do or not do, not the = design of these headers. Probably it is an overreach to discuss end-end = system designs. Maybe it is just better to remove this paragraph? >=20 > The constrained device can delegate most of its tasks (=E2=80=9Cwhat = is has to do=E2=80=9D) to a (sufficiently trusted) less-constrained one = (the only tasks that it cannot delegate are the ones needed to properly = establish and maintain trust into that device and the communication with = it). > The paragraph mostly serves as a reminder of how the task delegation = pattern can alleviate the concerns that led to the original COSE not = having X.509-related primitives. Hi Cartsen, As someone who is not involved in Ace and some of the other work on = constrained devices, with this explanation, the paragraph seems more out = of place and misleading . - It doesn=E2=80=99t inform or provide needed background info as to = usage and design of cose-x509 (delegation issues are the same and even = more important for regular x.509). - It doesn=E2=80=99t say anything about delegation to a cloud or such, = so it=E2=80=99s unclear what it is talking about - Maybe it reminds some people that already know about architecture for = delegation chain validation; not sure reminders for those in the know = are useful - The security considerations section for delegation of chain validation = would be substantial All that said, I don=E2=80=99t think the paragraph is so awful it I = would say it must be deleted, but think the document would be better if = it was (or it was expanded and moved to an appendix, or better yet some = constrained device architecture / cook book document). LL From nobody Tue Oct 20 10:23: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 3CB2E3A11BC for ; Tue, 20 Oct 2020 10:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 AJtbPd-wcd3K for ; Tue, 20 Oct 2020 10:23:12 -0700 (PDT) Received: from p3plsmtpa06-09.prod.phx3.secureserver.net (p3plsmtpa06-09.prod.phx3.secureserver.net [173.201.192.110]) (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 A16D83A11CA for ; Tue, 20 Oct 2020 10:23:01 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id UvLgkrn1tZTOlUvLgkrfuT; Tue, 20 Oct 2020 10:23:01 -0700 X-CMAE-Analysis: v=2.3 cv=e554tph/ c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=NeJZvmmVAAAA:20 a=pJJpBa5sSAg-iv3uvRYA:9 a=QEXdDO2ut3YA:10 a=0_fjHHoAbSm6SUXqyqkA:9 a=OW_qF-YvgNLjO4MK:21 a=_W_S_7VecoQA:10 a=WQnItmPV2fbdzLaCP6-h:22 a=sGdjRKYcF6ZcXPNQMhXj:22 a=p-dnK0njbqwfn1k4-x12:22 a=qxG4R2aHmpcNjmqRPJKJ:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_6C553ABE-14B5-451E-BA52-9DD1BE2B8D34" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Tue, 20 Oct 2020 10:23:00 -0700 References: <9284FE68-45D9-4282-8526-78914C3E3043@island-resort.com> To: cose In-Reply-To: <9284FE68-45D9-4282-8526-78914C3E3043@island-resort.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4wfDtYUfTHRUpIblo4xtVhJigb03wekng2Q+mJPetYW23S/hYUhIYzSEnBUVCnO8NiADIIg3nzFgGug0/bnl8v1bhiBXPNZLFlYFntowHj0lT5dnxKFH+p q06h/ohiDoiw4Ts7qBOJfpxwhOWnnaTfUdUzQRUUm95sLs+s12gMDzQc Archived-At: Subject: [COSE] draft-ietf-cose-x509-07 open GitHub issues, PEM, DER and x5t parameter 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, 20 Oct 2020 17:23:15 -0000 --Apple-Mail=_6C553ABE-14B5-451E-BA52-9DD1BE2B8D34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I went through my open GitHub issues on cose-x509 = and closed a few, but a few = remain. The comments on the issue diverged from their titles, but still = seem valuable. They come down to two things. 1) There is agreement that only certs in the DER format is allowed. = However, cose-x509-07 doesn=E2=80=99t seem to say that. 2) Confusion over the x5t parameter. I think it is to identify the = end-entity cert in an x5bag or out of a collection fetched by URI or a = collection the relying party already has, but I=E2=80=99m not sure from = the text. (Maybe it is just my misunderstanding or misreading = something). LL --Apple-Mail=_6C553ABE-14B5-451E-BA52-9DD1BE2B8D34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = went through my open GitHub issues on cose-x509 and closed a few, = but a few remain.  The comments on the issue diverged from their = titles, but still seem valuable. They come down to two things.

1) There is agreement = that only certs in the DER format is allowed. However, cose-x509-07 = doesn=E2=80=99t seem to say that.

2) Confusion over the x5t parameter. I = think it is to identify the end-entity cert in an x5bag or out of a = collection fetched by URI or a collection the relying party already has, = but I=E2=80=99m not sure from the text. (Maybe it is just my = misunderstanding or misreading something).

LL

= --Apple-Mail=_6C553ABE-14B5-451E-BA52-9DD1BE2B8D34-- From nobody Tue Oct 20 19:58:13 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 008333A0ADF; Tue, 20 Oct 2020 19:58:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-cose-x509@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov , ivaylo@ackl.io X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <160324908697.22038.2714972412110979523@ietfa.amsl.com> Date: Tue, 20 Oct 2020 19:58:06 -0700 Archived-At: Subject: [COSE] Roman Danyliw's Discuss on draft-ietf-cose-x509-07: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 02:58:07 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-cose-x509-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 2. Where is the uri (CCDL) syntax/format/data type (used by x5u and x5u-sender) defined? Is this covered by CBOR tag=32? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would like to recognize Jim Schaad’s tremendous contribution to the IETF as author, implementer, mentor and leader. Thank you to the Charlie Kaufman for the SECDIR review. This review proposes and poses a few places where clarifying text would be helpful. Please respond to it. ** Section 1. Per the github pointer with examples: -- please add this url as a reference, not an inline url -- which exact set of references are relevant to this draft? It isn’t clear how this collection of examples applies. ** Section 2. Recommend precision on the string vs. integer algorithm identifier. OLD The first element is an algorithm identifier which is an integer or a string containing the hash algorithm identifier. The algorithm is registered in the "COSE Algorithms" registry NEW The first element is an algorithm identifier which is an integer or a string containing the hash algorithm identifier corresponding to either the Value (integer) or Name (string) column of the algorithm registered in the "COSE Algorithms" registry. ** Table 1. To line up with the column names of COSE Headers Parameters registry with this table, s/Type/Value Type/ ** Section 5. Recommend pointing to Section 7 of RFC3986 to cover security considerations of URI. ** Section 5. Per “On the other hand, an oracle can potentially be built based on detecting the network resources which is only done if the signature validation passes.”, I didn’t follow what this means. ** Editorial Nits -- Section 1. Editorial. Multiple typos. OLD In the process of writing [RFC8152] the working group discussed X.509 certificates [RFC5280] ad decided that no use cases wher prestented that showed a need to support certificates NEW In the process of writing [RFC8152], the working group discussed X.509 certificates [RFC5280] and found that that no use cases were presented that showed a need to support certificates -- Section 1. Editorial. OLD for example, in the 6TiSCH environment [I-D.richardson-enrollment-roadmap], describes a device enrollment solution that relies on the presence in the device of a factory-installed certificate. NEW for example, in the 6TiSCH environment, [I-D.richardson-enrollment-roadmap] describes a device enrollment solution that relies on the presence of a factory-installed certificate on the device. -- Section 2. Editorial. s/be configured use a/be configured to us a/ -- Section 2. There appears to be a missing transition from describing x5u and Table 1 which applies to all the preceding text. From nobody Wed Oct 21 00:06: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 3D3213A1172; Wed, 21 Oct 2020 00:06:13 -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 HXNS0zsqrQgr; Wed, 21 Oct 2020 00:06:10 -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 CDEF23A1170; Wed, 21 Oct 2020 00:06:08 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4CGM3L5X8Jzyvd; Wed, 21 Oct 2020 09:06:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <160324908697.22038.2714972412110979523@ietfa.amsl.com> Date: Wed, 21 Oct 2020 09:06:06 +0200 Cc: The IESG , cose-chairs@ietf.org, ivaylo@ackl.io, draft-ietf-cose-x509@ietf.org, cose@ietf.org X-Mao-Original-Outgoing-Id: 624956766.21259-14de5989b325132123266d8d88b57c96 Content-Transfer-Encoding: quoted-printable Message-Id: <7A27731F-1C04-4542-B2AC-2A46F2DEF4E7@tzi.org> References: <160324908697.22038.2714972412110979523@ietfa.amsl.com> To: Roman Danyliw X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [COSE] Roman Danyliw's Discuss on draft-ietf-cose-x509-07: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 07:06:13 -0000 On 2020-10-21, at 04:58, Roman Danyliw via Datatracker = wrote: >=20 > Section 2. Where is the uri (CCDL) syntax/format/data type (used by = x5u and > x5u-sender) defined? =20 The draft references RFC 3986. It could be more explicit in saying that the URI as defined in RFC 3986 = is represented as a CBOR text string; it is indeed unfortunate that the = tables use the term =E2=80=9Curi=E2=80=9D which is the name given by RFC = 8610 Appendix D to the CDDL prelude type for Tag 32 (uri =3D = #6.32(tstr)). > Is this covered by CBOR tag=3D32? Tag 32 would be a way to mark the text string as a URI at the CBOR level = (the definitions of Tag 32 in RFC 7049 as well as = draft-ietf-cbor-7049bis both also reference RFC 3986). However, the addition of the tag is not needed here, as the labeled = parameter (x5u/x5u-sender) already provides the URI semantics. (One convention to signify the use of an unadorned text string with URI = semantics in CDDL would be =E2=80=9C~uri=E2=80=9D.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Oct 21 05:14:11 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 30B9D3A0944; Wed, 21 Oct 2020 05:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFt3NTEqXhQ9; Wed, 21 Oct 2020 05:14:07 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3AF03A0948; Wed, 21 Oct 2020 05:14:06 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09LCE3rZ007414; Wed, 21 Oct 2020 08:14:03 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 09LCE3rZ007414 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1603282443; bh=C8/+/qzwl3B+QpZ3epPPogQuws2iVw7iqlPq+CHfHnE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=rH4ZPK+0aUzN9pg6bxps6HJQYTOOG2OgZAHPrBEFCrUEjlGpbyaTjGxrujRgOpMZH 9bQr2of0jyYCvbxaiwtQddQxFC/4WO//qeuuUop+AZ+xJ4TsauY2c7RZtbxAA0xV6L VLhqX0iScStCSG6osI0uxEXwxvPAJcyDAyckSOPM= Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09LCE27r038036; Wed, 21 Oct 2020 08:14:02 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 21 Oct 2020 08:14:01 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Wed, 21 Oct 2020 08:14:01 -0400 From: Roman Danyliw To: Carsten Bormann CC: The IESG , "cose-chairs@ietf.org" , "ivaylo@ackl.io" , "draft-ietf-cose-x509@ietf.org" , "cose@ietf.org" Thread-Topic: [COSE] Roman Danyliw's Discuss on draft-ietf-cose-x509-07: (with DISCUSS and COMMENT) Thread-Index: AQHWp1YEFPUe59oTH0GMVTVPrFfIBKmh5awAgAAR5WA= Date: Wed, 21 Oct 2020 12:14:00 +0000 Message-ID: <2fa28683120142bfa9551b9f7bbf3893@cert.org> References: <160324908697.22038.2714972412110979523@ietfa.amsl.com> <7A27731F-1C04-4542-B2AC-2A46F2DEF4E7@tzi.org> In-Reply-To: <7A27731F-1C04-4542-B2AC-2A46F2DEF4E7@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.203.69] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [COSE] Roman Danyliw's Discuss on draft-ietf-cose-x509-07: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 12:14:09 -0000 SGkgQ2Fyc3RlbiENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDYXJz dGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4NCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDIx LCAyMDIwIDM6MDYgQU0NCj4gVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz4NCj4gQ2M6 IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPjsgY29zZS1jaGFpcnNAaWV0Zi5vcmc7IGl2YXlsb0Bh Y2tsLmlvOyBkcmFmdC1pZXRmLQ0KPiBjb3NlLXg1MDlAaWV0Zi5vcmc7IGNvc2VAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFtDT1NFXSBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1p ZXRmLWNvc2UteDUwOS0wNzogKHdpdGgNCj4gRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IE9u IDIwMjAtMTAtMjEsIGF0IDA0OjU4LCBSb21hbiBEYW55bGl3IHZpYSBEYXRhdHJhY2tlciA8bm9y ZXBseUBpZXRmLm9yZz4NCj4gd3JvdGU6DQo+ID4NCj4gPiBTZWN0aW9uIDIuICBXaGVyZSBpcyB0 aGUgdXJpIChDQ0RMKSBzeW50YXgvZm9ybWF0L2RhdGEgdHlwZSAodXNlZCBieSB4NXUgYW5kDQo+ ID4geDV1LXNlbmRlcikgZGVmaW5lZD8NCj4gDQo+IFRoZSBkcmFmdCByZWZlcmVuY2VzIFJGQyAz OTg2Lg0KPiANCj4gSXQgY291bGQgYmUgbW9yZSBleHBsaWNpdCBpbiBzYXlpbmcgdGhhdCB0aGUg VVJJIGFzIGRlZmluZWQgaW4gUkZDIDM5ODYgaXMNCj4gcmVwcmVzZW50ZWQgYXMgYSBDQk9SIHRl eHQgc3RyaW5nOyBpdCBpcyBpbmRlZWQgdW5mb3J0dW5hdGUgdGhhdCB0aGUgdGFibGVzIHVzZQ0K PiB0aGUgdGVybSDigJx1cmnigJ0gd2hpY2ggaXMgdGhlIG5hbWUgZ2l2ZW4gYnkgUkZDIDg2MTAg QXBwZW5kaXggRCB0byB0aGUgQ0RETA0KPiBwcmVsdWRlIHR5cGUgZm9yIFRhZyAzMiAodXJpID0g IzYuMzIodHN0cikpLg0KDQpFeGFjdGx5LiAgVGhlIGRyYWZ0cyBjaXRlcyB0aGUgc3ludGF4IG9m IHRoZSBVUkwgd2l0aCBSRkMzOTg2LCBidXQgaXQgZG9lcyBub3Qgc3RhdGUgdGhlIENCT1IgZGF0 YSB0eXBlIC0tIHRoaXMgd2FzIHRoZSBzaW1wbGUgY2xhcmlmaWNhdGlvbiBJIHdhcyBsb29raW5n IGZvci4NCg0KVGhlIG5hbWUgY29sbGlzaW9uIGlzIGRlZmluaXRlbHkgdW5mb3J0dW5hdGUuDQoN ClJlZ2FyZHMsDQpSb21hbg0KDQo+ID4gSXMgdGhpcyBjb3ZlcmVkIGJ5IENCT1IgdGFnPTMyPw0K PiANCj4gVGFnIDMyIHdvdWxkIGJlIGEgd2F5IHRvIG1hcmsgdGhlIHRleHQgc3RyaW5nIGFzIGEg VVJJIGF0IHRoZSBDQk9SIGxldmVsICh0aGUNCj4gZGVmaW5pdGlvbnMgb2YgVGFnIDMyIGluIFJG QyA3MDQ5IGFzIHdlbGwgYXMgZHJhZnQtaWV0Zi1jYm9yLTcwNDliaXMgYm90aCBhbHNvDQo+IHJl ZmVyZW5jZSBSRkMgMzk4NikuDQo+IEhvd2V2ZXIsIHRoZSBhZGRpdGlvbiBvZiB0aGUgdGFnIGlz IG5vdCBuZWVkZWQgaGVyZSwgYXMgdGhlIGxhYmVsZWQgcGFyYW1ldGVyDQo+ICh4NXUveDV1LXNl bmRlcikgYWxyZWFkeSBwcm92aWRlcyB0aGUgVVJJIHNlbWFudGljcy4NCj4gKE9uZSBjb252ZW50 aW9uIHRvIHNpZ25pZnkgdGhlIHVzZSBvZiBhbiB1bmFkb3JuZWQgdGV4dCBzdHJpbmcgd2l0aCBV UkkNCj4gc2VtYW50aWNzIGluIENEREwgd291bGQgYmUg4oCcfnVyaeKAnS4pDQo+IA0KPiBHcsO8 w59lLCBDYXJzdGVuDQoNCg== From nobody Wed Oct 21 10:58:19 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 34B433A13ED; Wed, 21 Oct 2020 10:58:18 -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-x509@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov , ivaylo@ackl.io X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160330309778.31613.17554753154209688241@ietfa.amsl.com> Date: Wed, 21 Oct 2020 10:58:18 -0700 Archived-At: Subject: [COSE] Benjamin Kaduk's Yes on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 17:58:18 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-cose-x509-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It's still hard to believe we've lost Jim. Thank you for taking up the mantle to finish this work. As Roman noted already, the secdir review had some good points (and perhaps also some that do not require changes to the text), which deserves a response. [The missing examples in the linked github repo have already been noted a few times so I have nothing further to say about it.] It's interesting that JOSE does not have an 'x5bag' parameter, though I don't think that there is a need for this document to do anything in that regard. Abstract The CBOR Signing And Encrypted Message (COSE) structure uses references to keys in general. For some algorithms, additional properties are defined which carry parts of keys as needed. The COSE (nit) I'm not sure that "parts of keys" covers all cases; the boundary between a "key" and various attributes or parameters associated with it can be fuzzy at times. Perhaps something like "parameters relating to keys" would be more encompassing? Section 2 required certificate evaluation and processing. It is also reasonable that a constrained device would have the hash of a certificate associated with a public key and be configured use a public key for that thumbprint, but without performing the certificate evaluation or even having the entire certificate. This implies that the constrained device is not doing the required revocation checking, which probably merits some form of caveat (a management system that monitors revocation and updates the device if needed?). This is particularly poingnant given the following paragraphs admonition that "[c]ertificates [...] MUST still be validated". a chain length of one as well as longer chains. If the application cannot establish trust in the certificate, that certificate cannot be used. The secdir review already noted some potential issues with the blanket "cannot be used"; another possible rewording would be "the public key contained in the certificate cannot be used for cryptographic operations". x5chain: This header parameter contains an ordered array of X.509 certificates. The certificates are to be ordered starting with the certificate containing the end-entity key followed by the certificate which signed it and so on. There is no requirement for the entire chain to be present in the element if there is reason to believe that the relying party already has, or can locate the missing certificates. This means that the relying Are the missing certificates required to be contiguous and contain the root? That is, is it okay to leave a gap in the middle of the chain? [still x5chain] This header parameter allows for a single X.509 certificate or a chain of X.509 certificates to be carried in the message. It's slightly surprising that the "chain" structure allows for a single certificate not in an array container; it might be intuitively more simple to just always use the array encoding for a chain, even a one-element chain. But I'm sure there's some reason to allow it, too, just not one that I thought of right away. x5t: This header parameter provides the ability to identify an X.509 certificate by a hash value. The attribute is an array of two I suggest using the word "thumbprint" somewhere to motivate the 't' in "x5t". Also, we may want to make a pass to check for consistent usage of "attribute", "parameter", etc. -- I think this is the first time we say "the attribute is". For interoperability, applications which use this header parameter MUST support the hash algorithm 'SHA-256', but can use other hash algorithms. In light of the following notes, perhaps we should add another sentence along the lines of "This requirement allows for different implementations to be configured to use an interoperable algorithm, but does not preclude the use (by prior agreement) of other algorithms." x5u: This header parameter provides the ability to identify an X.509 [...] As this header parameter implies a trust relationship, the attribute MUST be in the protected attribute bucket. In light of the secdir reviewer's comments, perhaps "a trust relationship between the party generating the x5u parameter and the party hosting the referred-to resource" would help? The URI provided MUST provide integrity protection and server authentication. For example, an HTTP or CoAP GET request to retrieve a certificate MUST use TLS [RFC8446] or DTLS [I-D.ietf-tls-dtls13]. If the certificate does not chain to an existing trust anchor, the certificate MUST NOT be trusted unless I think we should probably clarify that it is the "received" or "retrieved" certificate (as opposed to the certificate used to authenticate the (D)TLS connection used to dereference the URI). the server is configured as trusted to provide new trust anchors. In particular, self-signed certificates MUST NOT be trusted without an out-of-band confirmation. I agree with the secdir reviewer that some rewording/clarification is in order here. +---------+-------+---------------+---------------------+ | x5u | TBD2 | uri | URI pointing to an | | | | | X.509 certificate | +---------+-------+---------------+---------------------+ I agree with Roman that a more explicit statement of where the uri type is defined (or inline definition) is needed. The header parameters are used in the following locations: [...] I guess draft-ietf-cose-countersign is on the hook for specifying anything needed about the X.509-related parameter usage? It looks like COSE_Countersignature reuses the COSE_Signature sturcture, but I would not (naively) expect that to also inherit the ability to use these parameters. COSE_Countersignature0 does not have any place to stow metadata, so I guess these parameters are not useful at all there. In Table 2, I think all the "AES192KW" and "AES256KW" should be "A192KW" and "A256KW", respectively. Section 5 I think we need to explicitly pull in (by reference) the security considerations from RFC 3986, arguably with specific call-out to the "reliability and consistency" portions. We might also mention that path validation is an important part of establishing trust in a certificate and point to RFC 5280. I don't feel a huge need to also mention the possibility of constructing alternative chains, though we could do that as well if desired. We should probably also have some pro-forma mention of the strength of the hash used for a certificate thumbprint being a factor in the security of the system. Section 6.2 I feel like RFC 8152 (or the bis) ought to be present as a normative reference; you cannot implement these new parameters outside the context of a broader COSE implementation. From nobody Wed Oct 21 11:31: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 F11CB3A122F; Wed, 21 Oct 2020 11:31:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-cose-x509@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov , ivaylo@ackl.io X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <160330506996.22995.11534193058499105713@ietfa.amsl.com> Date: Wed, 21 Oct 2020 11:31:09 -0700 Archived-At: Subject: [COSE] Alissa Cooper's No Objection on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 18:31:10 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-cose-x509-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for taking this on. Please respond to the Gen-ART review. May Jim rest in peace. From nobody Wed Oct 21 12:57: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 3F7B73A13DD for ; Wed, 21 Oct 2020 12:57:03 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 Rm8q5w7vMYs3 for ; Wed, 21 Oct 2020 12:57:02 -0700 (PDT) Received: from p3plsmtpa12-05.prod.phx3.secureserver.net (p3plsmtpa12-05.prod.phx3.secureserver.net [68.178.252.234]) (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 C885C3A1468 for ; Wed, 21 Oct 2020 12:57:01 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id VKC5k4JtvGtvXVKC5ksgMa; Wed, 21 Oct 2020 12:54:46 -0700 X-CMAE-Analysis: v=2.3 cv=S9ynP7kP c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=48vgC7mUAAAA:8 a=NeJZvmmVAAAA:20 a=2cuxrn7jV-XLgP4STtAA:9 a=QEXdDO2ut3YA:10 a=gookZOs7tmVOqObNF5cA:9 a=jpCPEmtiyVhC5sSh:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <161E653B-4A17-4B3C-9312-19532C2936D3@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FEA4F30F-C74F-47F6-B83D-5E2CE41229C0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Wed, 21 Oct 2020 12:54:44 -0700 In-Reply-To: <160330309778.31613.17554753154209688241@ietfa.amsl.com> Cc: The IESG , cose-chairs@ietf.org, ivaylo@ackl.io, draft-ietf-cose-x509@ietf.org, cose@ietf.org To: Benjamin Kaduk References: <160330309778.31613.17554753154209688241@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4wfENBghZufkePC5ZULKM9RaTjGk0JA6zDGDv73zTjyqDLSa2i+1NETIhEuPr6yjNO1ONMWtLuQZ3EmbMcGhmS3dmNfn+6bzwjeXuBc9VRAzVRzvF+rjGh WGSF4nx2v18ThDW2c0HaUdz8JVvJPVzk+5TL4q8oKRfbbNAMXluXFVZo7/Gozlgs5FTzaR6JtYmWFhJDXmN75T52rm+TtOSn6m8d1w311inJqDq8aaviq7kv lFlX8bssEVf+4kuYDjIU/OsIYquMuOqaq1RjsV/7/Bv3xlDbM76vPZo1D9eBBjx65kxGivWKMuAaMTXGytHlyQ== Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Yes on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 19:57:03 -0000 --Apple-Mail=_FEA4F30F-C74F-47F6-B83D-5E2CE41229C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 21, 2020, at 10:58 AM, Benjamin Kaduk via Datatracker = wrote: >=20 > x5t: This header parameter provides the ability to identify an = X.509 > certificate by a hash value. The attribute is an array of two >=20 > I suggest using the word "thumbprint" somewhere to motivate the 't' in > "x5t=E2=80=9D. Using =E2=80=9Cthumbprint=E2=80=9D makes sense to me, though it was = changed from thumbprint to fingerprint in March = .=20 Is it the common understanding that this =E2=80=9Cx5t=E2=80=9D = identifies the end-entity cert like subjectKeyIdentifier does for CMS = ? I can=E2=80=99t = imagine what else it would identify, but it seems saying this explicitly = would be helpful. CMS certainly is explicit and detailed on this. >=20 > Also, we may want to make a pass to check for consistent usage of > "attribute", "parameter", etc. -- I think this is the first time we = say > "the attribute is=E2=80=9D. I believe the correct term is =E2=80=9Cheader parameter=E2=80=9D. This = was settled on for draft-ietf-cose-rfc8152bis-struct and Jim made a = number of changes to cose-x509 to use that term back in March (same PR = as referenced above). However, =E2=80=9Cattribute=E2=80=9D is still used = a lot and probably all those uses should be =E2=80=9Cheader = parameter=E2=80=9D. LL --Apple-Mail=_FEA4F30F-C74F-47F6-B83D-5E2CE41229C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Oct 21, 2020, at 10:58 AM, Benjamin Kaduk via Datatracker <noreply@ietf.org> = wrote:

  x5t:  This = header parameter provides the ability to identify an X.509
     certificate by a hash value. =  The attribute is an array of two

I suggest using the word "thumbprint" somewhere to motivate = the 't' in
"x5t=E2=80=9D.

Using =E2=80=9Cthumbprint=E2=80=9D makes sense to = me, though it was changed from thumbprint to fingerprint in = March. 

Is it the common = understanding that this =E2=80=9Cx5t=E2=80=9D identifies the end-entity = cert like subjectKeyIdentifier does for CMS? I can=E2=80=99t = imagine what else it would identify, but it seems saying this explicitly = would be helpful. CMS certainly is explicit and detailed on = this.


Also, we may = want to make a pass to check for consistent usage of
"attribute", "parameter", etc. = -- I think this is the first time we say
"the attribute is=E2=80=9D.

I believe the correct term is =E2=80=9Cheader = parameter=E2=80=9D. This was settled on for draft-ietf-cose-rfc8152bis-struct and Jim made a = number of changes to cose-x509 to use that term back in March (same PR = as referenced above). However, =E2=80=9Cattribute=E2=80=9D is still used = a lot and probably all those uses should be =E2=80=9Cheader = parameter=E2=80=9D.

LL



= --Apple-Mail=_FEA4F30F-C74F-47F6-B83D-5E2CE41229C0-- From nobody Wed Oct 21 13:28: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 51E163A02C1; Wed, 21 Oct 2020 13:28:04 -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 hYYYvgr7eALs; Wed, 21 Oct 2020 13:28:02 -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 B55783A03C9; Wed, 21 Oct 2020 13:28:01 -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 09LKRrwA008894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Oct 2020 16:27:58 -0400 Date: Wed, 21 Oct 2020 13:27:53 -0700 From: Benjamin Kaduk To: Laurence Lundblade Cc: The IESG , cose-chairs@ietf.org, ivaylo@ackl.io, draft-ietf-cose-x509@ietf.org, cose@ietf.org Message-ID: <20201021202753.GV39170@kduck.mit.edu> References: <160330309778.31613.17554753154209688241@ietfa.amsl.com> <161E653B-4A17-4B3C-9312-19532C2936D3@island-resort.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <161E653B-4A17-4B3C-9312-19532C2936D3@island-resort.com> Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Yes on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 20:28:04 -0000 On Wed, Oct 21, 2020 at 12:54:44PM -0700, Laurence Lundblade wrote: > > > On Oct 21, 2020, at 10:58 AM, Benjamin Kaduk via Datatracker wrote: > > > > x5t: This header parameter provides the ability to identify an X.509 > > certificate by a hash value. The attribute is an array of two > > > > I suggest using the word "thumbprint" somewhere to motivate the 't' in > > "x5t”. > > Using “thumbprint” makes sense to me, though it was changed from thumbprint to fingerprint in March . My point was more that we're effectively tied to the "x5t" symbol for JOSE parity, and even if we want to call the thing it carries a "fingerprint", we should still use the word "thumbprint" once to explain the mnemonic value of the 't'. > Is it the common understanding that this “x5t” identifies the end-entity cert like subjectKeyIdentifier does for CMS ? I can’t imagine what else it would identify, but it seems saying this explicitly would be helpful. CMS certainly is explicit and detailed on this. That's what I assumed, but probably worth a mention (one could, of course, identify a CA by fingerprint as well). > > > > Also, we may want to make a pass to check for consistent usage of > > "attribute", "parameter", etc. -- I think this is the first time we say > > "the attribute is”. > > I believe the correct term is “header parameter”. This was settled on for draft-ietf-cose-rfc8152bis-struct and Jim made a number of changes to cose-x509 to use that term back in March (same PR as referenced above). However, “attribute” is still used a lot and probably all those uses should be “header parameter”. That sounds right for everything except the -sender variants, which are "header algorithm parameter"s. (I had to look it up and check again while reviewing the document.) -Ben From nobody Wed Oct 21 13:50: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 507F33A0876 for ; Wed, 21 Oct 2020 13:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 ttaCOA0pwUxj for ; Wed, 21 Oct 2020 13:50:17 -0700 (PDT) Received: from p3plsmtpa08-01.prod.phx3.secureserver.net (p3plsmtpa08-01.prod.phx3.secureserver.net [173.201.193.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167D03A0A42 for ; Wed, 21 Oct 2020 13:50:10 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id VL3hknZ2miiCvVL3hkJCFB; Wed, 21 Oct 2020 13:50:09 -0700 X-CMAE-Analysis: v=2.3 cv=J5PUEzvS c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=48vgC7mUAAAA:8 a=NeJZvmmVAAAA:20 a=42J9ZSqge4FyWX5NUyoA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Laurence Lundblade In-Reply-To: <20201021202753.GV39170@kduck.mit.edu> Date: Wed, 21 Oct 2020 13:50:09 -0700 Cc: cose@ietf.org, cose-chairs@ietf.org, draft-ietf-cose-x509@ietf.org, The IESG , ivaylo@ackl.io Content-Transfer-Encoding: quoted-printable Message-Id: References: <160330309778.31613.17554753154209688241@ietfa.amsl.com> <161E653B-4A17-4B3C-9312-19532C2936D3@island-resort.com> <20201021202753.GV39170@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4wfBQ9dB0+68VlCvqbA//CrigVAsLcrGDALGUutzS+xOvts87czfujR1XhBvoNbYKBgige4dEdmds4bnJeNFRgA4ECdhKgLlozUHTyr5jW99ohBpJgUWmD wpYdKleansZlnqm4Bu2xH84p5KjrPNn4wZGYdfDM0/BBRZsMCxFBHxhJOP5nOeqUL95OVC3fFtFB+PIVdEmdSuTRBT56vuykzUHRmeTpW0huaGKMEf2f0sOa xznvzYDCT1AYPkp7v/5DPRfQOguXKDncPXC23KrJmW9loIQwjau3HyC6swBpwCF13QiqChNX5uyUOAob+LG5Sw== Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Yes on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 20:50:21 -0000 > On Oct 21, 2020, at 1:27 PM, Benjamin Kaduk wrote: >=20 > On Wed, Oct 21, 2020 at 12:54:44PM -0700, Laurence Lundblade wrote: >>=20 >>> On Oct 21, 2020, at 10:58 AM, Benjamin Kaduk via Datatracker = wrote: >>>=20 >>> x5t: This header parameter provides the ability to identify an = X.509 >>> certificate by a hash value. The attribute is an array of two >>>=20 >>> I suggest using the word "thumbprint" somewhere to motivate the 't' = in >>> "x5t=E2=80=9D. >>=20 >> Using =E2=80=9Cthumbprint=E2=80=9D makes sense to me, though it was = changed from thumbprint to fingerprint in March = .=20 >=20 > My point was more that we're effectively tied to the "x5t" symbol for = JOSE > parity, and even if we want to call the thing it carries a = "fingerprint", > we should still use the word "thumbprint" once to explain the mnemonic > value of the 't=E2=80=99. Makes sense. >=20 >> Is it the common understanding that this =E2=80=9Cx5t=E2=80=9D = identifies the end-entity cert like subjectKeyIdentifier does for CMS = ? I can=E2=80=99t = imagine what else it would identify, but it seems saying this explicitly = would be helpful. CMS certainly is explicit and detailed on this. >=20 > That's what I assumed, but probably worth a mention (one could, of = course, > identify a CA by fingerprint as well). The identification of the CA(s) would be in the X.509 certs in the = Subject Key Identifier or such. Don=E2=80=99t think x5t would ever = identify a CA (unless the cert is both an end-entity and CA cert). I worry a little about ambiguity if you receive a COSE with an x5chain, = an x5bag and an x5t. In particular x5t and x5chain both identify the = end-entity cert. Which has precedence? Since the point of x5chain is to = avoid the work of cert path construction, I=E2=80=99d say that if it is = present, use that. If x5chain processing fails, the whole processing = fails. If every (constrained node) implementation must fall back to cert = path construction using x5bag, then there would be no savings in using = x5chain. LL From nobody Wed Oct 21 17:39: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 B87523A0A3B; Wed, 21 Oct 2020 17:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=eKar0/Ns; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LzeleRh9 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 lnsZfric5sCG; Wed, 21 Oct 2020 17:39:17 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B493A0EF3; Wed, 21 Oct 2020 17:39:16 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 86B9F12E3; Wed, 21 Oct 2020 20:39:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 21 Oct 2020 20:39:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=e hAq4IH6h4eQ0rEJzzZvH5uRaTkQkGBRdKUYM6ODhfo=; b=eKar0/NsLPvUJrklB XxrOQDZ6xxDZ4vJndSNIkXaH91xnZFWYMsVHAbUEGKvMvORubXp9kdw+75lGRQam 0/oBIyMFTqLBVSLF2X5PJpBuPJ0QhcA3zTa+wQxASYKt4CxzZ+RYQvnwMV21UXZ3 Gkwl3uY5V8qJSZWV5/85X/R6dCLmHQBvbWpzXYdM5ifvk7JBLWIXw9LvfVWeQjnw Jf1oqzx22qXCAAwCQguZMhpFh6cQVi+Dgea9J2ncX0o1tTbLn1hwEEmzAq7Q8y2l zOqPqynz3tXNvGRQKf2B6Z8q9yCCNNoeVRJkZikx45H0aeb0n5SAUK6q0XayiTkL GnJ3g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ehAq4IH6h4eQ0rEJzzZvH5uRaTkQkGBRdKUYM6ODh fo=; b=LzeleRh9TEpnS7OuZUtsZB1tfddWffEqpOp/ZYTKpgWkrVrS0OEqkb8Ky WwtL6DA0JqdkMNsWtpwij7idMBNwFzMONi4VbGMA5KRxVmQNhuMpo0vI7lPNdBzo 8/4o0Jkc6+L2RDXKZ+ogshhEpSCYg4N0ke4erCxQoNA8X6dfFQIZQMESqwDeBRzn HYmg6Of5bxgJNwnTzJ34GTAarxl7Zv9DVF5085nEYcpDG/YRwF0psLEcit0ZQKfj 2LWdXCPTLl2L2Z+08byvjbY2JypMf6gzl02LpDO1VI9/iJghOTPXRB7N0YOzFJg6 3LDRj8m3n6fLa4Ndi1tIAMnUhTSnA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeeigdefgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuggftrfgrth htvghrnhepfeduhffgtefgtedvvdffiedutdekffegvdejjedtieehfefgleefuedtledv gffgnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrd eiheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegr lhhishhsrgestghoohhpvghrfidrihhn X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.65]) by mail.messagingengine.com (Postfix) with ESMTPA id 62A303064680; Wed, 21 Oct 2020 20:39:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Alissa Cooper In-Reply-To: <160043970238.15995.10253324286831703129@ietfa.amsl.com> Date: Wed, 21 Oct 2020 20:39:13 -0400 Cc: Review Team , Last Call , draft-ietf-cose-x509.all@ietf.org, cose@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <75871395-45B4-4E22-B4AD-981D28216078@cooperw.in> References: <160043970238.15995.10253324286831703129@ietfa.amsl.com> To: Vijay Gurbani X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [COSE] [Gen-art] Genart last call review of draft-ietf-cose-x509-07 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, 22 Oct 2020 00:39:19 -0000 Vijay, thanks for your review. I entered a No Objection ballot. Alissa > On Sep 18, 2020, at 10:35 AM, Vijay Gurbani via Datatracker = wrote: >=20 > Reviewer: Vijay Gurbani > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-cose-x509-07 > Reviewer: Vijay K. Gurbani > Review Date: 2020-09-18 > IETF LC End Date: 2020-10-01 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Ready for publication with nits. >=20 > Major issues: 0 >=20 > Minor issues: 0 >=20 > Nits/editorial comments: 5 >=20 > (Sn refers to Section n) > - S1: s/ad decided/and decided/ > - S1: s/Since that time a/Since that time, a/ > - S1: s/in the 6TiSCH environment [I-D.richardson-enrollment-roadmap], > describes/in the 6TiSCH environment, = [I-D.richardson-enrollment-roadmap] > describes/ - S1: "A third scenario..." The wording seemed odd since = there is no > text that sets the expectation that there will be three scenarios for > discussion. If your intent is to enumerate the different scenarios, = probably > best to prepare the reader for this ahead of time. - S2: s/which it = can then > provide to/that it subsequently provides to/ >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Oct 21 23:44:47 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1243D3A0B92; Wed, 21 Oct 2020 23:44:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-cose-x509@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <160334908054.28746.4797740329412955971@ietfa.amsl.com> Date: Wed, 21 Oct 2020 23:44:41 -0700 Archived-At: Subject: [COSE] Murray Kucherawy's No Objection on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 06:44:41 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-cose-x509-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would like to add my thanks to Jim Schaad for this document, and for all of his other contributions to the IETF. -- Section 1 includes a GitHub URL where the reader can find examples. Is this acceptable as a permanent reference? Section 2: * "... will evaluate and process of X.509 certificates ..." -- remove "of"? * "... and be configured use ..." -- add "to"? * The first paragraph of the "x5t" bullet seems to have a couple of sentences smashed together at the end. * Has the note about the AD Review comments in this section been resolved? From nobody Thu Oct 22 05:18:16 2020 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0613A0AE0; Thu, 22 Oct 2020 05:18:11 -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-x509@ietf.org, cose-chairs@ietf.org, cose@ietf.org, Ivaylo Petrov , ivaylo@ackl.io X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <160336909147.3199.13133404901002626604@ietfa.amsl.com> Date: Thu, 22 Oct 2020 05:18:11 -0700 Archived-At: Subject: [COSE] Magnus Westerlund's Discuss on draft-ietf-cose-x509-07: (with DISCUSS) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 12:18:12 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-cose-x509-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think the topic should be fairly easily to resolve one way or another. However, even after having read the reply to Marin's comment I don't think this document is published with the right status. - The document defines new CBOR attributes, that is standard track work as it comes out as consensus document from a IETF WG. - It does not define or document crypto algorithm just refer to existing ones. - The charter item might have been reasonable as informational if existing attributes could have been used. With the choice to define new attributes I think this has entered standards track. - The status of the document I think will also affect the value that IANA might assign to these COSE Header Parameters. If there are additional considerations I am happy to learn about them. Else, I would propose a change of status to proposed standard and redo the IETF last call. From nobody Thu Oct 22 08:21: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 BD4373A1085 for ; Thu, 22 Oct 2020 08:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psn5Rbv7z-h3 for ; Thu, 22 Oct 2020 08:21:35 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C903A11D8 for ; Thu, 22 Oct 2020 08:21:27 -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 09MFLL9T020025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Oct 2020 11:21:25 -0400 Date: Thu, 22 Oct 2020 08:21:20 -0700 From: Benjamin Kaduk To: Laurence Lundblade Cc: cose Message-ID: <20201022152120.GA39170@kduck.mit.edu> References: <9284FE68-45D9-4282-8526-78914C3E3043@island-resort.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9284FE68-45D9-4282-8526-78914C3E3043@island-resort.com> Archived-At: Subject: Re: [COSE] draft-ietf-cose-x509-07 and x5u header 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, 22 Oct 2020 15:21:38 -0000 On Mon, Oct 19, 2020 at 11:40:33AM -0700, Laurence Lundblade wrote: > I’m trying to understand why the x5u header must be a COSE protected header parameter and in general what the expected use of this header is. > > My understanding is that it the relying party that is validating the cert chain is the one doing the HTTP fetching. > > In the case of application/pkix-cert, then only one DER cert is returned and that is the end-entity cert. > > My expectation for the way this would work is: > - The relying party would use HTTP to with the x5u URL to fetch the end-entity cert > - The relying party would have a trust anchor previously configured > - The certs in the chain between the end-entity are either already possess by the relying party or are in the x5bag header > - Then it is just a straight forward chain formation and validation. > > In this use, there is no requirement for security of the URL or for use of TLS to fetch it. All the necessary security is provided by standard chain validation. > > So why is there a requirement that the header be protected and that TLS/DTLS be used? > > Further, wouldn't the header protection be a form of self signing since the private key used to sign the header corresponds to the public key that is being fetched? It is in some sense a form of self-signing, yes. But TLS (or equivalent) is still needed for fetching the certificate in order to verify that the *certificate* received is the one intended, not a different certificate that wraps the same public key. There are plenty of attacks if you swap out the certificate for one with different key usage, SAN, etc. You might argue that it's hard to get a different cert (with attacker-controlled contents) for the same public key if the attacker doesn't have access to the corresponding private key, but that's not a very reliable security control. -Ben From nobody Thu Oct 22 08:23: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 CAFFC3A0EC7; Thu, 22 Oct 2020 08:23:40 -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 S27gurA5ydam; Thu, 22 Oct 2020 08:23:39 -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 620BD3A0957; Thu, 22 Oct 2020 08:23:39 -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 09MFNT9G020903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Oct 2020 11:23:34 -0400 Date: Thu, 22 Oct 2020 08:23:29 -0700 From: Benjamin Kaduk To: Ivaylo Petrov Cc: Robert Wilton , Cose Chairs Wg , draft-ietf-cose-x509@ietf.org, The IESG , cose Message-ID: <20201022152329.GB39170@kduck.mit.edu> References: <160313511018.7246.11234492090901667420@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [COSE] Robert Wilton's No Objection on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 15:23:41 -0000 On Tue, Oct 20, 2020 at 08:28:26AM +0300, Ivaylo Petrov wrote: > Thank you Robert for your review! From this discussion [1] it appears that > indeed the intention of the usage of the term bag was not to make any > assumptions about the uniqueness of the elements. I am taking a note to > make that clear in the document regardless of the conclusion of that > discussion. > > [1]: https://mailarchive.ietf.org/arch/msg/cose/VLv2E6wcGkC4YY-vFMRxnEAXrXo/ There is also some precedent for the use of "bag" for this type of thing; consider, e.g., https://tools.ietf.org/html/rfc7292#section-4.2.3 . -Ben From nobody Thu Oct 22 08:28:03 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665313A0EFC; Thu, 22 Oct 2020 08:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDLasLpwfuUH; Thu, 22 Oct 2020 08:28:01 -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 DBE563A0EE8; Thu, 22 Oct 2020 08:28:00 -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 09MFRoZn022702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Oct 2020 11:27:56 -0400 Date: Thu, 22 Oct 2020 08:27:49 -0700 From: Benjamin Kaduk To: Roman Danyliw Cc: The IESG , cose-chairs@ietf.org, ivaylo@ackl.io, draft-ietf-cose-x509@ietf.org, cose@ietf.org Message-ID: <20201022152749.GC39170@kduck.mit.edu> References: <160324908697.22038.2714972412110979523@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <160324908697.22038.2714972412110979523@ietfa.amsl.com> Archived-At: Subject: Re: [COSE] Roman Danyliw's Discuss on draft-ietf-cose-x509-07: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 15:28:02 -0000 On Tue, Oct 20, 2020 at 07:58:06PM -0700, Roman Danyliw via Datatracker wrote: > ** Section 5. Per “On the other hand, an oracle can potentially be built based > on detecting the network resources which is only done if the signature > validation passes.”, I didn’t follow what this means. The scenario is an attacker sending probably-bogus signatures to the node that behaves in this way. The (lack of) outbound network requests is an oracle as to whether the signature is valid. This is generally not useful in its own right, but is a fairly common building block to assemble with other weaknesses into a consolidated attack, which is why I assumed it was mentioned. -Ben From nobody Thu Oct 22 09:59: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 806B73A08CF; Thu, 22 Oct 2020 09:59:45 -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 paN5Np09OSPb; Thu, 22 Oct 2020 09:59:43 -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 175403A08CD; Thu, 22 Oct 2020 09:59:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1B2F2389B0; Thu, 22 Oct 2020 13:06:01 -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 3M54c4Wtyo6o; Thu, 22 Oct 2020 13:06:00 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8CB2A389AF; Thu, 22 Oct 2020 13:06:00 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 89496DAF; Thu, 22 Oct 2020 12:59:40 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk , Ivaylo Petrov , Robert Wilton , Cose Chairs Wg , cose , The IESG , draft-ietf-cose-x509@ietf.org In-Reply-To: <20201022152329.GB39170@kduck.mit.edu> References: <160313511018.7246.11234492090901667420@ietfa.amsl.com> <20201022152329.GB39170@kduck.mit.edu> 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] Robert Wilton's No Objection on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 16:59:46 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Benjamin Kaduk wrote: > On Tue, Oct 20, 2020 at 08:28:26AM +0300, Ivaylo Petrov wrote: >> Thank you Robert for your review! From this discussion [1] it appears that >> indeed the intention of the usage of the term bag was not to make any >> assumptions about the uniqueness of the elements. I am taking a note to >> make that clear in the document regardless of the conclusion of that >> discussion. >> >> [1]: https://mailarchive.ietf.org/arch/msg/cose/VLv2E6wcGkC4YY-vFMRxnEAXrXo/ > There is also some precedent for the use of "bag" for this type of thing; > consider, e.g., https://tools.ietf.org/html/rfc7292#section-4.2.3 . Yes! I was trying to make allusions to some place in PKIX where bag was used. I understand Carsten's objection that it's mathematically incorrect. I don't care one way or another. --=-=-= Content-Type: text/plain Content-Disposition: inline Content-Description: Signature -- ] 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+93Q3WUFAl+RunwACgkQgItw+93Q 3WUvfgf6Ani9zNlF0BtAzrexZ4sy6UZCxRxsnFQRWRqAhN7XYxc7248u/1Km0WFa Vao4/ESqWu58UbzFL2np8IqN8MzFp6FRSxETvER9SoINuvbidcLnPe2XcNQZtvMN cHC+qdg23GHXhKa07zz74e6SSlWyNKndI8n0yDedtmEqIkuwEtOp55YiaiIg0p0R 4mWRqR9udGzJHSjb+YESU5Vk46vrh7Wyi7/MMvZ/nz4a2bUJmt9iNu2I0Fnfw7sL wOyoga6pWlV8rF1esfRcRHXJ74lsktp0ahphp/USx/KAsYLBZbtx9dszlhclU6D7 RxW7SeEm29IXeIycARarys/WpBt+TA== =sG/o -----END PGP SIGNATURE----- --==-=-=-- From nobody Thu Oct 22 10:20: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 3540C3A101F; Thu, 22 Oct 2020 10:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=K6A/4Gmt; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xDxgNRH0 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 UmmuSjX5mn_T; Thu, 22 Oct 2020 10:20:16 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE133A0C92; Thu, 22 Oct 2020 10:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1696; q=dns/txt; s=iport; t=1603387201; x=1604596801; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=bLJb5F2/WPzzTwlMmlS5WU70Qfshmy/104AuxbDkI14=; b=K6A/4GmtoqDTnJh9O171PM60ZM0Cv8zJbVz+uKmY31n30vNcHNZe6uIH x0rTj41BmCzzSwENJdiIEoiBOA4FaQWUIOvJcAfLiZzb33FItSvGzhz18 gXg6vAmFqvUVgPmiECtSLLzrx3doGUTASjyPNPWANCYJtchBws/Z+DDsh o=; IronPort-PHdr: =?us-ascii?q?9a23=3ARkFGWhaP1ZOFULj3DOmgO6//LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QWRD57S7f5Jj+/ftebrUD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Jq3u+4DoXEx?= =?us-ascii?q?O5PgMmbujwE5TZ2sKw0e368pbPYgJO0Ty6Z746LBi/oQjL8McMho43IacqwR?= =?us-ascii?q?yPqXxNKOk=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DsBQBSvpFf/5tdJa1gDg4BAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIFPgVJRB3BZLywKh3sDjU6YeoJTA1ULAQEBDQEBIwoCBAE?= =?us-ascii?q?BhEoCggkCJTgTAgMBAQsBAQUBAQECAQYEbYVhDIVyAQEBAQMSKAYBATgLBAI?= =?us-ascii?q?BCA4DBAEBAR4QMh0IAgQBEggagwWCSwMuAQMLpz0CgTmIaHSBNIMEAQEFgTM?= =?us-ascii?q?Bg00YghADBoE4gnKGNIQTG4FBP4ERQ4JNPoJcAQECAYFeg0iCLLcGgQMKgmq?= =?us-ascii?q?JBJIXoV6TPIp2lUECBAIEBQIOAQEFgWsjgVdwFYMkUBcCDY4fN4M6hRSFBAU?= =?us-ascii?q?BOHQCATUCBgoBAQMJfIw7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,404,1596499200"; d="scan'208";a="569808576" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Oct 2020 17:20:00 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 09MHK0UX030104 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2020 17:20:00 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 22 Oct 2020 12:20:00 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 22 Oct 2020 12:19:59 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 22 Oct 2020 13:19:59 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MzH+yVN582OAOr830JaYE7unjEglo9AP7QiIeNWtAsyHH8XmnsJyPW2uzrmxkdBma4sKjsbReIwSg4XvA+MD9U53pNtbdMmUojoznWUsJZ9/guCapvXmQPa9G0UqVFYD7jUMBgja0chKjcPwDJlNipK8OSqHOCyTEwDYyI99SFVwG6sDtqfETYbNtEmY0uWlxRKww+h2Oijxbgvhe1EpFvezFLSOkHqWewCFflkM/LR6q5bm1asaYgUpIlHAN+voAaZ+/j8zSO3noaF+w9kFqnWTFD4ALonBvfbIB9ucaR0lalefeTul/vJcVKriS3HG/0FcDTTMXbv10TcF2XuynA== 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=51QvNaM1nuKA3+Kup6IwoDYO3R2e3ld5z4aSiyUdQBQ=; b=algLrAQp3teZntGiDHx/1mV68IU7yi1CvtEdL80NiJ29IBiSfPn12WgHbMFTSC4IUJNoR6tWXwEPmmc0rm++IidH8vgLFThYdu6e2XaoxCBUSudfjc5JLQBFHILc+DSESvJUvwOaKWj6pFWRhhMQuYcoSff02oGRlC7LszwEyvtPR8pG7O3mi4m1YJvg8rXZItA7IWxqZTJJv/J7GvzJzPxG8wDzWOF4XUU1jVyC+hfv0KpclVTtIglZUvkDW+TyVu22AOeLlNqZ8+eG/gfGaMtmzK4ro3kJXdpcIUP7g55xAMZI8RFyZE6CAIc5I0cDdBX8ooy1eO69idW49/xcng== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=51QvNaM1nuKA3+Kup6IwoDYO3R2e3ld5z4aSiyUdQBQ=; b=xDxgNRH08G31X2PVgqJv4oovPArwjrxZ6xAvqKLdzpFWxP3TQ5NxbPQpONO9gCuxCMnkE+hvDJ+gmwWhL+mvgQRvVbz16f9rOKa1w5YAU3a7HwUoj+CI0nNP5mLkms5HS32kwn2YqEgaoKjb5HZ77gTkxrmhWql3ofvsUgk2wS0= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3137.namprd11.prod.outlook.com (2603:10b6:208:73::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Thu, 22 Oct 2020 17:19:58 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3477.028; Thu, 22 Oct 2020 17:19:58 +0000 From: "Rob Wilton (rwilton)" To: Michael Richardson , Benjamin Kaduk , Ivaylo Petrov , Cose Chairs Wg , cose , The IESG , "draft-ietf-cose-x509@ietf.org" Thread-Topic: [COSE] Robert Wilton's No Objection on draft-ietf-cose-x509-07: (with COMMENT) Thread-Index: AQHWpkyyMPmoUFYIIUmvsHAaHYKlbqmf9xIAgAPK64CAABrfAIAAA7ZA Date: Thu, 22 Oct 2020 17:19:58 +0000 Message-ID: References: <160313511018.7246.11234492090901667420@ietfa.amsl.com> <20201022152329.GB39170@kduck.mit.edu> <5502.1603385980@localhost> In-Reply-To: <5502.1603385980@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb58e590-8925-4c98-c0e0-08d876aeb3a6 x-ms-traffictypediagnostic: BL0PR11MB3137: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mJEOEd60jCuPM4mboP6k9qDlk8kvgTFk3o4rDJB6SCuJMT6y7KrDalxfmSByxFkys5/bMfnpd3+uhMC77CDWIWy5zo5Epz3SsFl45DkGWr6TCd+T2vUmilqK1DWqCxL2IfVXSXFHHqyHS+ftCU8wnFKPEa45WP4yOotBY75JiHgkTsHshCFm+L/hOd0u7s3fExx3dyO5hmCCmAjj+q8ZMb7ZK60Ac3E4jbaIrLQLFSKxYYoDbOz0hADAhh3n4zrrR7bVp6eTQNN6oXaQsfdT9F3neHxnMMqesB9L8uEtJbk/f6UfAkmcGRPi0+vvTAh2xSeOpC0d+r8TtdjrVbV+73mChgNkGDSsMLDiMpJKNKdvqI23NtfyNj+y7LQd38KePrH3m13Gu0nDpwY7wgnuig== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(376002)(346002)(396003)(39860400002)(53546011)(83380400001)(966005)(71200400001)(9686003)(64756008)(110136005)(66476007)(66556008)(66946007)(66446008)(76116006)(6506007)(5660300002)(2906002)(316002)(8676002)(8936002)(52536014)(7696005)(186003)(33656002)(55016002)(86362001)(26005)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: w5huHo30RmPyAmVQUcM1sn7LYgJLNpb0/Xmsx6djhCHh7sJjTeap6Y9A4nECKWQ5M4MYalNDuZh0D/p/KAIWwy7oeS+XDodx4OK619OieS1emnPqiGVgs6hNhmt5PGpbMynKv68AK6ZC1AeVGWxj44iDOyI+LSkws/g561vM8+sy3B+/EPGYrh0XtFTrxmGfRN29KohzzLabP6ku0hFF6LZxr4CzmMhv20GNatWFU1aw/rlxYpKp4aXws9xoyp0bLEr02Y1laPd7yQxTBDCTttCEikfG6nLPLaTur8qLOuBC9SObAs9oCtHpzQUh+edQCOdK+0AHsTXHmPbSb+6We3252Z2ediTjEn+LCaxN2Ht41vi5Ac6UNAjWUNGPIrMmq+0sJkC7NZs9sYAVlT7lEXbl+EyRWPmz2vvduIV/GR3cWPk2n/Y6tS8HnL11k1tDzXQDpLqShwTPSSmdIqmlpo8XgjcQvHGbMlDjKTpwoSU1yKqsSObtgWcyqsJfN2lKnn8yha0S3BAE4of10j4tkYZ1TQIejWcKd69NqONZQZqjMy37Os42pnInd75CNX75Vgg6mHkofLgVWvkEZHN0viw9FhgE5WoqygAj5OyKh0nt3fEugFyThoJ8eYb/hxAlfp7vHvrpbt944YxzNjOGXQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eb58e590-8925-4c98-c0e0-08d876aeb3a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2020 17:19:58.2472 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hQ61ggC/KBPdGGBixfv5VHfv9VU9pdAYb/dSYZJO6W82cjy5MwDy67MC6dQvoCLFZhmqZ5/YYokxtBB3GaYdlQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3137 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [COSE] Robert Wilton's No Objection on draft-ietf-cose-x509-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 17:20:25 -0000 > -----Original Message----- > From: Michael Richardson > Sent: 22 October 2020 18:00 > To: Benjamin Kaduk ; Ivaylo Petrov ; Rob > Wilton (rwilton) ; Cose Chairs Wg chairs@ietf.org>; cose ; The IESG ; draft- > ietf-cose-x509@ietf.org > Subject: Re: [COSE] Robert Wilton's No Objection on draft-ietf-cose-x509- > 07: (with COMMENT) >=20 >=20 > Benjamin Kaduk wrote: > > On Tue, Oct 20, 2020 at 08:28:26AM +0300, Ivaylo Petrov wrote: > >> Thank you Robert for your review! From this discussion [1] it > appears that > >> indeed the intention of the usage of the term bag was not to make > any > >> assumptions about the uniqueness of the elements. I am taking a > note to > >> make that clear in the document regardless of the conclusion of > that > >> discussion. > >> > >> [1]: https://mailarchive.ietf.org/arch/msg/cose/VLv2E6wcGkC4YY- > vFMRxnEAXrXo/ >=20 > > There is also some precedent for the use of "bag" for this type of > thing; > > consider, e.g., https://tools.ietf.org/html/rfc7292#section-4.2.3 . >=20 > Yes! I was trying to make allusions to some place in PKIX where bag was > used. > I understand Carsten's objection that it's mathematically incorrect. > I don't care one way or another. I'm fine with it being called a bag if that is the historical term in this = context. I just think that the description should be clear that it is unor= dered and not allowed to contain duplicates. Of course, that is presuming = that it isn't allowed duplicates ;-) Regards, Rob From nobody Thu Oct 22 11:17:24 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1D63A0A50 for ; Thu, 22 Oct 2020 11:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 AKFY0yopC-Yo for ; Thu, 22 Oct 2020 11:17:22 -0700 (PDT) Received: from p3plsmtpa08-02.prod.phx3.secureserver.net (p3plsmtpa08-02.prod.phx3.secureserver.net [173.201.193.103]) (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 3A9253A0A5F for ; Thu, 22 Oct 2020 11:17:22 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id Vf9MktOWqCYOQVf9MksgsG; Thu, 22 Oct 2020 11:17:21 -0700 X-CMAE-Analysis: v=2.3 cv=IrRgj43g c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=48vgC7mUAAAA:8 a=AOUx41rpp16fiSyFkOQA:9 a=QEXdDO2ut3YA:10 a=T6nxoV7N0hILLgTO9_wA:9 a=dHcsUA_zy9Cx6eMR:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <0CF2598E-61CD-4011-9E97-1B28C7DB4065@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0DA506DC-22A6-4992-8F56-860B93F9ED75" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Thu, 22 Oct 2020 11:17:20 -0700 In-Reply-To: <160336909147.3199.13133404901002626604@ietfa.amsl.com> Cc: The IESG , cose-chairs@ietf.org, ivaylo@ackl.io, draft-ietf-cose-x509@ietf.org, cose@ietf.org To: Magnus Westerlund References: <160336909147.3199.13133404901002626604@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4wfDb9JSmklMNNxrEyE05em2gPmQl6h/FS9UHdYH9we9tEE13AJBpUHf8EbShILG3fppCYljk8YsEAd3V/EHzuhdp79mXQRrKfqHYmAm+c8uO+v/fE3vuG Eo15w+2FrP6J7yd9zJ8S6LA0FWtIK/rYOh5h3975vHdTcrTJ/xlh6meyVUBayTo9/AYW/pOB6wu/bGzK/zTz60hfEM0Pup7C4SPc593cX5EBWx2/lFzqUmy0 bPQWWq0feaCzb6ShihXrOF3lH1sdNdbgFr+eYOzimYRu258g/30Lxv3oeIlEhbhqAcWum039+0keU1sVpDA3Pp2TactAA1sFBzJ+DejuC7M= Archived-At: Subject: Re: [COSE] Magnus Westerlund's Discuss on draft-ietf-cose-x509-07: (with 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, 22 Oct 2020 18:17:23 -0000 --Apple-Mail=_0DA506DC-22A6-4992-8F56-860B93F9ED75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would like to see it as standards track. I would like EAT / RATS to make normative reference to it. Some forms of = Attestation use Endorsements to convey a signature verification key to = the Verifier and some Endorsements are in the form of an X.509 = certificate. I will present some of this at the RATS virtual interim tomorrow = . = Slides are here = . This is why I=E2=80=99ve been so = interested in this lately. Also, it seems pretty important for COSE to be usable with the all the = X.509 infrastructure out there. LL > On Oct 22, 2020, at 5:18 AM, Magnus Westerlund via Datatracker = wrote: >=20 > ... > I think the topic should be fairly easily to resolve one way or = another. > However, even after having read the reply to Marin's comment I don't = think this > document is published with the right status. >=20 > - The document defines new CBOR attributes, that is standard track = work as it > comes out as consensus document from a IETF WG. - It does not define = or > document crypto algorithm just refer to existing ones. - The charter = item might > have been reasonable as informational if existing attributes could = have been > used. With the choice to define new attributes I think this has = entered > standards track. - The status of the document I think will also affect = the > value that IANA might assign to these COSE Header Parameters. >=20 > If there are additional considerations I am happy to learn about them. >=20 > Else, I would propose a change of status to proposed standard and redo = the IETF > last call. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose >=20 --Apple-Mail=_0DA506DC-22A6-4992-8F56-860B93F9ED75 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = would like to see it as standards track.

I would like EAT / RATS = to make normative reference to it. Some forms of Attestation use = Endorsements to convey a signature verification key to the Verifier and = some Endorsements are in the form of an X.509 = certificate.

I will present some of this at the RATS virtual interim tomorrow. Slides are here. This is = why I=E2=80=99ve been so interested in this lately.

Also, it seems pretty = important for COSE to be usable with the all the X.509 infrastructure = out there.

LL


On Oct 22, 2020, at 5:18 AM, Magnus Westerlund via = Datatracker <noreply@ietf.org> wrote:

...I think the topic should be fairly easily to resolve one way = or another.
However, even after having read the reply to = Marin's comment I don't think this
document is published = with the right status.

- The document = defines new CBOR attributes, that is standard track work as it
comes out as consensus document from a IETF WG. - It does not = define or
document crypto algorithm just refer to existing = ones. - The charter item might
have been reasonable as = informational if existing attributes could have been
used. = With the choice to define new attributes I think this has entered
standards track. - The status of the document I think will = also affect the
value that IANA might assign to these COSE = Header Parameters.

If there are additional = considerations I am happy to learn about them.

Else, I would propose a change of status to proposed standard = and redo the IETF
last call.





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


= --Apple-Mail=_0DA506DC-22A6-4992-8F56-860B93F9ED75-- From nobody Thu Oct 22 11:56: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 A6F313A0AFD for ; Thu, 22 Oct 2020 11:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 x9Bc6cPZcqYQ for ; Thu, 22 Oct 2020 11:56:25 -0700 (PDT) Received: from p3plsmtpa12-06.prod.phx3.secureserver.net (p3plsmtpa12-06.prod.phx3.secureserver.net [68.178.252.235]) (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 1F4953A0AF7 for ; Thu, 22 Oct 2020 11:56:25 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id VflAkIXv6EXsLVflAkE1Mp; Thu, 22 Oct 2020 11:56:24 -0700 X-CMAE-Analysis: v=2.3 cv=Uo8dyN4B c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=vca8Hk-Ph6j2YHRVUkgA:9 a=QEXdDO2ut3YA:10 a=a0Yl254zkloZfjh9:21 a=_W_S_7VecoQA:10 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_09BAEA49-C450-4383-9292-904BCA7F3885" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Thu, 22 Oct 2020 11:56:24 -0700 In-Reply-To: <20201022152120.GA39170@kduck.mit.edu> Cc: cose To: Benjamin Kaduk References: <9284FE68-45D9-4282-8526-78914C3E3043@island-resort.com> <20201022152120.GA39170@kduck.mit.edu> X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4wfNPUIijSZAbaAmD/GNCj0Bwp0q1X/3tzNXonVGKkRT2NfjMbDVZ0emXcyBd0VInDRv6ZQhqPFY4rZ3WsgiB4m3kyCYBTaElVHt0Yqx7HefIFvssg46m/ oJ74Y3apR8BPvcaIrc7g0fcoUnT4kbz5cw2V17fg2e6l5mWFXKtNHs1pyG2iDI153oCLGpy/DB+B1A== Archived-At: Subject: Re: [COSE] draft-ietf-cose-x509-07 and x5u header 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, 22 Oct 2020 18:56:27 -0000 --Apple-Mail=_09BAEA49-C450-4383-9292-904BCA7F3885 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 22, 2020, at 8:21 AM, Benjamin Kaduk wrote: >=20 > On Mon, Oct 19, 2020 at 11:40:33AM -0700, Laurence Lundblade wrote: >> I=E2=80=99m trying to understand why the x5u header must be a COSE = protected header parameter and in general what the expected use of this = header is. >>=20 >> My understanding is that it the relying party that is validating the = cert chain is the one doing the HTTP fetching. >>=20 >> In the case of application/pkix-cert, then only one DER cert is = returned and that is the end-entity cert. >>=20 >> My expectation for the way this would work is: >> - The relying party would use HTTP to with the x5u URL to fetch the = end-entity cert >> - The relying party would have a trust anchor previously configured >> - The certs in the chain between the end-entity are either already = possess by the relying party or are in the x5bag header >> - Then it is just a straight forward chain formation and = validation.=20 >>=20 >> In this use, there is no requirement for security of the URL or for = use of TLS to fetch it. All the necessary security is provided by = standard chain validation. >>=20 >> So why is there a requirement that the header be protected and that = TLS/DTLS be used? >>=20 >> Further, wouldn't the header protection be a form of self signing = since the private key used to sign the header corresponds to the public = key that is being fetched? >=20 > It is in some sense a form of self-signing, yes. But TLS (or = equivalent) > is still needed for fetching the certificate in order to verify that = the > *certificate* received is the one intended, not a different = certificate > that wraps the same public key. There are plenty of attacks if you = swap > out the certificate for one with different key usage, SAN, etc. > You might argue that it's hard to get a different cert (with > attacker-controlled contents) for the same public key if the attacker > doesn't have access to the corresponding private key, but that's not a = very > reliable security control. Hi Ben,=20 It seems like your are interpreting the x5u header to be for the = fetching of a single validated end-entity certificate. Some remote = service did the cert chain validation. You and other folks probably were = involved in some ace work that I was not involved with to know that. I = don=E2=80=99t think it says that clearly in cose-x509, though I can now = see how you can triangulate your way to that understanding. If x5u is to = work like this, it seems a lot of addition to security considerations is = needed. RFC 2585 does not work this way. It assumes the chain validation is done = locally (see RFC 2585 Security Considerations) and that there is no need = for any transport layer security. This seems like a perfectly useful and = good thing to do and to support in cose-x509. This is what I outlined = in bullet points above. When I think about implementing cose-x509, I can see several options. 1. Just implement x5chain. Fail if x5chain is not present. Only need = code for chain validation. No need for chain formation. 2. Just implement x5bag and x5t. Fail if x5t and x5bag are not present. = Now you need code for chain validation and chain formation. 3. Just implement x5u. Fail if x5u is not present. All you need is some = ASN.1 parsing and DTLS code. No chain validation or formation needed. 4. Implement all, with a priority order like first try x5chain, then try = x5bag/x5t, finally x5u. 5. Various combinations of the above If RFC 2585 (non-validated) fetching is allowed, then further options=E2=80= =A6 LL --Apple-Mail=_09BAEA49-C450-4383-9292-904BCA7F3885 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Oct 22, 2020, at 8:21 AM, Benjamin Kaduk <kaduk@mit.edu> = wrote:

On Mon, Oct 19, 2020 at = 11:40:33AM -0700, Laurence Lundblade wrote:
I=E2=80= =99m trying to understand why the x5u header must be a COSE protected = header parameter and in general what the expected use of this header = is.

My understanding is that it the relying = party that is validating the cert chain is the one doing the HTTP = fetching.

In the case of = application/pkix-cert, then only one DER cert is returned and that is = the end-entity cert.

My expectation for the = way this would work is:
  - The relying party = would use HTTP to with the x5u URL to fetch the end-entity cert
  - The relying party would have a trust anchor = previously configured
  - The certs in the chain = between the end-entity are either already possess by the relying party = or are in the x5bag header
  - Then it is just a = straight forward chain formation and validation. 

In this use, there is no requirement for security of the URL = or for use of TLS to fetch it. All the necessary security is provided by = standard chain validation.

So why is there = a requirement that the header be protected and that TLS/DTLS be used?

Further, wouldn't the header protection be a = form of self signing since the private key used to sign the header = corresponds to the public key that is being fetched?

It is in some sense a form of self-signing, yes.  But = TLS (or equivalent)
is still needed for fetching the certificate in order to = verify that the
*certificate* received is the one intended, not a different = certificate
that wraps = the same public key.  There are plenty of attacks if you = swap
out the = certificate for one with different key usage, SAN, etc.
You might argue that it's hard = to get a different cert (with
attacker-controlled contents) for the same public key if the = attacker
doesn't have = access to the corresponding private key, but that's not a very
reliable security = control.

Hi = Ben, 

It seems like your are = interpreting the x5u header to be for the fetching of a single validated = end-entity certificate. Some remote service did the cert chain = validation. You and other folks probably were involved in some ace work = that I was not involved with to know that. I don=E2=80=99t think it says = that clearly in cose-x509, though I can now see how you can triangulate = your way to that understanding. If x5u is to work like this, it seems a = lot of addition to security considerations is needed.

RFC 2585 does not work this way. It assumes the = chain validation is done locally (see RFC 2585 Security Considerations) = and that there is no need for any transport layer security. This seems = like a perfectly useful and good thing to do and to support in = cose-x509.  This is what I outlined in bullet points = above.


When = I think about implementing cose-x509, I can see several = options.

1. Just implement = x5chain. Fail if x5chain is not present. Only need code for chain = validation. No need for chain formation.

2. Just implement x5bag and x5t. =  Fail if x5t and x5bag are not present. Now you need code for chain = validation and chain formation.

3. Just implement x5u. Fail if x5u is not = present. All you need is some ASN.1 parsing and DTLS code. No chain = validation or formation needed.

4. = Implement all, with a priority order like first try x5chain, then try = x5bag/x5t, finally x5u.

5. Various = combinations of the above

If RFC = 2585 (non-validated) fetching is allowed, then further = options=E2=80=A6

LL





= --Apple-Mail=_09BAEA49-C450-4383-9292-904BCA7F3885-- From nobody Thu Oct 22 12:12: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 9F8AD3A0B36 for ; Thu, 22 Oct 2020 12:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwiI4vMJ68Vq for ; Thu, 22 Oct 2020 12:12:31 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284B93A0B32 for ; Thu, 22 Oct 2020 12:12:30 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09MJCNaY013736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Oct 2020 15:12:28 -0400 Date: Thu, 22 Oct 2020 12:12:23 -0700 From: Benjamin Kaduk To: Laurence Lundblade Cc: cose Message-ID: <20201022191223.GH39170@kduck.mit.edu> References: <9284FE68-45D9-4282-8526-78914C3E3043@island-resort.com> <20201022152120.GA39170@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [COSE] draft-ietf-cose-x509-07 and x5u header 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, 22 Oct 2020 19:12:33 -0000 Hi Laurence, On Thu, Oct 22, 2020 at 11:56:24AM -0700, Laurence Lundblade wrote: > > > On Oct 22, 2020, at 8:21 AM, Benjamin Kaduk wrote: > > > > On Mon, Oct 19, 2020 at 11:40:33AM -0700, Laurence Lundblade wrote: > >> I’m trying to understand why the x5u header must be a COSE protected header parameter and in general what the expected use of this header is. > >> > >> My understanding is that it the relying party that is validating the cert chain is the one doing the HTTP fetching. > >> > >> In the case of application/pkix-cert, then only one DER cert is returned and that is the end-entity cert. > >> > >> My expectation for the way this would work is: > >> - The relying party would use HTTP to with the x5u URL to fetch the end-entity cert > >> - The relying party would have a trust anchor previously configured > >> - The certs in the chain between the end-entity are either already possess by the relying party or are in the x5bag header > >> - Then it is just a straight forward chain formation and validation. > >> > >> In this use, there is no requirement for security of the URL or for use of TLS to fetch it. All the necessary security is provided by standard chain validation. > >> > >> So why is there a requirement that the header be protected and that TLS/DTLS be used? > >> > >> Further, wouldn't the header protection be a form of self signing since the private key used to sign the header corresponds to the public key that is being fetched? > > > > It is in some sense a form of self-signing, yes. But TLS (or equivalent) > > is still needed for fetching the certificate in order to verify that the > > *certificate* received is the one intended, not a different certificate > > that wraps the same public key. There are plenty of attacks if you swap > > out the certificate for one with different key usage, SAN, etc. > > You might argue that it's hard to get a different cert (with > > attacker-controlled contents) for the same public key if the attacker > > doesn't have access to the corresponding private key, but that's not a very > > reliable security control. > > Hi Ben, > > It seems like your are interpreting the x5u header to be for the fetching > of a single validated end-entity certificate. Some remote service did the I do not believe I am doing so. The TLS (or other) authentication of the URI target does not inherently stand in for local validation of the certificate and chain. (There may be particular special cases arranged by policy where it does, but not in the general case.) I am saying that you can have multiple certificates, call them A and B, that certify the same public key K. Knowing K, you can validate the message signature, protected attributes, etc., including the URI used to fetch the certificate. However, if the URI used to fetch the certificate uses a scheme that does not provide integrity protection or server authentication, then the party dereferencing the URI could obtain certificate A when the message originator intended for certificate B to be used for validation. It is not too hard to imagine situations where both A and B can be used to build valid chains that end at root CAs trusted by the message recipient, and thus the insecure certificate fetch is (1) undetected and (2) causes the message to be interpreted differently than intended by the originator. As I mentioned originally, A and B could have different X.509 extensions, (extended) key usage, subject information, etc., so there is a lot of room for the "interpreted differently" to be attacked. > cert chain validation. You and other folks probably were involved in some > ace work that I was not involved with to know that. I don’t think it says > that clearly in cose-x509, though I can now see how you can triangulate > your way to that understanding. If x5u is to work like this, it seems a > lot of addition to security considerations is needed. > > RFC 2585 does not work this way. It assumes the chain validation is done locally (see RFC 2585 Security Considerations) and that there is no need for any transport layer security. This seems like a perfectly useful and good thing to do and to support in cose-x509. This is what I outlined in bullet points above. With RFC 2585 you know enough information about the *certificate* that you want that you have what is (supposed to be, at least) a unique identifier for the *certificate*. In the "x5u" case you only have information about a *key*, not a certificate. > > When I think about implementing cose-x509, I can see several options. > > 1. Just implement x5chain. Fail if x5chain is not present. Only need code for chain validation. No need for chain formation. > > 2. Just implement x5bag and x5t. Fail if x5t and x5bag are not present. Now you need code for chain validation and chain formation. > > 3. Just implement x5u. Fail if x5u is not present. All you need is some ASN.1 parsing and DTLS code. No chain validation or formation needed. > > 4. Implement all, with a priority order like first try x5chain, then try x5bag/x5t, finally x5u. > > 5. Various combinations of the above I believe that there is some intent to use x5t for cases where the certificates in question are already in local storage on both parties, so the thumbprint is just a shortand reference for "use this one [that you already have]"; no need for the x5bag. [Probably more comments possible here, but I didn't think very hard.] -Ben From nobody Thu Oct 22 13:57:06 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3E23A1016 for ; Thu, 22 Oct 2020 13:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 BAe6p-qXFd0b for ; Thu, 22 Oct 2020 13:57:02 -0700 (PDT) Received: from p3plsmtpa06-05.prod.phx3.secureserver.net (p3plsmtpa06-05.prod.phx3.secureserver.net [173.201.192.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEAE3A1014 for ; Thu, 22 Oct 2020 13:57:02 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id VhdrkIuSUv1NGVhdtku9du; Thu, 22 Oct 2020 13:57:01 -0700 X-CMAE-Analysis: v=2.3 cv=AbLP4EfG c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=sDQRfeqegHbcQtQrnFUA:9 a=QEXdDO2ut3YA:10 a=KJ-3KL52COQ7yHo4BFEA:9 a=qeKFUrn_r3UGwYlW:21 a=_W_S_7VecoQA:10 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <6A069E4A-C284-4245-B4DE-ADF707ACDC30@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C5D64EDB-B5A5-4C1A-8387-08DC655DB288" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Thu, 22 Oct 2020 13:56:58 -0700 In-Reply-To: <20201022191223.GH39170@kduck.mit.edu> Cc: cose To: Benjamin Kaduk References: <9284FE68-45D9-4282-8526-78914C3E3043@island-resort.com> <20201022152120.GA39170@kduck.mit.edu> <20201022191223.GH39170@kduck.mit.edu> X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4wfAWPc8E31AmNCiA1bcmn9LgSBm+0uP1iI7ggThvV4jsqdGjrM9Xbr1zfpOwH5Pv8EwkfObgej488KMH4Mzm790JB68SGRcmRjxkM+HBSNHnvb0hqtqwC TEvI0PRfaIX2We4zI1SO7B7vgpkkWco8/N14FycX8StrUNe1Ws7DTEdDp71bQZr/pZAJkNO4UF/osQ== Archived-At: Subject: Re: [COSE] draft-ietf-cose-x509-07 and x5u header 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, 22 Oct 2020 20:57:04 -0000 --Apple-Mail=_C5D64EDB-B5A5-4C1A-8387-08DC655DB288 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Below... > On Oct 22, 2020, at 12:12 PM, Benjamin Kaduk wrote: >=20 > Hi Laurence, >=20 > On Thu, Oct 22, 2020 at 11:56:24AM -0700, Laurence Lundblade wrote: >>=20 >>> On Oct 22, 2020, at 8:21 AM, Benjamin Kaduk wrote: >>>=20 >>> On Mon, Oct 19, 2020 at 11:40:33AM -0700, Laurence Lundblade wrote: >>>> I=E2=80=99m trying to understand why the x5u header must be a COSE = protected header parameter and in general what the expected use of this = header is. >>>>=20 >>>> My understanding is that it the relying party that is validating = the cert chain is the one doing the HTTP fetching. >>>>=20 >>>> In the case of application/pkix-cert, then only one DER cert is = returned and that is the end-entity cert. >>>>=20 >>>> My expectation for the way this would work is: >>>> - The relying party would use HTTP to with the x5u URL to fetch = the end-entity cert >>>> - The relying party would have a trust anchor previously = configured >>>> - The certs in the chain between the end-entity are either already = possess by the relying party or are in the x5bag header >>>> - Then it is just a straight forward chain formation and = validation.=20 >>>>=20 >>>> In this use, there is no requirement for security of the URL or for = use of TLS to fetch it. All the necessary security is provided by = standard chain validation. >>>>=20 >>>> So why is there a requirement that the header be protected and that = TLS/DTLS be used? >>>>=20 >>>> Further, wouldn't the header protection be a form of self signing = since the private key used to sign the header corresponds to the public = key that is being fetched? >>>=20 >>> It is in some sense a form of self-signing, yes. But TLS (or = equivalent) >>> is still needed for fetching the certificate in order to verify that = the >>> *certificate* received is the one intended, not a different = certificate >>> that wraps the same public key. There are plenty of attacks if you = swap >>> out the certificate for one with different key usage, SAN, etc. >>> You might argue that it's hard to get a different cert (with >>> attacker-controlled contents) for the same public key if the = attacker >>> doesn't have access to the corresponding private key, but that's not = a very >>> reliable security control. >>=20 >> Hi Ben,=20 >>=20 >> It seems like your are interpreting the x5u header to be for the = fetching >> of a single validated end-entity certificate. Some remote service did = the >=20 > I do not believe I am doing so. The TLS (or other) authentication of = the > URI target does not inherently stand in for local validation of the > certificate and chain. (There may be particular special cases = arranged by > policy where it does, but not in the general case.) >=20 > I am saying that you can have multiple certificates, call them A and = B, > that certify the same public key K. Knowing K, you can validate the > message signature, protected attributes, etc., including the URI used = to > fetch the certificate. However, if the URI used to fetch the = certificate > uses a scheme that does not provide integrity protection or server > authentication, then the party dereferencing the URI could obtain > certificate A when the message originator intended for certificate B = to be > used for validation. It is not too hard to imagine situations where = both A > and B can be used to build valid chains that end at root CAs trusted = by the > message recipient, and thus the insecure certificate fetch is (1) > undetected and (2) causes the message to be interpreted differently = than > intended by the originator. As I mentioned originally, A and B could = have > different X.509 extensions, (extended) key usage, subject information, > etc., so there is a lot of room for the "interpreted differently" to = be > attacked. But isn=E2=80=99t this a problem with any and all cert chain = construction and validation? If this is an issue, then x5bag and = x5chain should be protected headers. Seems like the real problem is CA operation. CA=E2=80=99s shouldn=E2=80=99= t be creating alternate certs for real keys that result in issues like = this. So it still seems to me that the primary reason for an x5u that is a = protected header parameter and obtained with DTLS is so you don=E2=80=99t = have to validate the end-entity on the constrained device. Presumably = you already have a DTLS stack, so you are almost getting the validated = cert for no extra code. >=20 >> cert chain validation. You and other folks probably were involved in = some >> ace work that I was not involved with to know that. I don=E2=80=99t = think it says >> that clearly in cose-x509, though I can now see how you can = triangulate >> your way to that understanding. If x5u is to work like this, it seems = a >> lot of addition to security considerations is needed. >>=20 >> RFC 2585 does not work this way. It assumes the chain validation is = done locally (see RFC 2585 Security Considerations) and that there is no = need for any transport layer security. This seems like a perfectly = useful and good thing to do and to support in cose-x509. This is what I = outlined in bullet points above. >=20 > With RFC 2585 you know enough information about the *certificate* that = you > want that you have what is (supposed to be, at least) a unique = identifier > for the *certificate*. In the "x5u" case you only have information = about a > *key*, not a certificate. I=E2=80=99m not understanding how x5u is about a key, not about a = certificate. >=20 >>=20 >> When I think about implementing cose-x509, I can see several options. >>=20 >> 1. Just implement x5chain. Fail if x5chain is not present. Only need = code for chain validation. No need for chain formation. >>=20 >> 2. Just implement x5bag and x5t. Fail if x5t and x5bag are not = present. Now you need code for chain validation and chain formation. >>=20 >> 3. Just implement x5u. Fail if x5u is not present. All you need is = some ASN.1 parsing and DTLS code. No chain validation or formation = needed. >>=20 >> 4. Implement all, with a priority order like first try x5chain, then = try x5bag/x5t, finally x5u. >>=20 >> 5. Various combinations of the above >=20 > I believe that there is some intent to use x5t for cases where the > certificates in question are already in local storage on both parties, = so > the thumbprint is just a shortand reference for "use this one [that = you > already have]"; no need for the x5bag. Yes, agreed. Might not even need any chain formation code if the = hierarchy is simple and certs are pre-distributed. > [Probably more comments possible here, but I didn't think very hard.] >=20 > -Ben LL --Apple-Mail=_C5D64EDB-B5A5-4C1A-8387-08DC655DB288 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Below...

On Oct 22, 2020, at 12:12 PM, = Benjamin Kaduk <kaduk@mit.edu> wrote:

Hi Laurence,

On Thu, Oct 22, 2020 at = 11:56:24AM -0700, Laurence Lundblade wrote:

On Oct 22, 2020, at 8:21 = AM, Benjamin Kaduk <kaduk@mit.edu> wrote:

On = Mon, Oct 19, 2020 at 11:40:33AM -0700, Laurence Lundblade wrote:
I=E2=80=99m trying to = understand why the x5u header must be a COSE protected header parameter = and in general what the expected use of this header is.

My understanding is that it the relying party that is = validating the cert chain is the one doing the HTTP fetching.

In the case of application/pkix-cert, then = only one DER cert is returned and that is the end-entity cert.

My expectation for the way this would work = is:
 - The relying party would use HTTP to with the = x5u URL to fetch the end-entity cert
 - The relying = party would have a trust anchor previously configured
 - The certs in the chain between the end-entity are = either already possess by the relying party or are in the x5bag = header
 - Then it is just a straight forward chain = formation and validation. 

In this use, there is no requirement for security of the URL = or for use of TLS to fetch it. All the necessary security is provided by = standard chain validation.

So why is there = a requirement that the header be protected and that TLS/DTLS be used?

Further, wouldn't the header protection be a = form of self signing since the private key used to sign the header = corresponds to the public key that is being fetched?

It is in some sense a form of = self-signing, yes.  But TLS (or equivalent)
is still = needed for fetching the certificate in order to verify that the
*certificate* received is the one intended, not a different = certificate
that wraps the same public key.  There = are plenty of attacks if you swap
out the certificate for = one with different key usage, SAN, etc.
You might argue = that it's hard to get a different cert (with
attacker-controlled contents) for the same public key if the = attacker
doesn't have access to the corresponding private = key, but that's not a very
reliable security control.

Hi Ben, 

It seems like your are interpreting the x5u header to be for = the fetching
of a single validated end-entity certificate. = Some remote service did the

I do not believe I am doing so. =  The TLS (or other) authentication of the
URI target does not inherently = stand in for local validation of the
certificate and chain.  (There may be particular special = cases arranged by
policy where it does, but not in the general case.)

I am saying that you can have = multiple certificates, call them A and B,
that certify the same public key K.  Knowing K, you can = validate the
message = signature, protected attributes, etc., including the URI used = to
fetch the = certificate.  However, if the URI used to fetch the = certificate
uses a scheme = that does not provide integrity protection or server
authentication, then the party = dereferencing the URI could obtain
certificate A when the message originator intended for = certificate B to be
used for validation.  It is not too hard to imagine = situations where both A
and B can be used to build valid chains that end at root CAs = trusted by the
message recipient, and thus the insecure certificate fetch is = (1)
undetected = and (2) causes the message to be interpreted differently than
intended by the originator. =  As I mentioned originally, A and B could have
different X.509 extensions, = (extended) key usage, subject information,
etc., so there is a lot of room for the "interpreted = differently" to be
attacked.

But isn=E2=80=99t this a problem with any and all cert = chain construction and validation?  If this is an issue, then x5bag = and x5chain should be protected headers.

Seems like the real problem is CA operation. = CA=E2=80=99s shouldn=E2=80=99t be creating alternate certs for real keys = that result in issues like this.

So = it still seems to me that the primary reason for an x5u that is a = protected header parameter and obtained with DTLS is so you don=E2=80=99t = have to validate the end-entity on the constrained device. Presumably = you already have a DTLS stack, so you are almost getting the validated = cert for no extra code.



cert = chain validation. You and other folks probably were involved in some
ace work that I was not involved with to know that. I don=E2=80= =99t think it says
that clearly in cose-x509, though I can = now see how you can triangulate
your way to that = understanding. If x5u is to work like this, it seems a
lot = of addition to security considerations is needed.

RFC 2585 does not work this way. It assumes the chain = validation is done locally (see RFC 2585 Security Considerations) and = that there is no need for any transport layer security. This seems like = a perfectly useful and good thing to do and to support in cose-x509. =  This is what I outlined in bullet points above.

With RFC 2585 you know enough information about the = *certificate* that you
want that you have what is (supposed to be, at least) a = unique identifier
for the *certificate*.  In the "x5u" case you only have = information about a
*key*, not a certificate.

I=E2=80=99m not understanding how x5u is about a = key, not about a certificate.



When I think about = implementing cose-x509, I can see several options.

1. Just implement x5chain. Fail if x5chain is not present. = Only need code for chain validation. No need for chain formation.

2. Just implement x5bag and x5t.  Fail if = x5t and x5bag are not present. Now you need code for chain validation = and chain formation.

3. Just implement x5u. = Fail if x5u is not present. All you need is some ASN.1 parsing and DTLS = code. No chain validation or formation needed.

4. Implement all, with a priority order like first try = x5chain, then try x5bag/x5t, finally x5u.

5. = Various combinations of the above

I believe that there is some = intent to use x5t for cases where the
certificates in question are already in local storage on both = parties, so
the = thumbprint is just a shortand reference for "use this one [that = you
already = have]"; no need for the x5bag.

Yes, agreed. Might not even need any chain = formation code if the hierarchy is simple and certs are = pre-distributed.

[Probably more comments possible here, but I didn't think = very hard.]

-Ben

LL

= --Apple-Mail=_C5D64EDB-B5A5-4C1A-8387-08DC655DB288-- From nobody Thu Oct 22 14:08: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 B64B73A104E for ; Thu, 22 Oct 2020 14:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKx9v6nHSTH3 for ; Thu, 22 Oct 2020 14:08:34 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450: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 C8DC23A104C for ; Thu, 22 Oct 2020 14:08:33 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id c16so5240846wmd.2 for ; Thu, 22 Oct 2020 14:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wSLqXDvy38MPaNb4+rkTTpLZzTBAoL7WWg9kDFz/nGM=; b=t6nFpQHjrAHeSUC/zzRub0XvEDOxrnFdE/4nE6rT2t6ADXClqgnwNa5dHO9xugD5dC xYy1OyODmHsAo/ZZyDnNbwNksQknWQJyQjYiUsToqkKgRjlrqttyugF/zhztWbMN8g7H rz+ld2LciMvc+r3N095WfP/9PWOv4EuX+JTJECF5LWtWV4jauDw+6GpOmx8e/dFu4HiE fx6zXLxCUYhHJJwcXHMI+CFmPipM0JeNDu08Y37ewGi+mYSeUY6Q5lSpdRAFp4GXQ6YO 4hgJ7lLy9I/am9hTaMxUIi7nowpkLnHradvun77Rp0qhFOobVaSoLI1MhWaTHIHiSDlp a8/Q== 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=wSLqXDvy38MPaNb4+rkTTpLZzTBAoL7WWg9kDFz/nGM=; b=Nr3ME8eiK6EshT7I5/AM1UC2FqruJKq+KyWfkGoK/foqgcY4xoxRhW4BRCBHMWTUoQ ucp7N0A/sYOe8fHOUsLPnyA3xAEznb6xy3mE7aR8C3f9MMesm6kfT5m0eobXMj+6Ceuu kx07UojpL2mqT6J1IMPV6pOhNGKvPz4MV95qIU+SmXJBtb/UGRtaED14hN84T4mSWsPx nlc9K1GfgAcoJOMKxMxgxt5O1EuuLHtTOuhq3imgqWc00xildq80HWtngF/hh87BkBpn d66W3/3/uKmxmntj1mtKza3DX/TBTjcrTPHDyMM9APEhnUaR87YS6mTOMXcwEnr+Llbd pu8Q== X-Gm-Message-State: AOAM530UYGYEJUFUKShuZyBzq0dN402VufjZ98UoZSvvAHEQFe9tODZj ePseQMXoZpBmZ93mkUy6Mgf6W095C7w3YB8qOWO8+w== X-Google-Smtp-Source: ABdhPJyK6HfVADcyDiChTb5wS4H1WRNphfmLrQKiewcey3+0NtgLHBScKMQlUgfWDYnBR21Jlfjiy8da+bFS7M/skEM= X-Received: by 2002:a1c:7214:: with SMTP id n20mr4288839wmc.93.1603400912234; Thu, 22 Oct 2020 14:08:32 -0700 (PDT) MIME-Version: 1.0 References: <160043970238.15995.10253324286831703129@ietfa.amsl.com> <75871395-45B4-4E22-B4AD-981D28216078@cooperw.in> In-Reply-To: <75871395-45B4-4E22-B4AD-981D28216078@cooperw.in> From: Ivaylo Petrov Date: Fri, 23 Oct 2020 00:08:06 +0300 Message-ID: To: alissa@cooperw.in Cc: Vijay Gurbani , Review Team , Last Call , draft-ietf-cose-x509.all@ietf.org, cose Content-Type: multipart/alternative; boundary="000000000000ce809905b248dde7" Archived-At: Subject: Re: [COSE] [Gen-art] Genart last call review of draft-ietf-cose-x509-07 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, 22 Oct 2020 21:08:37 -0000 --000000000000ce809905b248dde7 Content-Type: text/plain; charset="UTF-8" Thank you for your reviews! I will verify that those nits are fixed in the next version of the draft. On Thu, Oct 22, 2020 at 3:39 AM Alissa Cooper wrote: > Vijay, thanks for your review. I entered a No Objection ballot. > > Alissa > > > > On Sep 18, 2020, at 10:35 AM, Vijay Gurbani via Datatracker < > noreply@ietf.org> wrote: > > > > Reviewer: Vijay Gurbani > > Review result: Ready with Nits > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > . > > > > Document: draft-ietf-cose-x509-07 > > Reviewer: Vijay K. Gurbani > > Review Date: 2020-09-18 > > IETF LC End Date: 2020-10-01 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: Ready for publication with nits. > > > > Major issues: 0 > > > > Minor issues: 0 > > > > Nits/editorial comments: 5 > > > > (Sn refers to Section n) > > - S1: s/ad decided/and decided/ > > - S1: s/Since that time a/Since that time, a/ > > - S1: s/in the 6TiSCH environment [I-D.richardson-enrollment-roadmap], > > describes/in the 6TiSCH environment, [I-D.richardson-enrollment-roadmap] > > describes/ - S1: "A third scenario..." The wording seemed odd since > there is no > > text that sets the expectation that there will be three scenarios for > > discussion. If your intent is to enumerate the different scenarios, > probably > > best to prepare the reader for this ahead of time. - S2: s/which it can > then > > provide to/that it subsequently provides to/ > > > > > > > > _______________________________________________ > > Gen-art mailing list > > Gen-art@ietf.org > > https://www.ietf.org/mailman/listinfo/gen-art > > --000000000000ce809905b248dde7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your reviews! I will verify that th= ose nits are fixed in the next version of the draft.
=


On Thu, Oct 22, 2020 at 3:39 AM Ali= ssa Cooper <alissa@cooperw.in&g= t; wrote:
Vijay,= thanks for your review. I entered a No Objection ballot.

Alissa


> On Sep 18, 2020, at 10:35 AM, Vijay Gurbani via Datatracker <noreply@ietf.org> wr= ote:
>
> Reviewer: Vijay Gurbani
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.=C2=A0 Please treat these comments just=
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq<= /a>>.
>
> Document: draft-ietf-cose-x509-07
> Reviewer: Vijay K. Gurbani
> Review Date: 2020-09-18
> IETF LC End Date: 2020-10-01
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: Ready for publication with nits.
>
> Major issues: 0
>
> Minor issues: 0
>
> Nits/editorial comments: 5
>
> (Sn refers to Section n)
> - S1: s/ad decided/and decided/
> - S1: s/Since that time a/Since that time, a/
> - S1: s/in the 6TiSCH environment [I-D.richardson-enrollment-roadmap],=
> describes/in the 6TiSCH environment, [I-D.richardson-enrollment-roadma= p]
> describes/ - S1: "A third scenario..." The wording seemed od= d since there is no
> text that sets the expectation that there will be three scenarios for<= br> > discussion.=C2=A0 If your intent is to enumerate the different scenari= os, probably
> best to prepare the reader for this ahead of time. - S2: s/which it ca= n then
> provide to/that it subsequently provides to/
>
>
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org=
> https://www.ietf.org/mailman/listinfo/gen-art<= br>
--000000000000ce809905b248dde7-- From nobody Thu Oct 22 14:18: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 631693A106D for ; Thu, 22 Oct 2020 14:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiZR41SRdK0U for ; Thu, 22 Oct 2020 14:18:13 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988013A1067 for ; Thu, 22 Oct 2020 14:18:13 -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 09MLI5BF012839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Oct 2020 17:18:11 -0400 Date: Thu, 22 Oct 2020 14:18:04 -0700 From: Benjamin Kaduk To: Laurence Lundblade Cc: cose Message-ID: <20201022211804.GI39170@kduck.mit.edu> References: <9284FE68-45D9-4282-8526-78914C3E3043@island-resort.com> <20201022152120.GA39170@kduck.mit.edu> <20201022191223.GH39170@kduck.mit.edu> <6A069E4A-C284-4245-B4DE-ADF707ACDC30@island-resort.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6A069E4A-C284-4245-B4DE-ADF707ACDC30@island-resort.com> Archived-At: Subject: Re: [COSE] draft-ietf-cose-x509-07 and x5u header 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, 22 Oct 2020 21:18:15 -0000 On Thu, Oct 22, 2020 at 01:56:58PM -0700, Laurence Lundblade wrote: > Below... > > > On Oct 22, 2020, at 12:12 PM, Benjamin Kaduk wrote: > > > > Hi Laurence, > > > > On Thu, Oct 22, 2020 at 11:56:24AM -0700, Laurence Lundblade wrote: > >> > >>> On Oct 22, 2020, at 8:21 AM, Benjamin Kaduk wrote: > >>> > >>> On Mon, Oct 19, 2020 at 11:40:33AM -0700, Laurence Lundblade wrote: > >>>> I’m trying to understand why the x5u header must be a COSE protected header parameter and in general what the expected use of this header is. > >>>> > >>>> My understanding is that it the relying party that is validating the cert chain is the one doing the HTTP fetching. > >>>> > >>>> In the case of application/pkix-cert, then only one DER cert is returned and that is the end-entity cert. > >>>> > >>>> My expectation for the way this would work is: > >>>> - The relying party would use HTTP to with the x5u URL to fetch the end-entity cert > >>>> - The relying party would have a trust anchor previously configured > >>>> - The certs in the chain between the end-entity are either already possess by the relying party or are in the x5bag header > >>>> - Then it is just a straight forward chain formation and validation. > >>>> > >>>> In this use, there is no requirement for security of the URL or for use of TLS to fetch it. All the necessary security is provided by standard chain validation. > >>>> > >>>> So why is there a requirement that the header be protected and that TLS/DTLS be used? > >>>> > >>>> Further, wouldn't the header protection be a form of self signing since the private key used to sign the header corresponds to the public key that is being fetched? > >>> > >>> It is in some sense a form of self-signing, yes. But TLS (or equivalent) > >>> is still needed for fetching the certificate in order to verify that the > >>> *certificate* received is the one intended, not a different certificate > >>> that wraps the same public key. There are plenty of attacks if you swap > >>> out the certificate for one with different key usage, SAN, etc. > >>> You might argue that it's hard to get a different cert (with > >>> attacker-controlled contents) for the same public key if the attacker > >>> doesn't have access to the corresponding private key, but that's not a very > >>> reliable security control. > >> > >> Hi Ben, > >> > >> It seems like your are interpreting the x5u header to be for the fetching > >> of a single validated end-entity certificate. Some remote service did the > > > > I do not believe I am doing so. The TLS (or other) authentication of the > > URI target does not inherently stand in for local validation of the > > certificate and chain. (There may be particular special cases arranged by > > policy where it does, but not in the general case.) > > > > I am saying that you can have multiple certificates, call them A and B, > > that certify the same public key K. Knowing K, you can validate the > > message signature, protected attributes, etc., including the URI used to > > fetch the certificate. However, if the URI used to fetch the certificate > > uses a scheme that does not provide integrity protection or server > > authentication, then the party dereferencing the URI could obtain > > certificate A when the message originator intended for certificate B to be > > used for validation. It is not too hard to imagine situations where both A > > and B can be used to build valid chains that end at root CAs trusted by the > > message recipient, and thus the insecure certificate fetch is (1) > > undetected and (2) causes the message to be interpreted differently than > > intended by the originator. As I mentioned originally, A and B could have > > different X.509 extensions, (extended) key usage, subject information, > > etc., so there is a lot of room for the "interpreted differently" to be > > attacked. > > But isn’t this a problem with any and all cert chain construction and validation? If this is an issue, then x5bag and x5chain should be protected headers. No; once you have a (EE) cert, you have Issuer information to find the next cert in the chain. With just a COSE message you don't have that. > Seems like the real problem is CA operation. CA’s shouldn’t be creating alternate certs for real keys that result in issues like this. Most of the time, for most scenarios. But this is not a reliable security control. > So it still seems to me that the primary reason for an x5u that is a protected header parameter and obtained with DTLS is so you don’t have to validate the end-entity on the constrained device. Presumably you already have a DTLS stack, so you are almost getting the validated cert for no extra code. I disagree. > > > > >> cert chain validation. You and other folks probably were involved in some > >> ace work that I was not involved with to know that. I don’t think it says > >> that clearly in cose-x509, though I can now see how you can triangulate > >> your way to that understanding. If x5u is to work like this, it seems a > >> lot of addition to security considerations is needed. > >> > >> RFC 2585 does not work this way. It assumes the chain validation is done locally (see RFC 2585 Security Considerations) and that there is no need for any transport layer security. This seems like a perfectly useful and good thing to do and to support in cose-x509. This is what I outlined in bullet points above. > > > > With RFC 2585 you know enough information about the *certificate* that you > > want that you have what is (supposed to be, at least) a unique identifier > > for the *certificate*. In the "x5u" case you only have information about a > > *key*, not a certificate. > > I’m not understanding how x5u is about a key, not about a certificate. The key is the only thing tying the COSE message to the certificate; other information in the certificate (e.g., SubjectPublicKeyInfo) is not available when processing the COSE message. Let me try to walk through some steps: You have a COSE message; say it's a signed message. The recipient has the (plain)text, the actual signature bytes, and the parameters, including x5u. If the recipient verifies the signature, they know that the x5u URI is the one intended by the holder of the private key that made the signature. (In order to validate the signature, they presumably have to obtain the certificate first, but we're getting there.) The only thing that ties the received message to the certificate obtained by dereferencing the URI is the signature in the message itself. That signature does not contain or include any attributes of the certificate containing the public key corresponding to the private key that made the signature; there is no SubjectPublicKeyInfo or similar in the COSE message. The only thing needed to validate the signature is the public key in question. In principle that public key could be obtained in many ways (it could have been included as a COSE_Key for that matter), but in the x5u case, we're supposed to get that public key from a certificate found at a particular URI. But the way that I tie the message+signature to the certificate is by using the public key in the certificate to validate the signature on the message. So, it is the public key that is what I use to find the certificate that is associated with the signature, but there is not a unique mapping from public key to certificate, in general. In order for the signing party to be confident that the recipient interprets the signature properly, there has to be a chain of custody from the message+signature to the intended certificate. Using coap-not-s to obtain the certificate breakas the chain of custody -- in extreme cases the message could appear to have been generated by a completely different entity than it actually was! -Ben > > > >> > >> When I think about implementing cose-x509, I can see several options. > >> > >> 1. Just implement x5chain. Fail if x5chain is not present. Only need code for chain validation. No need for chain formation. > >> > >> 2. Just implement x5bag and x5t. Fail if x5t and x5bag are not present. Now you need code for chain validation and chain formation. > >> > >> 3. Just implement x5u. Fail if x5u is not present. All you need is some ASN.1 parsing and DTLS code. No chain validation or formation needed. > >> > >> 4. Implement all, with a priority order like first try x5chain, then try x5bag/x5t, finally x5u. > >> > >> 5. Various combinations of the above > > > > I believe that there is some intent to use x5t for cases where the > > certificates in question are already in local storage on both parties, so > > the thumbprint is just a shortand reference for "use this one [that you > > already have]"; no need for the x5bag. > > Yes, agreed. Might not even need any chain formation code if the hierarchy is simple and certs are pre-distributed. > > > [Probably more comments possible here, but I didn't think very hard.] > > > > -Ben > > LL > From nobody Fri Oct 23 12:02:32 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7043A128F for ; Fri, 23 Oct 2020 12:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 Y2uuPS4g8o9e for ; Fri, 23 Oct 2020 12:02:26 -0700 (PDT) Received: from p3plsmtpa12-09.prod.phx3.secureserver.net (p3plsmtpa12-09.prod.phx3.secureserver.net [68.178.252.238]) (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 45EC33A12A5 for ; Fri, 23 Oct 2020 12:02:08 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id W2KEkERBXaH1HW2KEkIRmV; Fri, 23 Oct 2020 12:02:06 -0700 X-CMAE-Analysis: v=2.4 cv=f+mNuM+M c=1 sm=1 tr=0 ts=5f9328af a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=48vgC7mUAAAA:8 a=ocnbKTyJfoPRQxfWJUgA:9 a=0Qa0F1IqZDSnEF6N:21 a=Rpwd5W29VEUZUxVT:21 a=QEXdDO2ut3YA:10 a=qUoPElG5t2PH5JovimkA:9 a=x5o8FK3KaTZioFTB:21 a=MoEMpKfmSDptkVfV:21 a=OFrWZg0pZcVeydpA:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_991FD6D0-7A7A-4CF2-BEA9-EA927629C59F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Fri, 23 Oct 2020 12:02:06 -0700 In-Reply-To: <20201022211804.GI39170@kduck.mit.edu> Cc: cose To: Benjamin Kaduk References: <9284FE68-45D9-4282-8526-78914C3E3043@island-resort.com> <20201022152120.GA39170@kduck.mit.edu> <20201022191223.GH39170@kduck.mit.edu> <6A069E4A-C284-4245-B4DE-ADF707ACDC30@island-resort.com> <20201022211804.GI39170@kduck.mit.edu> X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4xfD80sFrcTk2pklrfFuLaANH0MkLv3iSA1KScadSDButLbkn1iTKP6V0zfSgYVAvq7/ByRMNCmCAbMLoR3C952eJG6rO9IF1ZCX7XIgaEKJi108xzy//C zjLSmWADV8HRD04yOXsi9OxrJoO2Tzme69AzIrIlB2W3Z8zH6oT3PznCsoz4BQUjicrXlipHa4YRAiMef++lmb/MrtxGFljNejU= Archived-At: Subject: Re: [COSE] draft-ietf-cose-x509-07 and x5u header 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, 23 Oct 2020 19:02:30 -0000 --Apple-Mail=_991FD6D0-7A7A-4CF2-BEA9-EA927629C59F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK. Got it. Thanks for writing it out. I think that means identification of an end-entity cert must usually be = covered by the signature. Since x5t and x5chain identify end-entity = certs, they should be protected headers. =46rom an attackers point of = view the unprotected headers can be manipulated to the same result as an = x5u if it were unprotected. It is spelled out clearly here in Key Identification in RFC 7517 = (JWS). Seems like = cose-x509 needs similar text. It seems like you could combine a protected x5t with an unprotected x5u = to get the same result. Fetch the cert with x5u, then make sure it is = right with x5t. I spent some time reading CMS, RFC 5652. It does not seem to address = this. The SignerIdentifier which identifies the end-entity cert does not = seem to be covered by the signature. This seems like an omission in CMS. If I=E2=80=99d read RFC 7515 before I read cose-x509, I would have been = much less confused and caused a lot less trouble here. LL > On Oct 22, 2020, at 2:18 PM, Benjamin Kaduk wrote: >=20 > On Thu, Oct 22, 2020 at 01:56:58PM -0700, Laurence Lundblade wrote: >> Below... >>=20 >>> On Oct 22, 2020, at 12:12 PM, Benjamin Kaduk wrote: >>>=20 >>> Hi Laurence, >>>=20 >>> On Thu, Oct 22, 2020 at 11:56:24AM -0700, Laurence Lundblade wrote: >>>>=20 >>>>> On Oct 22, 2020, at 8:21 AM, Benjamin Kaduk wrote: >>>>>=20 >>>>> On Mon, Oct 19, 2020 at 11:40:33AM -0700, Laurence Lundblade = wrote: >>>>>> I=E2=80=99m trying to understand why the x5u header must be a = COSE protected header parameter and in general what the expected use of = this header is. >>>>>>=20 >>>>>> My understanding is that it the relying party that is validating = the cert chain is the one doing the HTTP fetching. >>>>>>=20 >>>>>> In the case of application/pkix-cert, then only one DER cert is = returned and that is the end-entity cert. >>>>>>=20 >>>>>> My expectation for the way this would work is: >>>>>> - The relying party would use HTTP to with the x5u URL to fetch = the end-entity cert >>>>>> - The relying party would have a trust anchor previously = configured >>>>>> - The certs in the chain between the end-entity are either = already possess by the relying party or are in the x5bag header >>>>>> - Then it is just a straight forward chain formation and = validation.=20 >>>>>>=20 >>>>>> In this use, there is no requirement for security of the URL or = for use of TLS to fetch it. All the necessary security is provided by = standard chain validation. >>>>>>=20 >>>>>> So why is there a requirement that the header be protected and = that TLS/DTLS be used? >>>>>>=20 >>>>>> Further, wouldn't the header protection be a form of self signing = since the private key used to sign the header corresponds to the public = key that is being fetched? >>>>>=20 >>>>> It is in some sense a form of self-signing, yes. But TLS (or = equivalent) >>>>> is still needed for fetching the certificate in order to verify = that the >>>>> *certificate* received is the one intended, not a different = certificate >>>>> that wraps the same public key. There are plenty of attacks if = you swap >>>>> out the certificate for one with different key usage, SAN, etc. >>>>> You might argue that it's hard to get a different cert (with >>>>> attacker-controlled contents) for the same public key if the = attacker >>>>> doesn't have access to the corresponding private key, but that's = not a very >>>>> reliable security control. >>>>=20 >>>> Hi Ben,=20 >>>>=20 >>>> It seems like your are interpreting the x5u header to be for the = fetching >>>> of a single validated end-entity certificate. Some remote service = did the >>>=20 >>> I do not believe I am doing so. The TLS (or other) authentication = of the >>> URI target does not inherently stand in for local validation of the >>> certificate and chain. (There may be particular special cases = arranged by >>> policy where it does, but not in the general case.) >>>=20 >>> I am saying that you can have multiple certificates, call them A and = B, >>> that certify the same public key K. Knowing K, you can validate the >>> message signature, protected attributes, etc., including the URI = used to >>> fetch the certificate. However, if the URI used to fetch the = certificate >>> uses a scheme that does not provide integrity protection or server >>> authentication, then the party dereferencing the URI could obtain >>> certificate A when the message originator intended for certificate B = to be >>> used for validation. It is not too hard to imagine situations where = both A >>> and B can be used to build valid chains that end at root CAs trusted = by the >>> message recipient, and thus the insecure certificate fetch is (1) >>> undetected and (2) causes the message to be interpreted differently = than >>> intended by the originator. As I mentioned originally, A and B = could have >>> different X.509 extensions, (extended) key usage, subject = information, >>> etc., so there is a lot of room for the "interpreted differently" to = be >>> attacked. >>=20 >> But isn=E2=80=99t this a problem with any and all cert chain = construction and validation? If this is an issue, then x5bag and = x5chain should be protected headers. >=20 > No; once you have a (EE) cert, you have Issuer information to find the > next cert in the chain. With just a COSE message you don't have that. >=20 >> Seems like the real problem is CA operation. CA=E2=80=99s shouldn=E2=80= =99t be creating alternate certs for real keys that result in issues = like this. >=20 > Most of the time, for most scenarios. But this is not a reliable = security > control. >=20 >> So it still seems to me that the primary reason for an x5u that is a = protected header parameter and obtained with DTLS is so you don=E2=80=99t = have to validate the end-entity on the constrained device. Presumably = you already have a DTLS stack, so you are almost getting the validated = cert for no extra code. >=20 > I disagree. >=20 >>=20 >>>=20 >>>> cert chain validation. You and other folks probably were involved = in some >>>> ace work that I was not involved with to know that. I don=E2=80=99t = think it says >>>> that clearly in cose-x509, though I can now see how you can = triangulate >>>> your way to that understanding. If x5u is to work like this, it = seems a >>>> lot of addition to security considerations is needed. >>>>=20 >>>> RFC 2585 does not work this way. It assumes the chain validation is = done locally (see RFC 2585 Security Considerations) and that there is no = need for any transport layer security. This seems like a perfectly = useful and good thing to do and to support in cose-x509. This is what I = outlined in bullet points above. >>>=20 >>> With RFC 2585 you know enough information about the *certificate* = that you >>> want that you have what is (supposed to be, at least) a unique = identifier >>> for the *certificate*. In the "x5u" case you only have information = about a >>> *key*, not a certificate. >>=20 >> I=E2=80=99m not understanding how x5u is about a key, not about a = certificate. >=20 > The key is the only thing tying the COSE message to the certificate; = other > information in the certificate (e.g., SubjectPublicKeyInfo) is not > available when processing the COSE message. Let me try to walk = through > some steps: >=20 > You have a COSE message; say it's a signed message. The recipient has = the > (plain)text, the actual signature bytes, and the parameters, including = x5u. > If the recipient verifies the signature, they know that the x5u URI is = the > one intended by the holder of the private key that made the signature. = (In > order to validate the signature, they presumably have to obtain the > certificate first, but we're getting there.) The only thing that ties = the > received message to the certificate obtained by dereferencing the URI = is > the signature in the message itself. That signature does not contain = or > include any attributes of the certificate containing the public key > corresponding to the private key that made the signature; there is no > SubjectPublicKeyInfo or similar in the COSE message. The only thing > needed to validate the signature is the public key in question. In > principle that public key could be obtained in many ways (it could = have > been included as a COSE_Key for that matter), but in the x5u case, = we're > supposed to get that public key from a certificate found at a = particular > URI. But the way that I tie the message+signature to the certificate = is by > using the public key in the certificate to validate the signature on = the > message. So, it is the public key that is what I use to find the > certificate that is associated with the signature, but there is not a > unique mapping from public key to certificate, in general. In order = for > the signing party to be confident that the recipient interprets the > signature properly, there has to be a chain of custody from the > message+signature to the intended certificate. Using coap-not-s to = obtain > the certificate breakas the chain of custody -- in extreme cases the > message could appear to have been generated by a completely different > entity than it actually was! >=20 > -Ben >=20 >>>=20 >>>>=20 >>>> When I think about implementing cose-x509, I can see several = options. >>>>=20 >>>> 1. Just implement x5chain. Fail if x5chain is not present. Only = need code for chain validation. No need for chain formation. >>>>=20 >>>> 2. Just implement x5bag and x5t. Fail if x5t and x5bag are not = present. Now you need code for chain validation and chain formation. >>>>=20 >>>> 3. Just implement x5u. Fail if x5u is not present. All you need is = some ASN.1 parsing and DTLS code. No chain validation or formation = needed. >>>>=20 >>>> 4. Implement all, with a priority order like first try x5chain, = then try x5bag/x5t, finally x5u. >>>>=20 >>>> 5. Various combinations of the above >>>=20 >>> I believe that there is some intent to use x5t for cases where the >>> certificates in question are already in local storage on both = parties, so >>> the thumbprint is just a shortand reference for "use this one [that = you >>> already have]"; no need for the x5bag. >>=20 >> Yes, agreed. Might not even need any chain formation code if the = hierarchy is simple and certs are pre-distributed. >>=20 >>> [Probably more comments possible here, but I didn't think very = hard.] >>>=20 >>> -Ben >>=20 >> LL >>=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_991FD6D0-7A7A-4CF2-BEA9-EA927629C59F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OK. = Got it. Thanks for writing it out.

I think that means = identification of an end-entity cert must usually be covered by the = signature. Since x5t and x5chain identify end-entity certs, they should = be protected headers. =46rom an attackers point of view the unprotected = headers can be manipulated to the same result as an x5u if it were = unprotected.

It = is spelled out clearly here in Key = Identification in RFC 7517 (JWS). Seems like cose-x509 needs = similar text.

It= seems like you could combine a protected x5t with an unprotected x5u to = get the same result. Fetch the cert with x5u, then make sure it is right = with x5t.

I = spent some time reading CMS, RFC 5652. It does not seem to address this. = The SignerIdentifier which = identifies the end-entity cert does not seem to be covered by the = signature. This seems like an omission in CMS.

If I=E2=80=99d read RFC 7515 before I = read cose-x509, I would have been much less confused and caused a lot = less trouble here.

LL



On = Oct 22, 2020, at 2:18 PM, Benjamin Kaduk <kaduk@mit.edu> = wrote:

On Thu, Oct 22, 2020 at = 01:56:58PM -0700, Laurence Lundblade wrote:
Below...

On Oct 22, 2020, at 12:12 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:

Hi Laurence,

On = Thu, Oct 22, 2020 at 11:56:24AM -0700, Laurence Lundblade wrote:

On Oct 22, 2020, at 8:21 AM, Benjamin Kaduk = <kaduk@mit.edu> = wrote:

On Mon, Oct 19, 2020 at 11:40:33AM = -0700, Laurence Lundblade wrote:
I=E2=80=99m trying to understand why the x5u header must be a = COSE protected header parameter and in general what the expected use of = this header is.

My understanding is that it = the relying party that is validating the cert chain is the one doing the = HTTP fetching.

In the case of = application/pkix-cert, then only one DER cert is returned and that is = the end-entity cert.

My expectation for the = way this would work is:
- The relying party would use HTTP = to with the x5u URL to fetch the end-entity cert
- The = relying party would have a trust anchor previously configured
- The certs in the chain between the end-entity are either = already possess by the relying party or are in the x5bag header
- Then it is just a straight forward chain formation and = validation. 

In this use, there is no requirement for = security of the URL or for use of TLS to fetch it. All the necessary = security is provided by standard chain validation.

So why is there a requirement that the header be protected = and that TLS/DTLS be used?

Further, = wouldn't the header protection be a form of self signing since the = private key used to sign the header corresponds to the public key that = is being fetched?

It is in = some sense a form of self-signing, yes.  But TLS (or equivalent)
is still needed for fetching the certificate in order to = verify that the
*certificate* received is the one = intended, not a different certificate
that wraps the same = public key.  There are plenty of attacks if you swap
out the certificate for one with different key usage, SAN, = etc.
You might argue that it's hard to get a different = cert (with
attacker-controlled contents) for the same = public key if the attacker
doesn't have access to the = corresponding private key, but that's not a very
reliable = security control.

Hi Ben, 

It seems like your are interpreting the x5u header to be for = the fetching
of a single validated end-entity certificate. = Some remote service did the

I = do not believe I am doing so.  The TLS (or other) authentication of = the
URI target does not inherently stand in for local = validation of the
certificate and chain.  (There may = be particular special cases arranged by
policy where it = does, but not in the general case.)

I am = saying that you can have multiple certificates, call them A and B,
that certify the same public key K.  Knowing K, you can = validate the
message signature, protected attributes, = etc., including the URI used to
fetch the certificate. =  However, if the URI used to fetch the certificate
uses= a scheme that does not provide integrity protection or server
authentication, then the party dereferencing the URI could = obtain
certificate A when the message originator intended = for certificate B to be
used for validation.  It is = not too hard to imagine situations where both A
and B can = be used to build valid chains that end at root CAs trusted by the
message recipient, and thus the insecure certificate fetch is = (1)
undetected and (2) causes the message to be = interpreted differently than
intended by the originator. =  As I mentioned originally, A and B could have
different X.509 extensions, (extended) key usage, subject = information,
etc., so there is a lot of room for the = "interpreted differently" to be
attacked.

But isn=E2=80=99t this a problem = with any and all cert chain construction and validation?  If this = is an issue, then x5bag and x5chain should be protected headers.

No; once you have a (EE) cert, you have Issuer information to = find the
next cert in = the chain.  With just a COSE message you don't have that.

Seems = like the real problem is CA operation. CA=E2=80=99s shouldn=E2=80=99t be = creating alternate certs for real keys that result in issues like = this.

Most of the time, for most scenarios.  But this is not a = reliable security
control.

So it still seems to me that the = primary reason for an x5u that is a protected header parameter and = obtained with DTLS is so you don=E2=80=99t have to validate the = end-entity on the constrained device. Presumably you already have a DTLS = stack, so you are almost getting the validated cert for no extra = code.

I disagree.



cert chain validation. You and other folks probably were = involved in some
ace work that I was not involved with to = know that. I don=E2=80=99t think it says
that clearly in = cose-x509, though I can now see how you can triangulate
your= way to that understanding. If x5u is to work like this, it seems a
lot of addition to security considerations is needed.

RFC 2585 does not work this way. It assumes = the chain validation is done locally (see RFC 2585 Security = Considerations) and that there is no need for any transport layer = security. This seems like a perfectly useful and good thing to do and to = support in cose-x509.  This is what I outlined in bullet points = above.

With RFC 2585 you know = enough information about the *certificate* that you
want = that you have what is (supposed to be, at least) a unique identifier
for the *certificate*.  In the "x5u" case you only have = information about a
*key*, not a certificate.

I=E2=80=99m not understanding how = x5u is about a key, not about a certificate.

The key is the only thing tying the COSE message to the = certificate; other
information in the certificate (e.g., SubjectPublicKeyInfo) = is not
available = when processing the COSE message.  Let me try to walk = through
some = steps:

You have a = COSE message; say it's a signed message.  The recipient has = the
(plain)text, = the actual signature bytes, and the parameters, including x5u.
If the recipient verifies the = signature, they know that the x5u URI is the
one intended by the holder of = the private key that made the signature.  (In
order to validate the signature, = they presumably have to obtain the
certificate first, but we're getting there.)  The only = thing that ties the
received message to the certificate obtained by dereferencing = the URI is
the signature = in the message itself.  That signature does not contain = or
include any = attributes of the certificate containing the public key
corresponding to the private key = that made the signature; there is no
SubjectPublicKeyInfo or similar in the COSE message. =  The only thing
needed to validate the signature is the public key in = question.  In
principle that public key could be obtained in many ways (it = could have
been included = as a COSE_Key for that matter), but in the x5u case, we're
supposed to get that public key = from a certificate found at a particular
URI.  But the way that I tie the message+signature to = the certificate is by
using the public key in the certificate to validate the = signature on the
message.  So, it is the public key that is what I use to = find the
certificate = that is associated with the signature, but there is not a
unique mapping from public key = to certificate, in general.  In order for
the signing party to be = confident that the recipient interprets the
signature properly, there has to = be a chain of custody from the
message+signature to the intended certificate.  Using = coap-not-s to obtain
the certificate breakas the chain of custody -- in extreme = cases the
message could = appear to have been generated by a completely different
entity than it actually = was!

-Ben



When I think about implementing = cose-x509, I can see several options.

1. = Just implement x5chain. Fail if x5chain is not present. Only need code = for chain validation. No need for chain formation.

2. Just implement x5bag and x5t.  Fail if x5t and x5bag = are not present. Now you need code for chain validation and chain = formation.

3. Just implement x5u. Fail if = x5u is not present. All you need is some ASN.1 parsing and DTLS code. No = chain validation or formation needed.

4. = Implement all, with a priority order like first try x5chain, then try = x5bag/x5t, finally x5u.

5. Various = combinations of the above

I = believe that there is some intent to use x5t for cases where the
certificates in question are already in local storage on both = parties, so
the thumbprint is just a shortand reference = for "use this one [that you
already have]"; no need for = the x5bag.

Yes, agreed. Might = not even need any chain formation code if the hierarchy is simple and = certs are pre-distributed.

[Probably more comments possible here, but I = didn't think very hard.]

-Ben

LL


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

= --Apple-Mail=_991FD6D0-7A7A-4CF2-BEA9-EA927629C59F-- From nobody Fri Oct 23 12:11:10 2020 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA33B3A1355 for ; Fri, 23 Oct 2020 12:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 1vK76-tDvZlp for ; Fri, 23 Oct 2020 12:11:06 -0700 (PDT) Received: from p3plsmtpa06-09.prod.phx3.secureserver.net (p3plsmtpa06-09.prod.phx3.secureserver.net [173.201.192.110]) (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 19BBF3A1357 for ; Fri, 23 Oct 2020 12:11:06 -0700 (PDT) Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id W2Svk1lu3FEkAW2SvkPJgJ; Fri, 23 Oct 2020 12:11:05 -0700 X-CMAE-Analysis: v=2.4 cv=QbCjAuXv c=1 sm=1 tr=0 ts=5f932ac9 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=K6EGIJCdAAAA:8 a=48vgC7mUAAAA:8 a=UPGJrdY-DB1JySJ4pBkA:9 a=QEXdDO2ut3YA:10 a=T6nxoV7N0hILLgTO9_wA:9 a=v8URyKlVhoe3pyAe:21 a=_W_S_7VecoQA:10 a=L6pVIi0Kn1GYQfi8-iRI:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_441A7B84-B096-44FE-A577-22DEEE823160" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Fri, 23 Oct 2020 12:11:04 -0700 In-Reply-To: <0CF2598E-61CD-4011-9E97-1B28C7DB4065@island-resort.com> Cc: cose , cose-chairs@ietf.org, draft-ietf-cose-x509@ietf.org, The IESG , ivaylo@ackl.io To: Magnus Westerlund References: <160336909147.3199.13133404901002626604@ietfa.amsl.com> <0CF2598E-61CD-4011-9E97-1B28C7DB4065@island-resort.com> X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4xfI4se5kyuw/mHFkILKyI917+msMGA9h9TSUW4+UIk/3wEh9IdvRSH9eYDPNhgS5WFXjyzDjlr6cVV/YLlX/uJACkWm+fWCkpBfifjZr1jqnKTfbJ3UgJ 4LUpozNxUlggPFH+fffEAntrxWROZRBFE5SUgdntpYYwIqSlyTLE85LYs9ACOCg2EAKYY5jqMKybvQBqtv/UtNkohQ4dvIIqtE84DUPrKTF0cKNWd5aOjcpr 9edtJsqRJiFSbgGCxuP7wTY2k1pv0QmTj3u9zAZ8EHeimrgGcXz7X9Yrepg2NYqSzQ5ciY7aT+aTPb2WWBwqnSGkExAQolNxHd+bTACnvazhHTHEiFouYxd6 7fzNtjmg Archived-At: Subject: Re: [COSE] Magnus Westerlund's Discuss on draft-ietf-cose-x509-07: (with 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, 23 Oct 2020 19:11:08 -0000 --Apple-Mail=_441A7B84-B096-44FE-A577-22DEEE823160 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We had a good discussion on key / cert identification for EAT / RATS at = our virtual interim meeting today. There seems to be consensus support = for use of cose-x509. LL > On Oct 22, 2020, at 11:17 AM, Laurence Lundblade = wrote: >=20 > I would like to see it as standards track. >=20 > I would like EAT / RATS to make normative reference to it. Some forms = of Attestation use Endorsements to convey a signature verification key = to the Verifier and some Endorsements are in the form of an X.509 = certificate. >=20 > I will present some of this at the RATS virtual interim tomorrow = . = Slides are here = . This is why I=E2=80=99ve been so = interested in this lately. >=20 > Also, it seems pretty important for COSE to be usable with the all the = X.509 infrastructure out there. >=20 > LL >=20 >=20 >> On Oct 22, 2020, at 5:18 AM, Magnus Westerlund via Datatracker = > wrote: >>=20 >> ... >> I think the topic should be fairly easily to resolve one way or = another. >> However, even after having read the reply to Marin's comment I don't = think this >> document is published with the right status. >>=20 >> - The document defines new CBOR attributes, that is standard track = work as it >> comes out as consensus document from a IETF WG. - It does not define = or >> document crypto algorithm just refer to existing ones. - The charter = item might >> have been reasonable as informational if existing attributes could = have been >> used. With the choice to define new attributes I think this has = entered >> standards track. - The status of the document I think will also = affect the >> value that IANA might assign to these COSE Header Parameters. >>=20 >> If there are additional considerations I am happy to learn about = them. >>=20 >> Else, I would propose a change of status to proposed standard and = redo the IETF >> last call. >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >>=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose = --Apple-Mail=_441A7B84-B096-44FE-A577-22DEEE823160 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
We had a good discussion on key / cert identification for EAT = / RATS at our virtual interim meeting today. There seems to be consensus = support for use of cose-x509.

LL


On Oct 22, 2020, at 11:17 AM, Laurence Lundblade <lgl@island-resort.com> wrote:

I would like to see it as = standards track.

I = would like EAT / RATS to make normative reference to it. Some forms of = Attestation use Endorsements to convey a signature verification key to = the Verifier and some Endorsements are in the form of an X.509 = certificate.

I will present = some of this at the RATS virtual interim tomorrow. Slides are here. This is = why I=E2=80=99ve been so interested in this lately.

Also, it seems pretty important for COSE to be = usable with the all the X.509 infrastructure out there.

LL


On Oct 22, 2020, at 5:18 AM, Magnus Westerlund via = Datatracker <noreply@ietf.org> wrote:

...I think the topic should be fairly easily to resolve one way = or another.
However, even after having read the reply to = Marin's comment I don't think this
document is published = with the right status.

- The document = defines new CBOR attributes, that is standard track work as it
comes out as consensus document from a IETF WG. - It does not = define or
document crypto algorithm just refer to existing = ones. - The charter item might
have been reasonable as = informational if existing attributes could have been
used. = With the choice to define new attributes I think this has entered
standards track. - The status of the document I think will = also affect the
value that IANA might assign to these COSE = Header Parameters.

If there are additional = considerations I am happy to learn about them.

Else, I would propose a change of status to proposed standard = and redo the IETF
last call.





_______________________________________________
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

= --Apple-Mail=_441A7B84-B096-44FE-A577-22DEEE823160-- From nobody Fri Oct 23 14:21: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 C71043A1580; Fri, 23 Oct 2020 14:16:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: kaduk@mit.edu, cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348779780.5087.7905422229494438679@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:16:37 -0700 Archived-At: Subject: [COSE] cose - Requested session has been scheduled for IETF 109 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, 23 Oct 2020 21:16:41 -0000 Dear Matthew Miller, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. cose Session 1 (1:00 requested) Monday, 16 November 2020, Session II 1430-1530 Room Name: Room 6 size: 506 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/cose.ics Request Information: --------------------------------------------------------- Working Group Name: CBOR Object Signing and Encryption Area Name: Security Area Session Requester: Matthew Miller Number of Sessions: 1 Length of Session(s): 1 Hour 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: John Preuss Mattsson Jim Schaad Matthew A. Miller Benjamin Kaduk Goeran Selander Ivaylo Petrov Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 23 14:56: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 95DFD3A096B; Fri, 23 Oct 2020 14:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KS5aT5_cwUgt; Fri, 23 Oct 2020 14:55:59 -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 DDE2B3A0969; Fri, 23 Oct 2020 14:55:58 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4CHyj80bmnzyQH; Fri, 23 Oct 2020 23:55:56 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 625182955.352785-88957ab6bab68974b1cdf3ee5b0db56d Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 23 Oct 2020 23:55:55 +0200 Message-Id: <15D90A88-9959-4417-8F87-1C8A35E9DC0A@tzi.org> To: Ace Wg , "core@ietf.org WG (core@ietf.org)" , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [COSE] Constrained Node/Network Cluster @ IETF109: "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, 23 Oct 2020 21:56:02 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF109. Remember that further agenda changes can still happen. Very little has changed with respect to the draft agenda. WEBTRANS does meet, and CFRG and IRTFOPEN have been moved around (CFRG now on top of CORE, unfortunately). All times *on my agenda* are in UTC (the default page is UTC+0700). https://datatracker.ietf.org/meeting/agenda-utc might be handy. Note that both EU and US are on winter time (standard time) then. Gr=C3=BC=C3=9Fe, Carsten MONDAY, November 9, 2020 0500-0700 Hackathon Kickoff Rm 1 GEN hackathon Hackathon FRIDAY, November 13, 2020 0500-0700 Hackathon Closing Rm 1 GEN hackathon Hackathon MONDAY, November 16, 2020 0500-0700 Session I Rm 1 ART dispatch Dispatch WG - Joint with ARTAREA Rm 3 IRTF qirg Quantum Internet Research Group Rm 5 RTG raw Reliable and Available Wireless WG Rm 6 SEC *** lake Lightweight Authenticated Key Exchange WG 0730-0830 Session II Rm 2 INT add Adaptive DNS Discovery WG Rm 3 IRTF maprg Measurement and Analysis for Protocols Rm 6 SEC *** cose CBOR Object Signing and Encryption WG 0900-1100 Session III Rm 1 ART jsonpath JSON Path WG Rm 2 ART webtrans WebTransport WG Rm 7 SEC secdispatch Security Dispatch WG Rm 8 TSV tsvwg Transport Area Working Group WG TUESDAY, November 17, 2020 0500-0700 Session I Rm 1 ART *** core Constrained RESTful Environments WG Rm 2 INT 6man IPv6 Maintenance WG Rm 3 IRTF cfrg Crypto Forum Rm 7 SEC gnap Grant Negotiation and Authorization Protocol WG 0730-0830 Session II Rm 5 RTG babel Babel routing protocol WG Rm 6 SEC tls Transport Layer Security WG 0900-1100 Session III Rm 1 ART *** asdf A Semantic Definition Format for Data and = Interactions of Things WG Rm 5 RTG apn Application-aware Networking BOF Rm 8 SEC *** rats Remote ATtestation ProcedureS WG WEDNESDAY, November 18, 2020 0500-0700 Session I Rm 3 INT madinas MAC Address Device Identification for Network = and Application Services BOF Rm 5 RTG bier Bit Indexed Explicit Replication WG Rm 7 SEC *** ace Authentication and Authorization for Constrained = Environments WG Rm 8 TSV quic QUIC WG 0730-0830 Session II Rm 3 INT *** 6lo IPv6 over Networks of Resource-constrained Nodes = WG Rm 4 INT *** drip Drone Remote ID Protocol WG Rm 7 SEC *** teep Trusted Execution Environment Provisioning WG Rm 8 TSV tsvwg Transport Area Working Group WG THURSDAY, November 19, 2020 0500-0700 Session I Rm 3 IRTF coinrg Computing in the Network Research Group Rm 7 SEC saag Security Area Open Meeting 0730-0830 Session II Rm 1 ART *** cbor Concise Binary Object Representation Maintenance = and Extensions WG Rm 2 INT intarea Internet Area Working Group WG Rm 3 RTG detnet Deterministic Networking WG Rm 5 SEC acme Automated Certificate Management Environment WG 0900-1100 Session III Rm 4 OPS v6ops IPv6 Operations WG Rm 6 RTG *** roll Routing Over Low power and Lossy networks WG Rm 7 SEC mls Messaging Layer Security WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG FRIDAY, November 20, 2020 0500-0700 Session I Rm 2 INT add Adaptive DNS Discovery WG Rm 6 RTG rift Routing In Fat Trees WG Rm 7 SEC emu EAP Method Update WG 0730-0830 Session II Rm 1 ART httpapi Building Blocks for HTTP APIs WG Rm 2 INT *** lwig Light-Weight Implementation Guidance WG Rm 3 OPS anima Autonomic Networking Integrated Model and = Approach WG Rm 6 SEC *** suit Software Updates for Internet of Things WG Rm 7 TSV tsvarea Transport Area Open Meeting 0900-1100 Session III Rm 1 ART *** core Constrained RESTful Environments WG Rm 3 INT 6man IPv6 Maintenance WG Rm 5 IRTF irtfopen IRTF Open Meeting Rm 8 TSV masque Multiplexed Application Substrate over QUIC = Encryption WG From nobody Sat Oct 31 13:56:21 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 5DB623A0EA2; Sat, 31 Oct 2020 13:56: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 g42P-bCrO1ly; Sat, 31 Oct 2020 13:56:14 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 C70963A0EA7; Sat, 31 Oct 2020 13:56:14 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id k1so9543918ilc.10; Sat, 31 Oct 2020 13:56:14 -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=q2lDy6Yq+DG2LRGrqLTI1XKJGvS7DzEuTot4+1Acw7g=; b=ZlD1TwisM3eu6XOvsPySejbPaEiMEbypUKMfm41MgA0vaZnNSqHmMiOtaESTEOGjZV D3iXo4CwxHKUGmY9YLXuX5pfghiWVpvuLbzjZoOXJ+erBRtKonEklcUXYQ4+JnTw6MYD uJZ5v3KcAV3xOqSeLakHsN1Ycrmr6/Z6Qriae5vDrZrsil0uyJFmjYfJNtisfqe6VgPj /VQOr0ZC0WPV3f5wGhQ3UwIRndtGxhZRAJMPw05jXvItj4HwzknxxocZ6kEd/pGcdpEl /t7BDYp6k5Rl1FnKyc1fZtqWLCdGF6YU4fdkndR6MQ1HgAK39h2/wxHyPfiEj5BT8nTT ih4g== 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=q2lDy6Yq+DG2LRGrqLTI1XKJGvS7DzEuTot4+1Acw7g=; b=FC0aHfDvIzma5v9zfcW7B3h2u71nWaUpkSuL6vHUlU0h5LsrWqmhdNNJ5g+OWIbQ/N WATGQUmNU42erXm+RBkh81dWhUN2avrldfoKaU5RhHuL7Ml8IceSzeeGQ9f1nEkQNEKa sJX8UL2KoqP7x0O+Q+nwLznNrLKoFb1NQ0x1hBFsi1hEJmPmym3A7zhwm49QuqG767Pw c66XDvUmYk8Yrihzv5LSa3V5qfrSWoXXGoxj5wTtLwLlSY1+mbKxeVvgdcwVhz5AU2hr fPFTRx+eEsZqlcCV1r1vl55B/52BEwVCl2v8DJqcmiJwEdnP2ADVMopTNdyl0n39+MfZ wh0A== X-Gm-Message-State: AOAM533TGpwuMKYaDeS48oGygn/FjO5dSqQb3ucCh+1rUDdrSlZj/A6M n/5l1tbWMv0hwFTsrth+mIGi7FKgjaHyWVXO+Z90YTnZBMY= X-Google-Smtp-Source: ABdhPJzWgcKqYWskcxdV+v3CLyEoHeVnjFdg8vGOkX5lHyJ+YMEq2TNnXPWE/Tl1odtwmZuoiiid9NOhqZN5KVWGn14= X-Received: by 2002:a92:25d3:: with SMTP id l202mr6026886ill.249.1604177774125; Sat, 31 Oct 2020 13:56:14 -0700 (PDT) MIME-Version: 1.0 References: <160209160818.12838.15929178240331409569@ietfa.amsl.com> <21362.1602538323@localhost> <0ABC7267-6534-44CD-9ACA-E4F568CD07AE@island-resort.com> <72B2AEEB-D6D0-4E59-A3DE-CCEF015A0B47@island-resort.com> In-Reply-To: <72B2AEEB-D6D0-4E59-A3DE-CCEF015A0B47@island-resort.com> From: Martin Duke Date: Sat, 31 Oct 2020 13:56:03 -0700 Message-ID: To: Laurence Lundblade Cc: Carsten Bormann , draft-ietf-cose-x509@ietf.org, Michael Richardson , Cose Chairs Wg , The IESG , cose , Ivaylo Petrov Content-Type: multipart/alternative; boundary="00000000000062264205b2fdbe77" Archived-At: Subject: Re: [COSE] Martin Duke's No Objection on draft-ietf-cose-x509-07: (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: Sat, 31 Oct 2020 20:56:17 -0000 --00000000000062264205b2fdbe77 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would be happy if it the paragraph in question was rewritten to be clearer, perhaps using the words in the exchange between me and Michael. Really, simply replacing the passive voice in the sentence with active pretty much forces you to be clear about who is doing what. On Tue, Oct 20, 2020 at 10:06 AM Laurence Lundblade wrote: > > > On Oct 19, 2020, at 11:58 PM, Carsten Bormann wrote: > > > > On 2020-10-19, at 19:45, Laurence Lundblade > wrote: > >> > >> It is the requirements and design of the end-end system that determine= s > what the constrained device has to do or not do, not the design of these > headers. Probably it is an overreach to discuss end-end system designs. > Maybe it is just better to remove this paragraph? > > > > The constrained device can delegate most of its tasks (=E2=80=9Cwhat is= has to > do=E2=80=9D) to a (sufficiently trusted) less-constrained one (the only t= asks that > it cannot delegate are the ones needed to properly establish and maintain > trust into that device and the communication with it). > > The paragraph mostly serves as a reminder of how the task delegation > pattern can alleviate the concerns that led to the original COSE not havi= ng > X.509-related primitives. > > Hi Cartsen, > > As someone who is not involved in Ace and some of the other work on > constrained devices, with this explanation, the paragraph seems more out = of > place and misleading . > - It doesn=E2=80=99t inform or provide needed background info as to usage= and > design of cose-x509 (delegation issues are the same and even more importa= nt > for regular x.509). > - It doesn=E2=80=99t say anything about delegation to a cloud or such, so= it=E2=80=99s > unclear what it is talking about > - Maybe it reminds some people that already know about architecture for > delegation chain validation; not sure reminders for those in the know are > useful > - The security considerations section for delegation of chain validation > would be substantial > > All that said, I don=E2=80=99t think the paragraph is so awful it I would= say it > must be deleted, but think the document would be better if it was (or it > was expanded and moved to an appendix, or better yet some constrained > device architecture / cook book document). > > LL > > > > --00000000000062264205b2fdbe77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would be happy if it the paragraph in question was rewri= tten to be clearer, perhaps using the words in the exchange between me and = Michael. Really, simply replacing the passive voice in the sentence with ac= tive pretty much forces you to be clear about who is doing what.
<= br>
On Tue,= Oct 20, 2020 at 10:06 AM Laurence Lundblade <lgl@island-resort.com> wrote:

> On Oct 19, 2020, at 11:58 PM, Carsten Bormann <cabo@tzi.org> wrote:
>
> On 2020-10-19, at 19:45, Laurence Lundblade <lgl@island-resort.com> wrote: >>
>> It is the requirements and design of the end-end system that deter= mines what the constrained device has to do or not do, not the design of th= ese headers. Probably it is an overreach to discuss end-end system designs.= Maybe it is just better to remove this paragraph?
>
> The constrained device can delegate most of its tasks (=E2=80=9Cwhat i= s has to do=E2=80=9D) to a (sufficiently trusted) less-constrained one (the= only tasks that it cannot delegate are the ones needed to properly establi= sh and maintain trust into that device and the communication with it).
> The paragraph mostly serves as a reminder of how the task delegation p= attern can alleviate the concerns that led to the original COSE not having = X.509-related primitives.

Hi Cartsen,

As someone who is not involved in Ace and some of the other work on constra= ined devices, with this explanation, the paragraph seems more out of place = and misleading .
- It doesn=E2=80=99t inform or provide needed background info as to usage a= nd design of cose-x509 (delegation issues are the same and even more import= ant for regular x.509).
- It doesn=E2=80=99t say anything about delegation to a cloud or such, so i= t=E2=80=99s unclear what it is talking about
- Maybe it reminds some people that already know about architecture for del= egation chain validation; not sure reminders for those in the know are usef= ul
- The security considerations section for delegation of chain validation wo= uld be substantial

All that said, I don=E2=80=99t think the paragraph is so awful it I would s= ay it must be deleted, but think the document would be better if it was (or= it was expanded and moved to an appendix, or better yet some constrained d= evice architecture / cook book document).

LL



--00000000000062264205b2fdbe77-- From nobody Sat Oct 31 15:03:36 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 6AE2D3A07C4; Sat, 31 Oct 2020 15:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdCdKNuanqc9; Sat, 31 Oct 2020 15:03:28 -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 544EB3A0656; Sat, 31 Oct 2020 15:03:27 -0700 (PDT) Received: from [192.168.217.118] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (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 4CNtV54x44zycY; Sat, 31 Oct 2020 23:03:25 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Sat, 31 Oct 2020 23:03:25 +0100 Cc: Laurence Lundblade , draft-ietf-cose-x509@ietf.org, Michael Richardson , Cose Chairs Wg , The IESG , Ivaylo Petrov , cose X-Mao-Original-Outgoing-Id: 625874605.282427-45b35a2da6ae45da8b1d27d4fc4136f4 Content-Transfer-Encoding: quoted-printable Message-Id: <1CB50567-884D-4B46-926C-BA20A8A00AFB@tzi.org> References: <160209160818.12838.15929178240331409569@ietfa.amsl.com> <21362.1602538323@localhost> <0ABC7267-6534-44CD-9ACA-E4F568CD07AE@island-resort.com> <72B2AEEB-D6D0-4E59-A3DE-CCEF015A0B47@island-resort.com> To: Martin Duke X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [COSE] Martin Duke's No Objection on draft-ietf-cose-x509-07: (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: Sat, 31 Oct 2020 22:03:31 -0000 > On 2020-10-31, at 21:56, Martin Duke wrote: >=20 > I would be happy if it the paragraph in question was rewritten to be = clearer, perhaps using the words in the exchange between me and Michael. = Really, simply replacing the passive voice in the sentence with active = pretty much forces you to be clear about who is doing what. Like: Certificates obtained from any of these methods MUST still be validated. =E2=9E=94 Parties that intend to rely on the assertions made by a certificate obtained from any of these methods still need to validate it. ? (Note that I changed the RFC 2119 MUST into a statement of fact, which = is orthogonal to the question of who the actor of the validation is.) Gr=C3=BC=C3=9Fe, Carsten