From nobody Sat Apr 14 10:30:06 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBC31201FA; Sat, 14 Apr 2018 10:30:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152372700398.17677.7869785039393556389@ietfa.amsl.com> Date: Sat, 14 Apr 2018 10:30:04 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-14.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2018 17:30:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Michael H. Behringer Steinthor Bjarnason Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-14.txt Pages : 94 Date : 2018-04-14 Abstract: This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using manufacturer installed X.509 certificate, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-14 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-14 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 Sat Apr 14 10:40:29 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE731241F3 for ; Sat, 14 Apr 2018 10:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 hXI42pRnXNtP for ; Sat, 14 Apr 2018 10:40:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1284C1201FA for ; Sat, 14 Apr 2018 10:40:26 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 88CC620090 for ; Sat, 14 Apr 2018 13:50:48 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7C2A481A21 for ; Sat, 14 Apr 2018 13:40:24 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: <152372700398.17677.7869785039393556389@ietfa.amsl.com> References: <152372700398.17677.7869785039393556389@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.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: [Anima] revision -14: draft-ietf-anima-bootstrapping-keyinfra-14.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2018 17:40:28 -0000 --=-=-= Content-Type: text/plain EXEC SUM: we are ready for WGLC! internet-drafts@ietf.org wrote: > Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) > Authors : Max Pritikin > Michael C. Richardson > Michael H. Behringer > Steinthor Bjarnason > Kent Watsen > Filename : draft-ietf-anima-bootstrapping-keyinfra-14.txt > Pages : 94 > Date : 2018-04-14 Kent, Max and I have closed off the remaining bigger issues arising from the various reviews and discussions in between resolving ietf-anima-voucher AUTH48 issues. As a result of RFC-EDITOR comments about ietf-anima-voucher, we have made the "pledge" and "registrar" lower case in this document to be consistent with the ietf-anima-voucher document. This is in contrast to what we did we a month ago when we made them consistently upper case, as we were thinking of them as Proper Nouns. The major changes are in the organization of section 5. New sub-headings, and we made sure that were not writing normative MUSTs in summary/overview statements. New section 5.7.2 on interpreting the audit log. Many other small changes, see: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-14 https://github.com/anima-wg/anima-bootstrap/issues shows three issues open: 1) proper noun question above. 2) two issues open for updating of examples, including providing a CSR example. This will require some code to mature. {ps: ietf-anima-voucher is waiting in AUTH48 for an AD sign off on a small addition to security considerations, then it will be out} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlrSPQgACgkQgItw+93Q 3WVI6ggAh+YOcZ3np7QetwZ2ULF2ZCycmPNQP39C5bCx/N5swSQffyWWt63JsHRP LsBog49CxEnD/uNAHjQ9Nk3B22fZpyV05ioB3cjsO2LQH2bbh146p/yD2Xl7bIVk MUHLxoOPnpLqwjJSNrrJAkQvGBrN0OnLJPcOU6x1PFRGcdlJKvAuC29xMHPNgyqZ zj3Q8BQf2R9lEMl153AGen9APAHc5/Gf8ybbeHhaCUTnzNPcacJBSFewZ+9dZDvS Ee0fB+La4bJzShvfXj1ZCqdoDfUnP6g/84C9M3zxoLLsVXL0fJkkA/8KC5Ao+HSU 5cCoUSO3UG7UtK6rxNztqEfkGO5pHA== =apH4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Apr 14 14:09:08 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5961250B8 for ; Sat, 14 Apr 2018 14:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 IxMSlJRXnuj2 for ; Sat, 14 Apr 2018 14:09:04 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 46CEC12702E for ; Sat, 14 Apr 2018 14:09:04 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id p6so8734034pfn.4 for ; Sat, 14 Apr 2018 14:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JR/rqCsuzYtO2WT98isIX57b6uKT5mSq8zGBE1PNnl8=; b=OjX3uLnpomaNym00Y+gleaGgBUk8tssZvUKr4H1b6zRYIBvo7VNbl60qnQ7YTlpPD2 a6T7oVG3jJS87SeNAnbgn2uuRWS5GgOFUlFn0UEAV4q7cQchIVMeR7PeIagRLhlzJ2AW eROViwl95qL/uAgV3q+kyETGVHd1BBI0YehMaIryFv4+ADI0Cq1B/qmTJqOzAr3NQOwr K92ftiD3jKymAnQ5qqVDeAXx+E/R3iIW/PmNmZShVfnVsYp8oKsKZZZPV8wteQSsg3kZ gzi1+k3eQXj/lsuk5j8Bzuq+gHlNgh+XHvTpBkujPWowFhaApeb9MSvscPXCl9afHo2k frBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JR/rqCsuzYtO2WT98isIX57b6uKT5mSq8zGBE1PNnl8=; b=SSd5XfeNbq/Ky5v32kEDPk9xW5tAzsZAfpHs2NKolGIwrVbpGamaPeXFZ18/XH2uHD 0DVUrsxzxDWFwve3vgNwfIXtjOEJnvXlC807L8bwnu8qdmkBEpbi0h7VPpEvvzGgVgk/ dtE9nTNiouHU922pTF9ipCvDaMgBZ1V+Q6C5FkYzjIILXoKD786Rh1xfeWzuhlxgb9M9 3h6jX5k18wNuRVd5euTVo4A5ZnODshPTdrAw665Ia/oiS7emWtR3v8q76nhm5ukhSr8i KgPgkwi7PiA7C5LDG/N0eP4L9HXvIk5giCFrZJg7TGyHxL2mhACkb+zCo1Np5jSHYKVe 9/mA== X-Gm-Message-State: ALQs6tD7VJ4vFX86nSW4ATMGWI/3NWW0ESYAOsO+TIf14mzPogGrPbrB dSyCZMGtbNVHGv7UX/333dr8bQ== X-Google-Smtp-Source: AIpwx4+80Q1xG8nQjPHzKHABgRDvqavUtPsLsrQ4qtlOUwE97vNiakuOUjj4oimyVtFYh5bna9sUzg== X-Received: by 10.98.238.3 with SMTP id e3mr16147665pfi.88.1523740143205; Sat, 14 Apr 2018 14:09:03 -0700 (PDT) Received: from [192.168.178.26] ([118.149.104.115]) by smtp.gmail.com with ESMTPSA id l80sm18992401pfk.73.2018.04.14.14.09.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Apr 2018 14:09:02 -0700 (PDT) Sender: Brian Carpenter To: anima@ietf.org References: <152372700398.17677.7869785039393556389@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Sun, 15 Apr 2018 09:08:59 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152372700398.17677.7869785039393556389@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-14.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2018 21:09:07 -0000 The GRASP part of this draft seems 100% OK now. Regards Brian On 15/04/2018 05:30, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. > > Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) > Authors : Max Pritikin > Michael C. Richardson > Michael H. Behringer > Steinthor Bjarnason > Kent Watsen > Filename : draft-ietf-anima-bootstrapping-keyinfra-14.txt > Pages : 94 > Date : 2018-04-14 > > Abstract: > This document specifies automated bootstrapping of a remote secure > key infrastructure (BRSKI) using manufacturer installed X.509 > certificate, in combination with a manufacturer's authorizing > service, both online and offline. Bootstrapping a new device can > occur using a routable address and a cloud service, or using only > link-local connectivity, or on limited/disconnected networks. > Support for lower security models, including devices with minimal > identity, is described for legacy reasons but not encouraged. > Bootstrapping is complete when the cryptographic identity of the new > key infrastructure is successfully deployed to the device but the > established secure connection can be used to deploy a locally issued > certificate to the device as well. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-14 > https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-14 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-14 > > > 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/ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Apr 20 01:21:20 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7F9126B6D; Fri, 20 Apr 2018 01:21:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: anima-chairs@ietf.org, ibagdona@gmail.com, anima@ietf.org, jiangsheng@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152421247741.10829.4566988470779582524.idtracker@ietfa.amsl.com> Date: Fri, 20 Apr 2018 01:21:17 -0700 Archived-At: Subject: [Anima] anima - New Meeting Session Request for IETF 102 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 08:21:18 -0000 A new meeting session request has just been submitted by Sheng Jiang, a Chair of the anima working group. --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: 6tisch nmrg 6lo 6man Second Priority: roll v6ops dhc homenet netconf Third Priority: cfrg saag intarea opsarea People who must be present: Toerless T. Eckert Sheng Jiang Terry Manderson Ignas Bagdonas Resources Requested: Special Requests: The WG prefer to have meeting on Tuesday/Wednesday if possible. --------------------------------------------------------- From nobody Fri Apr 20 01:34:33 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0901126B6D; Fri, 20 Apr 2018 01:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 P8mQDovUoxdA; Fri, 20 Apr 2018 01:34:29 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.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 C68DD12422F; Fri, 20 Apr 2018 01:34:28 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 79E75420C5DB5; Fri, 20 Apr 2018 09:34:24 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 20 Apr 2018 09:34:26 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Fri, 20 Apr 2018 16:34:20 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: ANIMA minutes - IETF 101, London, UK Thread-Index: AdPYgixGx708EVkiRwuY+ZEJJrcEGA== Date: Fri, 20 Apr 2018 08:34:20 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B928184E93C@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B928184E93CNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] ANIMA minutes - IETF 101, London, UK X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 08:34:31 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B928184E93CNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, The minutes for the ANIMA sessions at IETF101 in London can be found at:: https://datatracker.ietf.org/meeting/101/materials/minutes-101-anima/ Many thanks to Bing Liu for taking minutes. Please send any corrections to the chairs. Best regards, Sheng + Toerless --_000_5D36713D8A4E7348A7E10DF7437A4B928184E93CNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all,

 

The minutes for the ANIMA sessions at IETF101 in London can be found at:= :

 

https://datatracker.ietf.org/meeting/101/materials/minutes-101-anima/

 

Many thanks to Bing Liu for taking minutes.=

 

Please send any corrections to the chairs.<= /p>

 

Best regards,

 

Sheng + Toerless

 

--_000_5D36713D8A4E7348A7E10DF7437A4B928184E93CNKGEML515MBXchi_-- From nobody Sun Apr 22 16:50:41 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C6A127010 for ; Sun, 22 Apr 2018 16:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXhZTPqLulWF for ; Sun, 22 Apr 2018 16:50:38 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 5DB4B12426E for ; Sun, 22 Apr 2018 16:50:38 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id m21so4088872pgv.8 for ; Sun, 22 Apr 2018 16:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:organization:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=V6qVL3gejGRB2Dr1phmbe1gs4MKSBfvl1gcOc9UNBrQ=; b=ZC42FsucJMs9VdWqWP/Da0KmWxc+UGzAimRX/MsJOZTldgG/kvGwyv+1ava64tN8t/ +zfhyeWw1PSHYK/lPaLDI1l0rYMWk2hcWEaNffaE2BdfVmNBSTPxhGMJs2vZyzVGaEiG zL4jKnRBRcn4H0ZD6P8uogcDa99jjfJPkTqtFtdo6dC9Blo25JuKUe6UeBV2Mccxne0V NSHIpCMCw3D44/pQl5CwIxjcU2c3RJxj81HrhSs5wpTiUe4e6ciP83cBeDipUBwvCxai QGV5IIHTK2L6Qlg2rUACdFrExjICxMkB+kB8Tlr1R6+MRnJ+ct0NN1bCqOq/jUGC0HiC wbMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:organization:to:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=V6qVL3gejGRB2Dr1phmbe1gs4MKSBfvl1gcOc9UNBrQ=; b=HWuYmTIQHO2iBy7eHkEyQrEwk3A82roovezMvZgA+YWkFzcwKUOUGDDs3CsG+2hr0J wk6tPdIXtGxwEL+THJ1U7qsoXmnGuLTCsBS+lc+hPOCnG3giUkkzMpBT+Dl8In/znJsA xqWuVue7K4SaAGbDP4UfVSLU6Os6U8xqy0YJh1yYTIaUGJs+XsUL/BAVzfPDQRl47suP EWWMSl+K0OJIqBhiP9Cg56hH+IgqCmTrLrvLDjuGJ1qgJaOD17USaTh35P42Y49VqAHE DwaTCbk/YX15J7iG4wkRbaJyHQ8v3dvSCVXz2RMUqURPECeFXbLLRSjDWQGdaI8pDudo LwgA== X-Gm-Message-State: ALQs6tD9tMOPrYRWa5Uv4kbRoHOIJInJIC63Dzb2ro+Opi6/0ABEruve 55rKGOcUcm2+Re5QVbg25mGn6Q== X-Google-Smtp-Source: AIpwx49z9uHYxooGJiRYHifTG1b5jVfRlfPEJasEtNzAfz02iFw/8EptYIddioSB8B/yDFxSmHsFJA== X-Received: by 10.101.98.5 with SMTP id d5mr13495452pgv.416.1524441037539; Sun, 22 Apr 2018 16:50:37 -0700 (PDT) Received: from [130.216.38.11] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.11]) by smtp.gmail.com with ESMTPSA id l19sm13576846pgn.44.2018.04.22.16.50.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Apr 2018 16:50:36 -0700 (PDT) From: Brian E Carpenter Organization: University of Auckland To: Anima WG Message-ID: <51e53957-4ccd-6d15-713a-6b7f7571ede5@gmail.com> Date: Mon, 23 Apr 2018 11:50:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] draft-ietf-anima-grasp-api discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 23:50:40 -0000 A few comments on the issues raised at IETF 101: > 2c. GRASP Application Program Interface (API) - 10min > 9:55 - 10:05, by Bing Liu, draft-ietf-anima-grasp-api > [Sheng Jiang] Why "current API lacks support explicit locators for an objective > " is an issue? It's straightforward to just expose it. And let the ASAs > decide whether to use it. > [Bing] We're not very sure whether it is good to open such detailed thing to > ASAs by the GRASP module. I think it is straightforward. In fact, I already added it to the Python code, as an optional parameter for the register_obj() call. I found a use for it in one variant of my demo implementation of BRSKI discovery. So do people think the API description should include this? > [Sheng] Error codes between API and GRASP module and error codes inside the > GRASP are different. If it is the latter, it should be in GRASP document. > [Bing] It's inside the GRASP, but it is mostly regarding to ASAs. > (Errata: it is actually in the API not in GRASP messages.) Right. But it's still an open question whether most of the return codes should be standardised or implementation-dependent. The first four IMHO definitely need to be standard: ok = 0 #"Call succeeded" declined = 1 #"Declined" noReply = 2 #"No reply" unspec = 3 #"Unspecified error" > [Toerless Eckert] The main issue to me would be that the functionality > expressed over grasp is meant to be application information, so the trouble > is to establish cross application standards. I try to do that in the DNS-SD > draft which is trying to say okay whatever application you are if you're > trying to signal a service then here is a standard for that and I think > that's the type of functional document not an API document. Correct, it's almost an API on top of the API ;-) Brian From nobody Sun Apr 22 18:00:21 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CE11200FC for ; Sun, 22 Apr 2018 18:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARGzci-8cqpC for ; Sun, 22 Apr 2018 18:00:18 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 3E7F6124D37 for ; Sun, 22 Apr 2018 18:00:17 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id m21so4171402pgv.8 for ; Sun, 22 Apr 2018 18:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:organization:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=tZIO1ZuvgCM+adG9Cy3MASr8u+tG56jpHwC6v2HT3g8=; b=PA6aoydZhx1RQaRg71hG847/SuU3YByMOipk2/xd1k3naEWJRkztEwrf5+DMfqd4g3 ygaJCGnHmF/wPMKHA58rSV595Njucvmp6zT+MEq0fxsWUUNR/UOOfmAGXIIS3QQaH6ll eV4DCFZqqN272IY5DqEd/Tr8uNjog8zX4prIOZOX6q7e13DWwhUUxtPn0nCn2PlCcs3G RnL6/+P2CYe9lVKk/QdfXzZ9BFKXD8YtiNMXAdwIMJ9+fXmU76WurPmAl1wkhf35x5DH zHkrdLa3l34rAcACXmj6q0vC3Q7tV3HK/huFN4hkRz7nACFF8DK/qeef54d2K88cdvcU i6Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:organization:to:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=tZIO1ZuvgCM+adG9Cy3MASr8u+tG56jpHwC6v2HT3g8=; b=Ib1ryRrnvzCLI06sHUX5hAZQoObJtkOpDvsyTBqyLJ0sym4IC6SRepy/8aAIkIR68Y 2AlcqRMEjza0hVcdiECYuT57I6W6LU4P/U6mtDE2T/v4EoMGpama1FJswnL+9MEVZhkC kqKMnp9HczSykT61LnN1445cnzXbVnQUnTDywRi4LoYBNyR4DVn/ZHhIGqQnJ6K2LfMR SCcwcb5XfiTU4IJxuozO0jx6gYz0tH7yLiRKOaoiMLjxTfz83RFw8MPYtAG4XZpZUFHa 90oCs2QVHO27WIg15qNefA7TRYmBdp/LB0ett2hN/88Q4jO2F8NZaCKPaTbnLv7NAqfj ZLtA== X-Gm-Message-State: ALQs6tD+3W+V8zvlooLNVN5+/Dh40Utx9btxqCG4C/P2N/o3/HS5G32g E02Ng4S95zBuY6rSdmimyZ9L/g== X-Google-Smtp-Source: AIpwx48P3do97tx1U/AXPjKs1DTxB4v9xVdZcDt0b1mjtppqatkPbcgdVdwwXxG2O0TvTCnqXTQBXA== X-Received: by 10.98.61.84 with SMTP id k81mr18058765pfa.193.1524445216411; Sun, 22 Apr 2018 18:00:16 -0700 (PDT) Received: from [130.216.38.11] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.11]) by smtp.gmail.com with ESMTPSA id y13sm15404466pge.34.2018.04.22.18.00.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Apr 2018 18:00:15 -0700 (PDT) From: Brian E Carpenter Organization: University of Auckland To: Anima WG Message-ID: <575c24df-eef4-929b-c62b-ac412e4e4d7d@gmail.com> Date: Mon, 23 Apr 2018 13:00:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] draft-carpenter-anima-asa-guidelines discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 01:00:20 -0000 More comments on the discussion at IETF 101: > [Toerless] I think this work is highly useful, But we have to figure out the > charter issue, because ASAs in general are not in current charter. It can > become better and better the more experience we gain, thus as a chair I > wouldn'tnecessarily want to have it finished as quickly as possible. I understand that argument, and the document is far from finished. But how can we encourage people (not just IETF people) to provide the experience? I think we need open source implementations of the ANI components ASAP. ...> [Alex Galis] 1) this draft is to better describe the border between service > system right up vs. ASA right up; in other words, what are these and how to > move from the described application towards service, that's the driving > force. I don't think that this is a clear answer in you current system. Again: we need experience, not theory, to clarify this. > 2) NFV is coming in a big way, it's time to embrace the virtualization > significantly because that's where our autonomicity will be applied. > it's the time to embrace virtualization; Remember though that ANIMA is a *management* mechanism. Certainly it can manage virtual functions and components, just as easily as physical devices. I don't see a problem of principle here at all. The ASAs need the administrative privilege necessary to manage the virtual components, that's all. (The ACP itself is a virtual network, using VRF functionality.) > 3) Autonomicity had big subject, it's time to decouple it autonomocity > in terms of specific self-x capabilities for which ASA or other parts of the > Anima could be better applied. One framework for all, it's not going to be > easy to put in deployment in all the aspects, including the control plane > which was described recently. I'm afraid I'm not sure that this is > deployable. But if that's not deployed, at least ASA applications could be > better deployed. GRASP requires a secure substrate. It doesn't actually *require* draft-ietf-anima-autonomic-control-plane; that's just the first exemplar of a secure substrate. GRASP could be deployed tomorrow over any other sort of secure substrate (or, heretically, with no security at all, but I don't advocate that outside a hackathon). Alex, can you propose a simple alternative to the ACP? Brian From nobody Sun Apr 22 18:29:05 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB68C1200FC for ; Sun, 22 Apr 2018 18:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDMDOIH7Rz0e for ; Sun, 22 Apr 2018 18:29:02 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 0194512420B for ; Sun, 22 Apr 2018 18:29:01 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id t12so7207547pgp.13 for ; Sun, 22 Apr 2018 18:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:organization:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=s3q2TTh9UIMHqtqp7G0WKVj5qSgTWmGT/nNEwZ+4xhg=; b=VQKCyQ8U9g70uzBsVZAERJRcJE/AHrNeM/E9jUrXTRRvgX+6jFOOAFMiCdvFOY6Bnt rOTD4GkLFU5mKpbjKDflS3XmTN4Va7/OP522Te18hblKx43zKvmVeawnQHCbcPy2yxjD Lszb3EFTxDh4xEHwRS6jeYu4RcznFK+Zkdgvc7Tl25xXtNYS4VZnYtHx4EhVmnUch2LU C82bsnFPfnt0BVOjHtspm7/aqtIl2Vx9nPKbJrqvfje4GWdVczKwuz63RN5dEya7y8Db JQ+rXqSv3+U0TW3mnV6G8nhv5HLYYRcICku81qYts4a1DKYRETsUSF58M2dDoHqgv2Sa RsXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:organization:to:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=s3q2TTh9UIMHqtqp7G0WKVj5qSgTWmGT/nNEwZ+4xhg=; b=tltb+XExX2LPBhZGM7BkqVV6Xsqz0g43REo46MxpBKDlmTgMtCwbYvcY6PZL4Aza9A agYanOck3L2581rgOU689XTxs3nToaPh5PUP06B9fSab7izC3NrcRCRhmhZA5gCHxulw oXgAMY0SHjsj6y4/kNhNSN2/cq5gpXybEZbmFMcgbXz0R25lInDSdRb6JYcDbtdBQMgR FtBXQcvlHJDEtKOsZUfKUD35sZrz5c60CJ6wPe1rd81XDXL/H/DrZGkliZ5hmwuFso+S jlM8dTeoLlB7IDDtqNQzIJGHGNCIu4+6VXbqJqMk64B+3KQArc6uDNst+aEW4ltngPGj nZsg== X-Gm-Message-State: ALQs6tDmZXSXdD/K8HoTPxpRslRDL0zQVAWbwTBEXQVkhfPjtwtwVJq4 WGB5GL5kX7V6yM9jSbe4F6Py4A== X-Google-Smtp-Source: AIpwx48dZPJHNnII34eGwS+oDCeU2ArF5MvgrpC9zjPcYTH43k4r7u/vZ4M2f//hYG+3yJDc5L2A4g== X-Received: by 2002:a17:902:9686:: with SMTP id n6-v6mr18517544plp.136.1524446941329; Sun, 22 Apr 2018 18:29:01 -0700 (PDT) Received: from [130.216.38.11] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.11]) by smtp.gmail.com with ESMTPSA id e13sm15087007pga.53.2018.04.22.18.28.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Apr 2018 18:29:00 -0700 (PDT) From: Brian E Carpenter Organization: University of Auckland To: Anima WG Message-ID: Date: Mon, 23 Apr 2018 13:28:59 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] draft-carpenter-anima-grasp-bulk discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 01:29:04 -0000 > 6.Transferring Bulk Data over the GRASP - 10min > 10:55 - 11:05, by Bing Liu, draft-carpenter-anima-grasp-bulk > > [Sheng] I see use cases of this, e.g. IoT device software/firmware update. But > I'm not sure why you have the MTU as 2000 byte? > [Bing] It is mostly for convenience of parsing the GRASP messages because under > layer is CBOR serialization, a fixed 2000 byte is easy to identify the end > of the message. At some point in the design of GRASP it became clear that a default maximum message size was a practical requirement. The choice of 2048 was made in draft-ietf-anima-grasp-08. Discussion thread at: https://mailarchive.ietf.org/arch/msg/anima/y-WC1sUFYJ6f_gBALzrg6M4obvE The practical impact is the buffer size you set for recvfrom(). Also, there will be a physical limit for UDP multicast. The GRASP spec says: GRASP nodes MUST be able to receive unicast messages of at least GRASP_DEF_MAX_SIZE bytes. GRASP nodes MUST NOT send unicast messages longer than GRASP_DEF_MAX_SIZE bytes unless a longer size is explicitly allowed for the objective concerned. For example, GRASP negotiation itself could be used to agree on a longer message size. So it would be quite legal for bulk transfer to negotiate a larger size. (I had forgotten that when Joel raised this issue.) Brian From nobody Thu Apr 26 19:31:57 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AFC126CD8; Thu, 26 Apr 2018 19:31:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152479631590.6019.7534752757790844320@ietfa.amsl.com> Date: Thu, 26 Apr 2018 19:31:55 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-15.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 02:31:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Michael H. Behringer Steinthor Bjarnason Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-15.txt Pages : 94 Date : 2018-04-26 Abstract: This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using manufacturer installed X.509 certificate, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-15 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 27 08:32:15 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD5F1270AB; Fri, 27 Apr 2018 08:32:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152484313389.5933.11615401028244131515.idtracker@ietfa.amsl.com> Date: Fri, 27 Apr 2018 08:32:13 -0700 Archived-At: Subject: [Anima] The ANIMA WG has placed draft-richardson-anima-ace-constrained-voucher in state "Call For Adoption By WG Issued" X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 15:32:14 -0000 The ANIMA WG has placed draft-richardson-anima-ace-constrained-voucher in state Call For Adoption By WG Issued (entered by Toerless Eckert) The document is available at https://datatracker.ietf.org/doc/draft-richardson-anima-ace-constrained-voucher/ Comment: draft-richardson-anima-ace-constrained-voucher was presented at IETF101 and received good interest. The authors asked for adoption. As far as the chairs heard, there was no objection in the room. As new work, we discussed this with the new AD for ANIMA Ignas Bagdonas and also concluded that this work would be in scope of our current chater. We hereby are officially asking the working group to confirm adoption of this work: This message starts a two-week adoption call on: Title: Constrained Voucher Profile for Bootstrapping Protocols Name: draft-richardson-anima-ace-constrained-voucher Authors: M. Richardson, P. van der Stok, P. Kampanakis URL: https://datatracker.ietf.org/doc/draft-richardson-anima-ace-constraine d-voucher/ Please express your support or rejection. If you think this document should _not_ be adopted, please also explicitly indicate the reasons. This adoption call will end on May 12, 2018. More information as follows: This document is intended to become standards track ANIMA WG document (-03 has a format mistake indicating informational, this would be fixed). Standard track is desired because it is meant to become the required voucher format for solutions with (low-end) devices with existing or future signaling protocols. One of the candidate future signaling to use this voucher is draft-ietf-ace-coap-est. Another one is BRSKI with DTLS using the CBOR encoding proposed in the document for use cases of the FairHair association which includes members from ZigBEE, KNX and Bacnet. It would also be needed to by other 6tisch documents such as draft-ietf-6tisch-dtsecurity-zerotouch-join (from which this voucher draft was actually extracted, similarily to how voucher was extracted from BRSKI). The choice for bringing this to anima was done because of the experience with the first voucher draft, comparing possible working groups and concluding that ANIMA was best the best WG for it. From nobody Fri Apr 27 08:33:12 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBD71252BA; Fri, 27 Apr 2018 08:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxcU1MUBpftB; Fri, 27 Apr 2018 08:33:08 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C713120047; Fri, 27 Apr 2018 08:33:07 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0E9BB58C4B1; Fri, 27 Apr 2018 17:33:04 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id EC76E440214; Fri, 27 Apr 2018 17:33:03 +0200 (CEST) Date: Fri, 27 Apr 2018 17:33:03 +0200 From: Toerless Eckert To: anima@ietf.org Cc: draft-richardson-anima-ace-constrained-voucher@ietf.org Message-ID: <20180427153303.22ldck5segkmlxwp@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] Adoption call for draft-richardson-anima-ace-constrained-voucher (ends 05/12/2018) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 15:33:11 -0000 draft-richardson-anima-ace-constrained-voucher was presented at IETF101 and received good interest. The authors asked for adoption. As far as the chairs heard, there was no objection in the room. As new work, we discussed this with the new AD for ANIMA Ignas Bagdonas and also concluded that this work would be in scope of our current chater. We hereby are officially asking the working group to confirm adoption of this work: This message starts a two-week adoption call on: Title: Constrained Voucher Profile for Bootstrapping Protocols Name: draft-richardson-anima-ace-constrained-voucher Authors: M. Richardson, P. van der Stok, P. Kampanakis URL: https://datatracker.ietf.org/doc/draft-richardson-anima-ace-constrained-voucher/ Please express your support or rejection. If you think this document should _not_ be adopted, please also explicitly indicate the reasons. This adoption call will end on May 12, 2018. More information as follows: This document is intended to become standards track ANIMA WG document (-03 has a format mistake indicating informational, this would be fixed). Standard track is desired because it is meant to become the required voucher format for solutions with (low-end) devices with existing or future signaling protocols. One of the candidate future signaling to use this voucher is draft-ietf-ace-coap-est. Another one is BRSKI with DTLS using the CBOR encoding proposed in the document for use cases of the FairHair association which includes members from ZigBEE, KNX and Bacnet. It would also be needed to by other 6tisch documents such as draft-ietf-6tisch-dtsecurity-zerotouch-join (from which this voucher draft was actually extracted, similarily to how voucher was extracted from BRSKI). The choice for bringing this to anima was done because of the experience with the first voucher draft, comparing possible working groups and concluding that ANIMA was best the best WG for it. Regards ANIMA chairs (Sheng & Toerless) From nobody Fri Apr 27 14:24:50 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC371289B0; Fri, 27 Apr 2018 14:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.606 X-Spam-Level: X-Spam-Status: No, score=0.606 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001, 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 paC7lDzMkA7x; Fri, 27 Apr 2018 14:24:46 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32CEC1273E2; Fri, 27 Apr 2018 14:24:46 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 27 Apr 2018 14:22:13 -0700 From: Jim Schaad To: CC: Date: Fri, 27 Apr 2018 14:24:38 -0700 Message-ID: <030601d3de6e$2760f1f0$7622d5d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdPea4U/UfTWQOExS+mg2lBvltcaqA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Anima] draft-richardson-anima-ace-constrained-voucher X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 21:24:48 -0000 A fast review of the document, but I have no problems with having it adopted. * In section 1 para #4 you appear to have a formatting error where a list was supposed to exist. * Section 5 - you have a return of multiple items with the same rt value. However I would not want to have to filter through the list of return values to figure out which is the "root" one. Should this example have the rt=ace.est attribute on all of the links? * Section 5 the description of ct=16 is not quite correct as it is missing the encrypt0 subtype. This text might lead people to conclude that any application/cose type can use 16 * Suggest a strong recommendation on not use cmsVersion=1 to make your life easier. Jim From nobody Sat Apr 28 02:51:42 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5866212D95A; Sat, 28 Apr 2018 02:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QfhhErTR3Qi7; Sat, 28 Apr 2018 02:51:39 -0700 (PDT) Received: from lb1-smtp-cloud9.xs4all.net (lb1-smtp-cloud9.xs4all.net [194.109.24.22]) (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 88D9B12D952; Sat, 28 Apr 2018 02:51:38 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:200]) by smtp-cloud9.xs4all.net with ESMTPA id CMVzfAGV9bfBnCMVzfWKMZ; Sat, 28 Apr 2018 11:51:36 +0200 Received: from 2001:983:a264:1:2089:dca:134c:e3de by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Sat, 28 Apr 2018 11:51:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 28 Apr 2018 11:51:35 +0200 From: peter van der Stok To: Jim Schaad Cc: draft-richardson-anima-ace-constrained-voucher@ietf.org, anima@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <030601d3de6e$2760f1f0$7622d5d0$@augustcellars.com> References: <030601d3de6e$2760f1f0$7622d5d0$@augustcellars.com> Message-ID: <799535edb7d684c59f8d0aac65149496@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfLjcoMr6BkrvCdEvbqiq0IrIzZ3JL5Fgm8A5ddG3kjRJq56sJPd5EGFmrHzNEs5SAgLZIWfyW0ML1gZOMRR/W6HCO77F7r/N15JepV6Nic9ZH/a69fHA 5Upg3kKGANCkKO4Q6kBiVdPpV7GWd3oypIi2dsyVwBL4mT5+wZmm/UzT/NRzwmMK01fV/8Lbxp9g+m8eqcVjHK13C/TuJQ02lmxMwgPJ91M3uQYS0DMxaXyf eJVhxlXDu6h2iGvRwP2Z8A== Archived-At: Subject: Re: [Anima] draft-richardson-anima-ace-constrained-voucher X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2018 09:51:41 -0000 Hi Jim, thanks for the encouragement. Jim Schaad schreef op 2018-04-27 23:24: > A fast review of the document, but I have no problems with having it > adopted. > > * In section 1 para #4 you appear to have a formatting error where a > list > was supposed to exist. You mean that a list of omitted sections should be added? > > * Section 5 - you have a return of multiple items with the same rt > value. > However I would not want to have to filter through the list of return > values > to figure out which is the "root" one. Should this example have the > rt=ace.est attribute on all of the links? The example is an example and people can decide to do it differently. Two alternatives: - only return the root collection - define additional rt values per resource You have a preference? I prefer the first approach > > * Section 5 the description of ct=16 is not quite correct as it is > missing > the encrypt0 subtype. This text might lead people to conclude that any > application/cose type can use 16 Thanks, Will improve the description. > > * Suggest a strong recommendation on not use cmsVersion=1 to make your > life > easier. Thanks for the suggestion. > > Jim > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Apr 30 12:18:31 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD151242F7; Mon, 30 Apr 2018 12:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 USSHA5ZUcgN0; Mon, 30 Apr 2018 12:18:27 -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 39CCC120721; Mon, 30 Apr 2018 12:18:27 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 13B4120090; Mon, 30 Apr 2018 15:29:46 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id BF3362689; Mon, 30 Apr 2018 15:18:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BC6C62687; Mon, 30 Apr 2018 15:18:16 -0400 (EDT) From: Michael Richardson To: anima@ietf.org, Jim Schaad cc: draft-richardson-anima-ace-constrained-voucher@ietf.org In-Reply-To: <030601d3de6e$2760f1f0$7622d5d0$@augustcellars.com> References: <030601d3de6e$2760f1f0$7622d5d0$@augustcellars.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] draft-richardson-anima-ace-constrained-voucher X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 19:18:30 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Jim Schaad wrote: > * In section 1 para #4 you appear to have a formatting error where a = list > was supposed to exist. Thanks, I fixed that in the markdown. peter van der Stok wrote: >> * Section 5 - you have a return of multiple items with the same rt v= alue. >> However I would not want to have to filter through the list of return >> values >> to figure out which is the "root" one. Should this example have the >> rt=3Dace.est attribute on all of the links? > The example is an example and people can decide to do it differently. > Two alternatives: > - only return the root collection > - define additional rt values per resource > > You have a preference? I prefer the first approach I'm not clueful about this part, and generally quite fearful about parsing this stuff. Sure, it's easy in Ruby, but it's the constrained C code that I'm concerned about, so I don't understand the tradeoffs here. jim> * Suggest a strong recommendation on not use cmsVersion=3D1 to mak= e your life jim> easier. In other words: to not be PKCS7 compatible, but require CMS processing. I think this is reasonable from a specification point of view, but there has been pushback from people who have FIPS-140 libraries that they have hard times getting updated. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWudr+ICLcPvd0N1lAQLXlwf/Xu0iqP0UkxSNiW+SQlfBrVw08ZMcpj1H GtzCYgoF+PTkbI9je4PhJwEzMrJpWtpItwAdEqRaRF9qUE/PvjLroFwuf1tCar8d ZGFBO/sm40CDCAdmIAkjuAQEpcsZyRqQ6qiyn1SEXjQlRt6cp4xb/n5nFBz5vT6W +xKH2zbIhMScjDsEneKyEXU1Z0Ex424grNffdCB5grNgPp9WmD7noDqzxBqAXhmS 7FeL+d9PzWxVv+VZG6dgnLFo2wDKtrMu+XSjM/ceMGbT/nW1mok6bGIwrQc6Fc7z +Af4S5T5p2/ESo6HQKsxFyY06mTKW4ARNQ0STtZP3TDUs14dkApH/Q== =BSf0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 30 12:52:35 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20A4126D0C; Mon, 30 Apr 2018 12:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 6UOHadAHvBMv; Mon, 30 Apr 2018 12:52:31 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1D21200B9; Mon, 30 Apr 2018 12:52:31 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Apr 2018 12:49:56 -0700 From: Jim Schaad To: 'Michael Richardson' , CC: References: <030601d3de6e$2760f1f0$7622d5d0$@augustcellars.com> <24823.1525115896@obiwan.sandelman.ca> In-Reply-To: <24823.1525115896@obiwan.sandelman.ca> Date: Mon, 30 Apr 2018 12:52:24 -0700 Message-ID: <042701d3e0bc$c42d4150$4c87c3f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLCkQGC20XMmbNAiHDKQUp73z+Q4wKjAcVIoic7WjA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Anima] draft-richardson-anima-ace-constrained-voucher X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 19:52:34 -0000 > -----Original Message----- > From: Michael Richardson > Sent: Monday, April 30, 2018 12:18 PM > To: anima@ietf.org; Jim Schaad > Cc: draft-richardson-anima-ace-constrained-voucher@ietf.org > Subject: Re: draft-richardson-anima-ace-constrained-voucher > > > peter van der Stok wrote: > >> * Section 5 - you have a return of multiple items with the same rt value. > >> However I would not want to have to filter through the list of return > >> values > >> to figure out which is the "root" one. Should this example have the > >> rt=ace.est attribute on all of the links? > > > The example is an example and people can decide to do it differently. > > Two alternatives: > > - only return the root collection > > - define additional rt values per resource > > > > You have a preference? I prefer the first approach > > I'm not clueful about this part, and generally quite fearful about parsing this > stuff. Sure, it's easy in Ruby, but it's the constrained C code that I'm > concerned about, so I don't understand the tradeoffs here. There are a couple of questions that I would put here that I think guides things. * Is there any expectation that the path components would ever change for some implementation or are they always going to be the same? Would a request voucher always be posted to /rv or could an implementation change it to be /rvr? * Is there a reason for an endpoint to want to get what services are supported as a general rule rather than just assuming that if the root exists then all of the services are also going to exist. If the answer to the first question is no, then I don't know that they even need to have resource types. You get the root and go from there. If the answer to both questions is yes, then a different rt for every service would be needed so that they can be distinguished. If the answer to the first question is no and the second is yes, then it would make sense to define a generic rt='ace.est.service' so that the root and the list of services can be queried for individually. > > jim> * Suggest a strong recommendation on not use cmsVersion=1 to > make your life > jim> easier. > > In other words: to not be PKCS7 compatible, but require CMS processing. > > I think this is reasonable from a specification point of view, but there has > been pushback from people who have FIPS-140 libraries that they have hard > times getting updated. Just to be clear, they have updated the library sufficiently to be able to verify CMS messages but not to create them? We are also talking about libraries which have not been updated to deal with any 'new' crypto as that would not be supported by old bcrypt libraries as well. Note this is also an interesting question for how you are going to label the CBOR encoded voucher. If you use id-data, then the question is moot and everybody goes forward happy. On the other hand if you assign a new OID for this then it would need to be an ASN.1 object for the PKCKS7 people to encode based on my historic work with such packages. This is because for types which are not id-data the type and length bytes are stripped from the content before it is processed by the PKCS#7 library. Jim > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > From nobody Mon Apr 30 13:33:57 2018 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8B8127078; Mon, 30 Apr 2018 13:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 2EBM53op9ZdE; Mon, 30 Apr 2018 13:33:53 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482CB1270AB; Mon, 30 Apr 2018 13:33:53 -0700 (PDT) Received: from Jude (50.252.25.182) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 30 Apr 2018 13:31:19 -0700 From: Jim Schaad To: 'Michael Richardson' , CC: References: <030601d3de6e$2760f1f0$7622d5d0$@augustcellars.com> <24823.1525115896@obiwan.sandelman.ca> In-Reply-To: <24823.1525115896@obiwan.sandelman.ca> Date: Mon, 30 Apr 2018 13:33:46 -0700 Message-ID: <042801d3e0c2$8ba4d8b0$a2ee8a10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLCkQGC20XMmbNAiHDKQUp73z+Q4wKjAcVIoidJeKA= Content-Language: en-us X-Originating-IP: [50.252.25.182] Archived-At: Subject: Re: [Anima] draft-richardson-anima-ace-constrained-voucher X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 20:33:56 -0000 I had to go back and double check that I had things right but there is a trick that can be played for the PKCS#7 people. A new content type id-ct-cborVoucher can be defined with the content of "these are the CBOR encoded bytes". That is NO ASN.1 wrapper is included. This works well for CMS The people who are stuck in the old world of PKCS #7 can encode this by using the ASN.1 type of OCTET STRING for this OID. The signature/verification process for them will strip the OCTET STRING type and lengths and just sign/verify the content of the OCTET STRING. This is the same as would be done for CMS. This trick works only if the new content type is OCTET STRING and would fail for any other ASN.1 type Jim > -----Original Message----- > From: Michael Richardson > Sent: Monday, April 30, 2018 12:18 PM > To: anima@ietf.org; Jim Schaad > Cc: draft-richardson-anima-ace-constrained-voucher@ietf.org > Subject: Re: draft-richardson-anima-ace-constrained-voucher > > > Jim Schaad wrote: > > * In section 1 para #4 you appear to have a formatting error where a list > > was supposed to exist. > > Thanks, I fixed that in the markdown. > > peter van der Stok wrote: > >> * Section 5 - you have a return of multiple items with the same rt value. > >> However I would not want to have to filter through the list of return > >> values > >> to figure out which is the "root" one. Should this example have the > >> rt=ace.est attribute on all of the links? > > > The example is an example and people can decide to do it differently. > > Two alternatives: > > - only return the root collection > > - define additional rt values per resource > > > > You have a preference? I prefer the first approach > > I'm not clueful about this part, and generally quite fearful about parsing this > stuff. Sure, it's easy in Ruby, but it's the constrained C code that I'm > concerned about, so I don't understand the tradeoffs here. > > jim> * Suggest a strong recommendation on not use cmsVersion=1 to > make your life > jim> easier. > > In other words: to not be PKCS7 compatible, but require CMS processing. > > I think this is reasonable from a specification point of view, but there has > been pushback from people who have FIPS-140 libraries that they have hard > times getting updated. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >