From nobody Wed Mar 1 00:51:38 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600A71296A2 for ; Wed, 1 Mar 2017 00:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNyjH8AoSQkv for ; Wed, 1 Mar 2017 00:51:34 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D326B1294DA for ; Wed, 1 Mar 2017 00:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v218pCj2011824; Wed, 1 Mar 2017 09:51:12 +0100 (CET) Received: from [10.0.1.13] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vY8LS1kwNzDGwL; Wed, 1 Mar 2017 09:51:12 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2EA4DDB@nkgeml514-mbx.china.huawei.com> Date: Wed, 1 Mar 2017 09:51:11 +0100 X-Mao-Original-Outgoing-Id: 510051071.543913-e005731c590802c785a00d0a2cc58c17 Content-Transfer-Encoding: quoted-printable Message-Id: <07A8771E-0D92-40B2-B880-50EE58D816A1@tzi.org> References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E940C1@nkgeml514-mbx.china.huawei.com> <0c7b995c954746b8a58ae8a3399588ba@XCH-ALN-010.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E96D65@nkgeml514-mbx.china.huawei.com> <27173.1488308037@obiwan.sandelman.ca> <8AE0F17B87264D4CAC7DE0AA6C406F45C2EA4DDB@nkgeml514-mbx.china.huawei.com> To: "Liubing (Leo)" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Michael Richardson , "anima-bootstrap@ietf.org" , peter van der Stok , "Panos Kampanakis \(pkampana\)" , "Kumar, Sandeep" Subject: Re: [Anima-bootstrap] CoAP mandatory? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 08:51:37 -0000 On 1 Mar 2017, at 04:46, Liubing (Leo) wrote: >=20 > [Bing] I didn't quite followed the relative discussion. Is this = because that CoAP is seldom supported by Non-IoT devices (e.g. telecom = boxes)?=20 Well, ANIMA is rarely supported by Non-IoT devices either. So you implement it. (The afternoon you spend on implementing CoAP during that time is pretty = much inconsequential in the big picture.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 1 00:56:29 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D0D1294DA for ; Wed, 1 Mar 2017 00:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 ufv0ak0kRe79 for ; Wed, 1 Mar 2017 00:56:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196601294BF for ; Wed, 1 Mar 2017 00:56:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBX40222; Wed, 01 Mar 2017 08:56:17 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 1 Mar 2017 08:55:30 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 1 Mar 2017 16:55:24 +0800 From: "Liubing (Leo)" To: Carsten Bormann Thread-Topic: [Anima-bootstrap] CoAP mandatory? Thread-Index: AQHSZm3bDBkyKdzxNEmKd2cHh6652KEwahAAgAPLTRCASl+ygIABF8qA///SIoCAAIa2MA== Date: Wed, 1 Mar 2017 08:55:23 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2EA8533@nkgeml514-mbx.china.huawei.com> References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E940C1@nkgeml514-mbx.china.huawei.com> <0c7b995c954746b8a58ae8a3399588ba@XCH-ALN-010.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E96D65@nkgeml514-mbx.china.huawei.com> <27173.1488308037@obiwan.sandelman.ca> <8AE0F17B87264D4CAC7DE0AA6C406F45C2EA4DDB@nkgeml514-mbx.china.huawei.com> <07A8771E-0D92-40B2-B880-50EE58D816A1@tzi.org> In-Reply-To: <07A8771E-0D92-40B2-B880-50EE58D816A1@tzi.org> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58B68CB1.0251, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6fb0175b8f406722e4ad34b78e99510c Archived-At: Cc: Michael Richardson , "anima-bootstrap@ietf.org" , peter van der Stok , "Panos Kampanakis \(pkampana\)" , "Kumar, Sandeep" Subject: Re: [Anima-bootstrap] CoAP mandatory? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 08:56:25 -0000 SGkgQ2Fyc3RlbiwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDYXJz dGVuIEJvcm1hbm4gW21haWx0bzpjYWJvQHR6aS5vcmddDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWFy Y2ggMDEsIDIwMTcgNDo1MSBQTQ0KPiBUbzogTGl1YmluZyAoTGVvKQ0KPiBDYzogTWljaGFlbCBS aWNoYXJkc29uOyBhbmltYS1ib290c3RyYXBAaWV0Zi5vcmc7IHBldGVyIHZhbiBkZXIgU3RvazsN Cj4gUGFub3MgS2FtcGFuYWtpcyAocGthbXBhbmEpOyBLdW1hciwgU2FuZGVlcA0KPiBTdWJqZWN0 OiBSZTogW0FuaW1hLWJvb3RzdHJhcF0gQ29BUCBtYW5kYXRvcnk/DQo+IA0KPiBPbiAxIE1hciAy MDE3LCBhdCAwNDo0NiwgTGl1YmluZyAoTGVvKSA8bGVvLmxpdWJpbmdAaHVhd2VpLmNvbT4gd3Jv dGU6DQo+ID4NCj4gPiBbQmluZ10gSSBkaWRuJ3QgcXVpdGUgZm9sbG93ZWQgdGhlIHJlbGF0aXZl IGRpc2N1c3Npb24uIElzIHRoaXMgYmVjYXVzZSB0aGF0DQo+IENvQVAgaXMgc2VsZG9tIHN1cHBv cnRlZCBieSBOb24tSW9UIGRldmljZXMgKGUuZy4gdGVsZWNvbSBib3hlcyk/DQo+IA0KPiBXZWxs LCBBTklNQSBpcyByYXJlbHkgc3VwcG9ydGVkIGJ5IE5vbi1Jb1QgZGV2aWNlcyBlaXRoZXIuDQo+ IFNvIHlvdSBpbXBsZW1lbnQgaXQuDQo+IChUaGUgYWZ0ZXJub29uIHlvdSBzcGVuZCBvbiBpbXBs ZW1lbnRpbmcgQ29BUCBkdXJpbmcgdGhhdCB0aW1lIGlzIHByZXR0eQ0KPiBtdWNoIGluY29uc2Vx dWVudGlhbCBpbiB0aGUgYmlnIHBpY3R1cmUuKQ0KW0JpbmddIFN1cmU6KSANCkkgd2FzIGp1c3Qg Y3VyaW91cyBhYm91dCB3aHkgdGhlcmUgbWlnaHQgbm90IGJlIGNvbnNlbnN1cyBhcyBNaWNoYWVs IG1lbnRpb25lZC4NCg0KQmVzdCByZWdhcmRzLA0KQmluZw0KDQo+IEdyw7zDn2UsIENhcnN0ZW4N Cg0K From nobody Wed Mar 1 01:08:01 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41D512967E for ; Wed, 1 Mar 2017 01:07:59 -0800 (PST) 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 9kqUK6Ebh8n1 for ; Wed, 1 Mar 2017 01:07:57 -0800 (PST) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6FFD1296E7 for ; Wed, 1 Mar 2017 01:07:40 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.195]) by smtp-cloud2.xs4all.net with ESMTP id qZ7b1u00X4CYHle01Z7bAm; Wed, 01 Mar 2017 10:07:38 +0100 Received: from AMontpellier-654-1-112-77.w90-0.abo.wanadoo.fr ([90.0.87.77]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 01 Mar 2017 10:07:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Mar 2017 10:07:35 +0100 From: peter van der Stok To: Michael Richardson Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <27173.1488308037@obiwan.sandelman.ca> References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E940C1@nkgeml514-mbx.china.huawei.com> <0c7b995c954746b8a58ae8a3399588ba@XCH-ALN-010.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E96D65@nkgeml514-mbx.china.huawei.com> <27173.1488308037@obiwan.sandelman.ca> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Cc: anima-bootstrap@ietf.org, "Panos Kampanakis \(pkampana\)" , "Liubing \(Leo\)" , "Kumar, Sandeep" Subject: Re: [Anima-bootstrap] CoAP mandatory? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 09:08:00 -0000 From my point of view it will be more than nice, because bootstrap of IoT devices needing MASAs will be supported by the standards and the boxes using the standard. I am already happy that at this stage CoAP is considered being part of the anima bootstrapping architecture. Peter Michael Richardson schreef op 2017-02-28 19:53: > Liubing (Leo) wrote: > > So I guess once the new draft is adopted, BRSKI will choose the > CoAP > > as mandatory, right? > > To followup an old email thread. > > It would be nice (from my point of view), to do that, but I don't think > that > we have consensus to do that. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap From nobody Wed Mar 1 06:11:51 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6741294FA for ; Wed, 1 Mar 2017 06:11:50 -0800 (PST) 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, RP_MATCHES_RCVD=-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 yQyE4q9wuOei for ; Wed, 1 Mar 2017 06:11:48 -0800 (PST) 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 178361294E7 for ; Wed, 1 Mar 2017 06:11:48 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 76784E1E4; Wed, 1 Mar 2017 09:34:04 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B6EB36381A; Wed, 1 Mar 2017 09:11:46 -0500 (EST) From: Michael Richardson To: "anima-bootstrap\@ietf.org" In-Reply-To: <07A8771E-0D92-40B2-B880-50EE58D816A1@tzi.org> References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E940C1@nkgeml514-mbx.china.huawei.com> <0c7b995c954746b8a58ae8a3399588ba@XCH-ALN-010.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E96D65@nkgeml514-mbx.china.huawei.com> <27173.1488308037@obiwan.sandelman.ca> <8AE0F17B87264D4CAC7DE0AA6C406F45C2EA4DDB@nkgeml514-mbx.china.huawei.com> <07A8771E-0D92-40B2-B880-50EE58D816A1@tzi.org> X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: Carsten Bormann , peter van der Stok , "Panos Kampanakis \(pkampana\)" , "Liubing \(Leo\)" , "Kumar, Sandeep" Subject: Re: [Anima-bootstrap] CoAP mandatory? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 14:11:50 -0000 --=-=-= Content-Type: text/plain Carsten Bormann wrote: >> [Bing] I didn't quite followed the relative discussion. Is this >> because that CoAP is seldom supported by Non-IoT devices (e.g. telecom >> boxes)? > Well, ANIMA is rarely supported by Non-IoT devices either. Agreed. I don't expect IETF-notion IoT devices to support an ACP. (By this, I mean RFC7228 class 2 devices) One reason I'd like to have rfc7228bis define class 3 and 4 devices is because that's what the technical journalism think are IoT devices. If baby monitors (I'll call this class 3 for now) and home routers (I'll call this class 4) are "IoT", then yes, I *DO* expect IoT to support some of ANIMA. {I'd say that class 3 can speak client HTTP and TLS without simplification, and class 4 devices support a (web?) UI, and could participate as a leaf in an ACP. That would be *my* definitions without caring about ram/CPU/Mhz...} Even within the IETF, it seems that we have many categories of class 2 device: the power and network constraints between electric meter sensors (AMI has 802.15.4g PHYs and batteries that get charged regularly) and industrial sensors and light bulbs is pretty wide. The working environment that the ARM/TEEP people seem to be coming from seems like it's pretty rich compared to class 2: I think we are rapidly moving towards a place where code space and scratch ram are no longer significant limits, while wakefulness and network bandwidth continue to be limits. (I am recently involved in a project where a RPI/OrangePI 0 with mains and/or weekly battery changes may need to uplink via LoRAN. Makes me think of Marvin the Robot) I think that we can have a number of things in common. Frankly, I'm feeling a lot of pushback at this point, so please tell if you support these goals. 1) I'd like to have an ownership voucher format that is in common between IoT (class 2) devices and higher class devices. 2) I'd like JRCs to be able to enroll IoT devices as well as class 3+ devices. I don't mind if the JRC has to have totally different interfaces (HTTPS/EST vs CoAP/DTLS vs CoAP/OSCOAP/CoMI) for these differing envionments. 3) I think that the MASA/JRC interaction can be one protocol. In order for the ownership voucher to be easily processed by class 2 devices, there has to be a minimum of ASN.1 crud. If some is necessary, it should be easily faked with predefined const char crud[]={} constructs. OSCOAP/EDHOC seems to moving towords Curve25519, and perhaps EdDSA. I'm unclear if ACE will move from ECDSA to EdDSA. I'd like them to. Meanwhile, I'm unclear if hardware accel of asymmetric operations will apply to EdDSA as well as it does to ECDSA. I think that some devices, particularly TPM ones, are locked to ECDSA, and often the single p256 curve. This may lock us down for some time. This is an onwership voucher issue. [ASN.1 is bad for code space issues, but also because the code will be used once, and it's not gonna get a lot of attention] -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli21pgACgkQgItw+93Q 3WU2Wgf/bv+Y6mI2tnrqAUCqwpj5bhu8ntFfCyTlYWjkqFGhUfWn6a7P+wQbIfSi 8PBejfwTaii7PUW+FWQBxi1OO5K0gu6foYTqDDwOKQBmS2J+32dn3McsOnKn7YoR 9xdbCIzouwrfH05jhEKHZTnPYwtVXXm2zY5QKHpUHNPjI6Q/k92WGpQRwHkfgM1D xGhLIu3INORck+RuCXVjfD1RkoylZY1B8r1+wNXFp5L2iW98LmgV7qaqnQ+PUN8T aSllvGT9bEZgy3KiRbdNADJAJ8nPrw5iCZVgfj2pIrnbG6KMiYtdEZDFN5ouOR2A /dZfUZQlNs/YdNsrZqseVvAZtctl8Q== =AULR -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 1 06:37:52 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB7C129516 for ; Wed, 1 Mar 2017 06:37:49 -0800 (PST) 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, RP_MATCHES_RCVD=-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 ONiUzV6g3ubC for ; Wed, 1 Mar 2017 06:37:48 -0800 (PST) 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 D1CDF1294A3 for ; Wed, 1 Mar 2017 06:37:47 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 42685E20D; Wed, 1 Mar 2017 10:00:04 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6C9926381A; Wed, 1 Mar 2017 09:37:46 -0500 (EST) From: Michael Richardson To: "Liubing \(Leo\)" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2EA8533@nkgeml514-mbx.china.huawei.com> References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E940C1@nkgeml514-mbx.china.huawei.com> <0c7b995c954746b8a58ae8a3399588ba@XCH-ALN-010.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E96D65@nkgeml514-mbx.china.huawei.com> <27173.1488308037@obiwan.sandelman.ca> <8AE0F17B87264D4CAC7DE0AA6C406F45C2EA4DDB@nkgeml514-mbx.china.huawei.com> <07A8771E-0D92-40B2-B880-50EE58D816A1@tzi.org> <8AE0F17B87264D4CAC7DE0AA6C406F45C2EA8533@nkgeml514-mbx.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: Carsten Bormann , "anima-bootstrap@ietf.org" , peter van der Stok , "Panos Kampanakis \(pkampana\)" , "Kumar, Sandeep" Subject: Re: [Anima-bootstrap] CoAP mandatory? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 14:37:49 -0000 --=-=-= Content-Type: text/plain Liubing (Leo) wrote: > [Bing] Sure:) > I was just curious about why there might not be consensus as Michael mentioned. I think that there are three points of view: 1) ANIMA won't run on class 2 devices anyway, and bigger devices can just do HTTPS/EST. Why complicate my life? 2) The CoAP mechanism is not well enough defined as yet, so we don't know what it even means. Options are: CoAP/DTLS, CoAP/OSCOAP, CoAP/OSCOMP/CoMI (device is passive) IPIP proxy mechanism not well enough defined, so what does that even mean. Best to stick with things we know. 3) MyCompany wants to do mechanism X rather than CoAP, so if we can't have X, then let's specify a method too big for small devices, and in market confusion for small devices, MyCompany will dominate. (where X is various mixes of 1x, EAP, PANA, Thread, ZigbeeIP, etc.) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli23LAACgkQgItw+93Q 3WWQqAf/QyFkSwzTXhCIBHc/5Vw+6FyhCzEJESuCtSgNvXuhmJUx7v0Ig3n6Xb1b ukEWNv72TaCx7hxQ4+644EI550rEIhu6pWyouYn84U8/Rnr4vuL3wAwB6z3Wcsi0 yoIqPhaTMfiPlLih1Sf+mdyFZN5vbZfLbfmgwDloLQQCNVu/Y8dswMo3dZLsWAqA styiUX5B1F1aSRzUwmRZUZho/AqPozc215GMT3r8QZnrNM+XxgTTNbZnuuB0gi6j RQOHb99elz7qSJrfzBY/4z4dxe0Q2U400D4oEJAuSuqERAfILCMonh6rAiKAFGo3 XG7tR4HCfZl2eCzmIc5Zz8Ao4401lA== =RDWb -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 1 08:31:47 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFBE1295D7 for ; Wed, 1 Mar 2017 08:31:47 -0800 (PST) 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, RP_MATCHES_RCVD=-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 nDKxBlga3xjb for ; Wed, 1 Mar 2017 08:31:41 -0800 (PST) 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 CEA911295C9 for ; Wed, 1 Mar 2017 08:31:41 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 05ECAE1EE; Wed, 1 Mar 2017 11:53:59 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DA1E26381A; Wed, 1 Mar 2017 11:31:40 -0500 (EST) From: Michael Richardson To: anima-bootstrap@ietf.org In-Reply-To: <27b00b4c-0e38-688f-35de-20b1e492e948@gmail.com> References: <26901.1488237120@obiwan.sandelman.ca> <27b00b4c-0e38-688f-35de-20b1e492e948@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+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-bootstrap] agenda and details for Tuesday X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 16:31:47 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> And this led me to thing that the Registrar discovery probably needs a full >> NEG_SYN, rather than M_FLOOD or M_DISCOVER... > You could do both. Use Flood as the baseline and Negotiate or > Synchronize if the baseline info is insufficient. Please remind me if I've gotten the flow wrong, I just re-read section 3.8.4 and 3.8.5 and 3.8.6 of grasp-09. Does it go: Proxy Intermediate Join Registrar M_DISCOVERY --> MCAST M_DISCOVERY--->MCAST <---- unicast---- M_RESPONSE (I'm here) <----unicast---- M_RESPONSE (he is there) M_REQ_NEG ---------unicast-----------------> <--------------------------------- that is, the intermediate is just caching the location of the Join Registrar, and really if we want to do negotiation, we should do it directly? In this context, I don't see much difference, as you say, between M_DISCOVERY vs M_FLOOD, except for when it occurs and the need to keep the cache of things around. In either case, the locators that we were discussing ought really to only tell the Join Proxy where to find the Join Registrar's grasp daemon, not where to find the registration system itself. > I'm not sure if GRASP is Turing-equivalent, but I think you > can probably do anything you want. ha. I await the HAL9000 GRASP objective to be defined. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli2918ACgkQgItw+93Q 3WW+9gf8CzSuwQRYHRxygwSPAbTW6DhDE4qFjFbMhPOZZLJ9zRXf80V3lIIQpLKW edQ0anfrI81ZfoFVceTlKKBo3MwBiOu6Rg3/1EEa0S1pxCoUBua7Pv5kOrgyjEjp pMX7g7FkG9F2PR5ATRHblZ91LKrxW+GQ8LJB074YtnLLRsxTHfzioG87OizZeRrP 5vaL7fRKQK/3VkMwcZgxKm+MRHgF+67SOuUdW6awYc8aa5E154kJkQDz8A6UorQg fkyMeeainABeo5/lmSInYWiGmjlO4kB504U3HAp+WaFDxvE8XcR7YyfgSdYDebY6 QujqvrmkShR0ACTmBsDC+dcCmzkndg== =bKUr -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 1 14:14:42 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854F8128AB0 for ; Wed, 1 Mar 2017 14:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcWrDoG0fagN for ; Wed, 1 Mar 2017 14:14:40 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0136.outbound.protection.outlook.com [104.47.34.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36BB126D73 for ; Wed, 1 Mar 2017 14:14:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qIRYVsTvE5wJvYwUNtTCOAaci7btgIhwdkj7iYhaG4o=; b=g2AUJedxHkMsM9/TZhP44nGtsTYVPf0AsWw4OkaFv4UKmmn2rnSXcZAZdGDGn2DDIrZKV6mILm6n5eb/hcjptrMUk9Z2QHYG5G6fqvsZXGw6fFhl+QhlCWludhQMiFqJpv8dbclLDzrdWxDseOOaohQftn3g7ikSRWBV/w6lN4k= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Wed, 1 Mar 2017 22:14:38 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0947.011; Wed, 1 Mar 2017 22:14:38 +0000 From: Kent Watsen To: Michael Richardson , anima-bootstrap Thread-Topic: [Anima-bootstrap] voucher yang Thread-Index: AQHSke6O/yztceHfnUmp6ovkVBK+rqGAOr6A Date: Wed, 1 Mar 2017 22:14:38 +0000 Message-ID: <8CBC8F3C-E796-4042-8AFE-AFDC985DAEF5@juniper.net> References: <18454.1488305685@obiwan.sandelman.ca> In-Reply-To: <18454.1488305685@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 36eda6e6-893f-4968-b812-08d460f05a49 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:lxOM+vLPXn/agLPjQj0ka/TAU2N84/N5RHdHf1G4x4iCTWCx0pevJ0nRmqozsJhZlDoE24KtXekkO9cOqLLS8PYDEZqSP/hVUUcSDOohlaXHeu7Q5CsDU77xKcGacAVH1rdyMaWLupD6Z0FXKE1Gax3jFEX2j7myG8xEsMtiVzm774cHVWV4fe4BdGBo/lobe4dBjI9zKArANTDQRaGcKS0lrSOzD+Z908g/NOV4yw/4zi61GOeJsi4ZfHbORAlSPyVU/TrPSVBklLHW/3akoI9SiDrIpIeaIeSQBt5cYo4iWvdWJ9JXyqIfVRNlo50eCrPoiDNO0u5lplEpxAAUrg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39410400002)(39860400002)(39850400002)(51444003)(51914003)(7736002)(2900100001)(92566002)(83506001)(2906002)(36756003)(122556002)(6246003)(305945005)(82746002)(25786008)(3660700001)(6506006)(33656002)(6116002)(83716003)(6486002)(2950100002)(6436002)(3846002)(102836003)(99286003)(77096006)(3280700002)(86362001)(106116001)(189998001)(38730400002)(4001350100001)(6512007)(5660300001)(81166006)(8676002)(8936002)(76176999)(229853002)(50986999)(54356999)(66066001)(53936002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2017 22:14:38.8030 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [Anima-bootstrap] voucher yang X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 22:14:41 -0000 DQpIaSBNaWNoYWVsLA0KDQoNCj4gS2VudCwgdGhhbmtzIGZvciB0aGUgdXBkYXRlcyB0byB0aGUg WUFORyBmb3IgdGhlIHZvdWNoZXIuDQo+IFNvbWUgY29tbWVudHM6DQo+DQo+ICAgICAgbGVhZiBh c3NlcnRpb24gew0KPiAgICAgICAgZGVzY3JpcHRpb24NCj4gICAgICAgICAgIlRoZSBhc3NlcnRp b24gaXMgYSBzdGF0ZW1lbnQgZnJvbSB0aGUgTUFTQSByZWdhcmRpbmcgaG93DQo+ICAgICAgICAg ICB0aGUgb3duZXIgd2FzIHZlcmlmaWVkLiAgIFRoaXMgc3RhdGVtZW50IGVuYWJsZXMgcGxlZGdl cw0KPiAgICAgICAgICAgdG8gc3VwcG9ydCBtb3JlIGRldGFpbGVkIHBvbGljeSBjaGVja3MuICBQ bGVkZ2VzIE1VU1QNCj4gICAgICAgICAgIGVuc3VyZSB0aGF0IHRoZSBhc3NlcnRpb24gcHJvdmlk ZWQgaXMgYWNjZXB0YWJsZSBiZWZvcmUNCj4gICAgICAgICAgIHByb2Nlc3NpbmcgdGhlIHZvdWNo ZXIuIjsNCj4NCj5JIHRoaW5rIHRoYXQgaXQncyBtb3JlIGFib3V0IHRoZSByZWdpc3RyYXIgdGhh biB0aGUgcGxlZGdlIGFjdGl2aXR5Lg0KDQpXaGlsZSB0aGUgcmVnaXN0cmFyIGNhbiBpbnNwZWN0 IHRoZSB2b3VjaGVyLCBpdCB1bHRpbWF0ZWx5IG11c3QgcGFzcw0KaXQgdG8gdGhlIHBsZWRnZSB1 bm1vZGlmaWVkLiAgQWxzbywgbm90ZSB0aGF0IHRoZXJlIG5vICJyZWdpc3RyYXIiIA0KY29uY2Vw dCBpbiB0aGUgTkVUQ09ORiB6ZXJvdG91Y2ggZHJhZnQuDQoNCg0KPiAgICAgICAgbGVhZiBzdWJq ZWN0LWhhc2ggew0KPiAgICAgICAgICB0eXBlIGJpbmFyeTsNCj4gICAgICAgICAgZGVzY3JpcHRp b24NCj4NCj4gV2lsbCB0aGVyZSBiZSBhbiB1cGRhdGUgdG8gUkZDNTI4MCB0aGF0IHdpbGwgdW5s b2NrIHVzIGZyb20gU0hBLTE/DQo+IEFyZSBhbGwgb2Ygc3ViamVjdC1oYXNoL2NuLWlkL2Rucy1p ZCByZXF1aXJlZCwgb3IgaXMgaXQgb25lIG9mIHRoZSBhYm92ZT8NCg0KQXMgdGhlIGRlc2NyaXB0 aW9uIHN0YXRlbWVudCBleHBsYWlucywgU0hBLTEgaXMgdXNlZCBiZWNhdXNlIGl0IGlzDQppbnRl cm9wZXJhYmxlIHdpdGggT3BlblNTTC4gIFdlIGNvdWxkIGhhcmRjb2RlIFNIQS0yNTYsIG9yIGV2 ZW4gYWxsb3cNCml0IGJlIHRvIHBhcmFtZXRlcml6ZWQsIGJ1dCB0aGF0IHdvdWxkIHB1dCBtb3Jl IGNvZGUgb24gdGhlIHBsZWRnZXMsDQpkbyB5b3Ugd2FudCB0byBnbyB0aGlzIHJvdXRlPw0KDQoN Cj4gICAgICBsZWFmLWxpc3QgZGV2aWNlLWlkZW50aWZpZXIgew0KPiAgICAgICAgdHlwZSBzdHJp bmc7DQo+ICAgICAgICBtaW4tZWxlbWVudHMgMTsNCj4gICAgICAgIGRlc2NyaXB0aW9uDQo+ICAg ICAgICAgICJBIG5vbi1lbXB0eSBsaXN0IG9mIFBPU0lYIHJlZ3VsYXIgZXhwcmVzc2lvbnMsIGVh Y2gNCj4gICAgICAgICAgIGlkZW50aWZ5aW5nIG9uZSBvciBtb3JlIGRldmljZSBpZGVudGlmaWVy cyAoZS5nLiwgc2VyaWFsDQo+ICAgICAgICAgICBudW1iZXJzKS4gRm9yIGluc3RhbmNlLCB0aGUg ZXhwcmVzc2lvbiBjb3VsZCBtYXRjaCBqdXN0DQo+ICAgICAgICAgICBhIHNpbmdsZSBzZXJpYWwg bnVtYmVyLCBvciBpdCBtaWdodCBtYXRjaCBhIHJhbmdlIG9mDQo+ICAgICAgICAgICBzZXJpYWwg bnVtYmVycy4NCj4NCj4gICAgICAgICAgIFdoZW4gcHJvY2Vzc2luZyBhIHZvdWNoZXJzLCBwbGVk Z2VzIE1VU1QgZW5zdXJlIHRoYXQgdGhlaXINCj4gICAgICAgICAgIHVuaXF1ZSBpZGVudGlmaWVy IG1hdGNoZXMgYXQgbGVhc3Qgb25lIHJlZ3VsYXIgZXhwcmVzc2lvbiBpbg0KPiAgICAgICAgICAg dGhlIGxpc3QuICBJZiBubyBtYXRjaGluZyByZWd1bGFyIGV4cHJlc3Npb24gaXMgZm91bmQsIHRo ZQ0KPiAgICAgICAgICAgcGxlZGdlIE1VU1QgTk9UIHByb2Nlc3MgdGhpcyB2b3VjaGVyLiI7DQo+ DQo+IE9oLCB3b3cuIEknZCByZWFsbHkgcmF0aGVyIG5vdCBoYXZlIGEgcmVnZXggaGVyZSENCj4g SSdtIG1vcmUgd29ycmllZCBhYm91dCB0aGUgcG9zc2libGUgVHVyaW5nLWNvbXBsZXRlbmVzcyBv ZiB0aGUgcmVnZXggcmF0aGVyDQo+IHRoYW4gdGhlIGNvZGUgc3BhY2UgaXNzdWUuICBJIHRoaW5r IGluIElvVCwgaWYgdGhlIGRldmljZSBoYXNuJ3QgZ290IGENCj4gcmVnZXggcGFyc2VyLCB0aGVu IHRoZSB2ZW5kb3IganVzdCB3b24ndCBpc3N1ZSB2b3VjaGVycyB3aXRoIHJlZ2V4IGluIHRoZW0s DQo+IHNvIHRoYXQgaXMgb2theS4NCj4gSWYgd2UgaGF2ZSB0bywgSSBndWVzcyBJJ2QgcmF0aGVy IGhhdmUgYSBQQ1JFIGlmIHdlIGNhbiBmaW5kIGEgc3BlY2lmaWNhdGlvbg0KPiBmb3IgdGhhdC4N Cg0KSSdtIG9rYXkgd2l0aCBQQ1JFIGluIHRoZW9yeSwgYnV0IEkndmUgcmVhZCB0aGF0IGEgY29t cGlsZWQgc3RyaXBwZWQgDQpsaWJyYXJ5IGlzIGxhcmdlLCBkbyB5b3Uga25vdz8NCg0KDQo+ICAg ICAgbGVhZiBub25jZSB7DQo+ICAgICAgICB0eXBlIHN0cmluZzsgIC8vIHVuaXQ2ND8NCj4NCj4g SSB0aGluayBpdCBzaG91bGQgYmUgYmluYXJ5Pw0KDQpBICdiaW5hcnknIHR5cGUgd291bGQgYWxs b3cgdGhlIG5vbmNlIHRvIGJlIGFueSBsZW5ndGggb2N0ZXQgc2VxdWVuY2UsDQp3aGljaCBpcyBj b252ZXJ0ZWQgdG8gYmFzZTY0IGVuY29kZWQgc3RyaW5nIGZvciBKU09OLiAgSXMgdGhpcyB3aGF0 IA0KeW91IHdhbnQ/DQoNCg0KS2VudA0KDQoNCg0K From nobody Wed Mar 1 17:07:08 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FFE129445 for ; Wed, 1 Mar 2017 17:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luBpwUg7JmYT for ; Wed, 1 Mar 2017 17:07:06 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 83CA9129431 for ; Wed, 1 Mar 2017 17:07:06 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id w189so16109764pfb.0 for ; Wed, 01 Mar 2017 17:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=a4a/NxAZGx3i9m/LZrt1iOVgdG5ei/EWxtNLd7pmZCE=; b=daJIKbjEpmabqhEjD/mK6IeVf5kVQ4+D+48ZB5CF+7K+51qje93JHEudP7wkJWqrRq KR3oSPIiKODw3HlOa3w1kOKgljcC3AlXDiGMGcmyd0M4D8ckEMKmfGpFqx0X/Zz9xaWh iKpvv6I7tVdYPt+mcMjgPoyBTtUYz1VS9qh6BDMbfZ6hd10fWJn4qAfwc6zbnR/actlM tLhSNAPuCV6Fox9251UX7J0CfkSCvClmfezaz16vzXIfUc08lhWKjSgVIrvHrfHUpga8 /uuxvFIFdI3QdIMsptSvZkT94mUmmeV66v6Fm5ZeA3NzDVygZBQGBCculIjxeqCdjTXT xrGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=a4a/NxAZGx3i9m/LZrt1iOVgdG5ei/EWxtNLd7pmZCE=; b=g9Xh09n2FxrK8dchhBvSKaFsoyQ4SDr5k/M0w442WSzEJyFxuOQLrY12rZHW8Xy1bs EHQyN6EsIDnsX0EFDGxQ94i1it7XJ0T1xCIjVu3B+8FDUvUuTgeEfeO3zG6dYMxRBIeP /uFKKAdAAIP5XbtEe/bQpRyemekW5DIjDdQElq7q8/i9af7CgFaZG6ZFs18/KiH3kZ+A 2w48lce6wFbvMhLRw2ZuzuO0g5/VXIgaKu8AAkaBqBgPYZjBMFsnnyhiW2S5eop16DMa QQuUePpIhfEceF6XS7/0a08IiczEm7+n88ocjlYCIFJDNFfm2xwPl5rP0x68KM/Q28hR T6PA== X-Gm-Message-State: AMke39nnIUIfdJ5VGwo6BObAwPR0Fxue5l90+qgP3vM7DPnCBWWg0H+a3blJQtH9UuIbGw== X-Received: by 10.99.228.69 with SMTP id i5mr12501566pgk.63.1488416825925; Wed, 01 Mar 2017 17:07:05 -0800 (PST) Received: from ?IPv6:2406:e007:6663:1:28cc:dc4c:9703:6781? ([2406:e007:6663:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d72sm6366097pfb.21.2017.03.01.17.07.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Mar 2017 17:07:05 -0800 (PST) To: Michael Richardson , anima-bootstrap@ietf.org References: <26901.1488237120@obiwan.sandelman.ca> <27b00b4c-0e38-688f-35de-20b1e492e948@gmail.com> <20476.1488385900@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <598a826a-5c6a-589b-8c7f-a3c4f1cfcbbc@gmail.com> Date: Thu, 2 Mar 2017 14:07:08 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20476.1488385900@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima-bootstrap] agenda and details for Tuesday X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 01:07:07 -0000 On 02/03/2017 05:31, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> And this led me to thing that the Registrar discovery probably needs a full > >> NEG_SYN, rather than M_FLOOD or M_DISCOVER... > > > You could do both. Use Flood as the baseline and Negotiate or > > Synchronize if the baseline info is insufficient. > > Please remind me if I've gotten the flow wrong, I just re-read section 3.8.4 > and 3.8.5 and 3.8.6 of grasp-09. > > Does it go: > Proxy Intermediate Join Registrar > > M_DISCOVERY --> MCAST > M_DISCOVERY--->MCAST > <---- unicast---- M_RESPONSE (I'm here) > > <----unicast---- M_RESPONSE (he is there) > > M_REQ_NEG ---------unicast-----------------> > <--------------------------------- > > > that is, the intermediate is just caching the location of the Join Registrar, > and really if we want to do negotiation, we should do it directly? Yes, once you have discovered the address. (And discovery is only supposed to return a global-scope address, typically ULA, except for the special case where the target is on-link and no global-scope address is available.) > In this context, I don't see much difference, as you say, between M_DISCOVERY > vs M_FLOOD, except for when it occurs and the need to keep the cache of > things around. In either case, the locators that we were discussing ought > really to only tell the Join Proxy where to find the Join Registrar's > grasp daemon, not where to find the registration system itself. Sure. The extra tweak in M_FLOOD is that you MAY attach a specific locator to the flooded objective, in case you don't want to perform a follow-up M_REQ_NEG (or M_REQ_SYN). Brian > > > I'm not sure if GRASP is Turing-equivalent, but I think you > > can probably do anything you want. > > ha. I await the HAL9000 GRASP objective to be defined. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Wed Mar 1 17:53:01 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9008B129479; Wed, 1 Mar 2017 17:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 nLU1ch8BUknt; Wed, 1 Mar 2017 17:52:55 -0800 (PST) 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 2ED031293F5; Wed, 1 Mar 2017 17:52:55 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BF7B0E20F; Wed, 1 Mar 2017 21:15:10 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5596F6381A; Wed, 1 Mar 2017 20:52:51 -0500 (EST) From: Michael Richardson To: SPASM In-Reply-To: <18454.1488305685@obiwan.sandelman.ca> References: <18454.1488305685@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: anima-bootstrap Subject: [Anima-bootstrap] SHA1 usage in Anima-bootstrap voucher yang X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 01:52:56 -0000 --=-=-= Content-Type: text/plain In the ANIMA ownership voucher YANG model, the absolute latest which you can currently see at: https://github.com/anima-wg/voucher/blob/master/draft-ietf-anima-voucher-01.txt we write at line 574: leaf subject-hash { type binary; description "The certificate's entire subject field MUST match this value. This value is calculated as the SHA-1 hash over the TBSCertificate's subject structure, as specified by RFC 5280 Section 4.1.2.6, encoded using the ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690. Note: by using the SHA-1 algorithm, the result can be easily compared to OpenSSL's 'subject_hash' output."; } The voucher is a signed artifact (PKCS7? JWT? CWT? TBD) which indicates to a particular device who the devices owner is. ("Are you my mummy?" for Dr.Who Fans) For reasons of key hygiene and longevity, in many cases we do not want to point at the public key of the registrar directly, but rather indicate that it's DN=Foo, as signed by CA=Bar. It seems like there ought be a better way to do this kind of thing than what we specify above, which is annoyingly SHA1 linked. Can SPASM offer any advice? We could list the actual DER itself. Encoded, it might actually not be bigger than a SHA256, for instance. That might have privacy implications though, which we'd need to think through. Some time ago, I proposed replicating the SIDR artifact (RFC3779), and copy and pasted it to make: https://www.ietf.org/archive/id/draft-richardson-anima-idevid-cert-00.txt but, we didn't really want to go exactly that way. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli3evIACgkQgItw+93Q 3WVvoAf+O9mDTyPtXmu0kdFK+jKTQ7bOBu42B54CLP1h5z4q99nf3mpi5XvAG9s+ dWMLGKUe79bES0kQtsNeAdi9ugraCTimwEidZuwi+eCuYWnF1Gqh+xydOhCCqk3X vMdwxhtlfSOm0v5oCjOe1DyuHaGUTdpilFQTbSl8HUIEa3tT89tQLWlfBwAX4+vD KxJUgS6n/rsTcO5MRn0lZ1YkRSeXFKpARWGPtYL2/qWMGinakdZVjtUKSxzR8cTt XYPrrgDCkSh5lR+sz/a2yqjaubPn5FSesMGoRtRvm7AwDgM24STlFocSYbgh4iZR AXIYkH4JeKSbZz2zuEYidHZ09/Tncw== =ouYz -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 1 18:39:31 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F133F129717 for ; Wed, 1 Mar 2017 18:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 ltzTT_V1HO92 for ; Wed, 1 Mar 2017 18:39:29 -0800 (PST) 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 2B3F9129407 for ; Wed, 1 Mar 2017 18:39:29 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 78BED2009E; Wed, 1 Mar 2017 22:01:47 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E6CF96381A; Wed, 1 Mar 2017 21:39:27 -0500 (EST) From: Michael Richardson To: Kent Watsen In-Reply-To: <8CBC8F3C-E796-4042-8AFE-AFDC985DAEF5@juniper.net> References: <18454.1488305685@obiwan.sandelman.ca> <8CBC8F3C-E796-4042-8AFE-AFDC985DAEF5@juniper.net> X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: anima-bootstrap Subject: Re: [Anima-bootstrap] voucher yang X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 02:39:31 -0000 --=-=-= Content-Type: text/plain Kent Watsen wrote: > Hi Michael, >> Kent, thanks for the updates to the YANG for the voucher. >> Some comments: >> >> leaf assertion { >> description >> "The assertion is a statement from the MASA regarding how >> the owner was verified. This statement enables pledges >> to support more detailed policy checks. Pledges MUST >> ensure that the assertion provided is acceptable before >> processing the voucher."; >> >> I think that it's more about the registrar than the pledge activity. > While the registrar can inspect the voucher, it ultimately must pass > it to the pledge unmodified. Also, note that there no "registrar" > concept in the NETCONF zerotouch draft. What I'm saying is that the pledge can't know how the owner was verified. The pledge actually has to process the same as for "verified" as for "logged". It doesn't change the pledge's behaviour. >> Will there be an update to RFC5280 that will unlock us from SHA-1? >> Are all of subject-hash/cn-id/dns-id required, or is it one of the above? > As the description statement explains, SHA-1 is used because it is > interoperable with OpenSSL. We could hardcode SHA-256, or even allow > it be to parameterized, but that would put more code on the pledges, > do you want to go this route? If we have to pick something, let's pick SHA256 for now, or maybe, as I wrote in the other message I CC to spasm, maybe we should just put the DER itself? >> Oh, wow. I'd really rather not have a regex here! >> I'm more worried about the possible Turing-completeness of the regex rather >> than the code space issue. I think in IoT, if the device hasn't got a >> regex parser, then the vendor just won't issue vouchers with regex in them, >> so that is okay. >> If we have to, I guess I'd rather have a PCRE if we can find a specification >> for that. > I'm okay with PCRE in theory, but I've read that a compiled stripped > library is large, do you know? I don't know. I don't want either :-) If I have to pick a regex library (vs shell-style globbing...) then I'd rather pick PCRE if we can find a stable reference. >> leaf nonce { >> type string; // unit64? >> >> I think it should be binary? > A 'binary' type would allow the nonce to be any length octet sequence, > which is converted to base64 encoded string for JSON. Is this what > you want? I want as much entropy in as small a space as possible. string seems to waste 2-bits per byte if it's base64 encoded in a binary format (CBOR). If JSON has to base64 encode things, I'm okay with that. I would assume that integers get network-byte order considerations which might lead to implementation bugs, where as binary[8] (if such a thing exists) would not. I think uint64 might be too small. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli3hd8ACgkQgItw+93Q 3WV+tQgArJqEmpo4nwrnlShei+ftshfewCP04x6n9v9DDy4tQJ8T3KQVO+NMNFZc KBxVRjbugYr9946WGHBmobsQnvlRmR0rPT62r8Fz/m0+Xpca7BZBC7i1yij1SA5a VvuwjctH/qG8aA4ZNUJT/fodj0U4mrZxVBki1IhrXsX5ymME39yn7Qc1T2PFHE+J FcH1zYUHiOYFgUDMHoMuh7bFVNzfdjlqt+Uoq3FndiVOC0UG7i6chCrFFyyEFR3g So3+ADDMSvJpgjZCwpzIJ3g+q/o9sqyBVHgcUm5MEL8U0JWQ4hZc4j82J08TJSoC WFb4z1XWNO1cXGLOgLdpD6IaFa/Q+w== =cqSe -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 2 06:49:55 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B78612949B for ; Thu, 2 Mar 2017 06:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 wtg3bezUpMtq for ; Thu, 2 Mar 2017 06:49:52 -0800 (PST) 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 6C43B129491 for ; Thu, 2 Mar 2017 06:49:52 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A953A2009E; Thu, 2 Mar 2017 10:12:12 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5D85F636BB; Thu, 2 Mar 2017 09:49:51 -0500 (EST) From: Michael Richardson To: anima-bootstrap In-Reply-To: References: <20170221155002.GA8168@faui40p.informatik.uni-erlangen.de> <6b414f54-4164-5c9d-390e-30d21f786cca@gmail.com> <18032.1487866082@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: Toerless Eckert Subject: Re: [Anima-bootstrap] Brian: GRASP parameter for registrar discovery by proxy X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 14:49:53 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > That seems a bit disjoint from "proxy needs to find registrar". And it > definitely > sounds like a two-way conversation, which would more naturally be > modelled as > a negotiation. Can you change that from a "what if?" to a more specific > requirement that we can model? There are two aspects. 1) In the Circuit Proxy case, it would be good if the Registrar was able to point the Join Proxy at a different device. Or rather, decline to serve it, "too busy". M_FLOOD/M_DISCOVER does not provide for this. 2) In the IPIP case, it might make some implementations easier if the Registrar was aware of the Join Proxy before the traffic arrives, so that the Registrar could configure the appropriate virtual interfaces. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli4MQ4ACgkQgItw+93Q 3WWuNQgArF03YgZZkf8GRs/A0KNv9kpN7Y5xGMnQVRpcz9lYkUDfzGvvEZk/pftK CNniYPTSw7lO18MCLGAL3l6ryGyGqCXCogIM5DKGmMLyhKii9Ka9W+jKaty/gAyj 1gyEWXhbSXuy9naaxRond4yqSVmn0gUXaO3kzpBgWZdin/hrbIDBrTGzruq6z+XL HMkIsnwUOIpbu9U4VwRkdOJ+ePNXbxSzJL6uThnHDkB4L5Y1VvFCl1zMSBCoR1o1 jKpiWezg3QRJjVOsbRyUzsUMRR/jRFtSbEe2oRFOXHToi2HRjq0TtDANzRACxAdr HnQWDBfRMgu9K8pyj5dLLmKWOEcDkw== =9QeN -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 2 11:13:03 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD58512960D for ; Thu, 2 Mar 2017 11:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4aYIGjlScye for ; Thu, 2 Mar 2017 11:13:00 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0129.outbound.protection.outlook.com [104.47.33.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6C81293EC for ; Thu, 2 Mar 2017 11:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N2GvwEbtf7m5aKO8A0uKGDwDYSqpDluvvnZsYnVXE7I=; b=JgHHBQl/QOPmohIvVzc1q7bEpAfM+AnDcumuX73zXhQZudhJLPUv1sIr2PbNHCCQnfctqL6vdh1Jn55t9NE2ljMHfbsVGO04z6bQRSx/HTWZTPRlNi5ibtprYmVXigkxzdnZQO64eh4pqK35/H4o+mNZs0MR6/ApgT2rq28l7KE= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Thu, 2 Mar 2017 19:12:58 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0947.011; Thu, 2 Mar 2017 19:12:58 +0000 From: Kent Watsen To: Michael Richardson Thread-Topic: [Anima-bootstrap] voucher yang Thread-Index: AQHSke6O/yztceHfnUmp6ovkVBK+rqGAOr6AgACd0ICAAMHCAA== Date: Thu, 2 Mar 2017 19:12:57 +0000 Message-ID: <2C1C2636-DE14-4570-99E8-72AEB0B9D57D@juniper.net> References: <18454.1488305685@obiwan.sandelman.ca> <8CBC8F3C-E796-4042-8AFE-AFDC985DAEF5@juniper.net> <25053.1488422367@obiwan.sandelman.ca> In-Reply-To: <25053.1488422367@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 22882381-952b-45da-3bff-08d461a02350 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:I203doETPTYPuWB+glzXniEe/Kk3qSRwbbuD94mc2tpE6B7eqcckDoDfE9kKPeYu763+2tVKlme71Vu4iiyMmIkqH8KbvQ9l7yyFGaxoFHwK3OTT1HyKFmbK2R0jV6UM/fubxNFcfhteU0AJQGEsrSOOeYxnjCMgNtW2hhk8Vk0ahXU0Eighxyh/IzBtoEbDhX05E/exu2B5unSVH413eOUvLBo0uHZ3L8tP1d5ZeCsYmAHkkhnCtMaOgyb4miHpHdUAjrL+6fT3inye+PJlDiOAbUsskn2wqv9n/Y+IuaYqPu1fLAIw/2BuNhOQ+x5vHcO7QU7/v1DCetX957JF1A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(20161123558025)(20161123562025)(20161123560025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 023495660C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39450400003)(39860400002)(39840400002)(33656002)(7736002)(6246003)(2900100001)(83506001)(36756003)(122556002)(3660700001)(305945005)(25786008)(6512007)(3846002)(6116002)(6486002)(77096006)(6436002)(4326008)(2950100002)(99286003)(102836003)(6506006)(3280700002)(2906002)(92566002)(189998001)(110136004)(38730400002)(4001350100001)(5660300001)(76176999)(229853002)(8676002)(50986999)(54356999)(8936002)(81166006)(66066001)(53936002)(86362001)(106116001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2017 19:12:57.9954 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Cc: anima-bootstrap Subject: Re: [Anima-bootstrap] voucher yang X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 19:13:02 -0000 DQo+PiBXaGlsZSB0aGUgcmVnaXN0cmFyIGNhbiBpbnNwZWN0IHRoZSB2b3VjaGVyLCBpdCB1bHRp bWF0ZWx5IG11c3QgcGFzcw0KPj4gaXQgdG8gdGhlIHBsZWRnZSB1bm1vZGlmaWVkLiAgQWxzbywg bm90ZSB0aGF0IHRoZXJlIG5vICJyZWdpc3RyYXIiDQo+PiBjb25jZXB0IGluIHRoZSBORVRDT05G IHplcm90b3VjaCBkcmFmdC4NCj4NCj4gV2hhdCBJJ20gc2F5aW5nIGlzIHRoYXQgdGhlIHBsZWRn ZSBjYW4ndCBrbm93IGhvdyB0aGUgb3duZXIgd2FzIHZlcmlmaWVkLg0KPiBUaGUgcGxlZGdlIGFj dHVhbGx5IGhhcyB0byBwcm9jZXNzIHRoZSBzYW1lIGFzIGZvciAidmVyaWZpZWQiIGFzIGZvcg0K PiAibG9nZ2VkIi4gIEl0IGRvZXNuJ3QgY2hhbmdlIHRoZSBwbGVkZ2UncyBiZWhhdmlvdXIuDQoN CkJ1dCBpdCBkb2VzLiAgU29tZSBwbGVkZ2VzIG1heSBiZSBjb2RlZCB0byBvbmx5IHN1cHBvcnQg J3ZlcmlmaWVkJyB2b3VjaGVycy4NCg0KDQo+PiBBcyB0aGUgZGVzY3JpcHRpb24gc3RhdGVtZW50 IGV4cGxhaW5zLCBTSEEtMSBpcyB1c2VkIGJlY2F1c2UgaXQgaXMNCj4+IGludGVyb3BlcmFibGUg d2l0aCBPcGVuU1NMLiAgV2UgY291bGQgaGFyZGNvZGUgU0hBLTI1Niwgb3IgZXZlbiBhbGxvdw0K Pj4gaXQgYmUgdG8gcGFyYW1ldGVyaXplZCwgYnV0IHRoYXQgd291bGQgcHV0IG1vcmUgY29kZSBv biB0aGUgcGxlZGdlcywNCj4+IGRvIHlvdSB3YW50IHRvIGdvIHRoaXMgcm91dGU/DQo+DQo+IElm IHdlIGhhdmUgdG8gcGljayBzb21ldGhpbmcsIGxldCdzIHBpY2sgU0hBMjU2IGZvciBub3csIG9y IG1heWJlLCBhcyBJIHdyb3RlDQo+IGluIHRoZSBvdGhlciBtZXNzYWdlIEkgQ0MgdG8gc3Bhc20s IG1heWJlIHdlIHNob3VsZCBqdXN0IHB1dCB0aGUgREVSIGl0c2VsZj8NCg0KVGhlIERFUiBpdHNl bGYgd29ya3MgZm9yIG1lICh0aGUgcHJpdmFjeSBjb25jZXJuIHNlZW1zIG1pbm9yKS4gIEl0J3Mg YWxzbyBtb3JlDQpjb2RlIChyZWxhdGl2ZSB0byBqdXN0IHVzaW5nIGFuIG9wZW5zc2wgY29tbWFu ZCBsaW5lIG9wdGlvbiksIGJ1dCBhY3R1YWxseSBpdCdzDQpvbmUgc3RlcCBsZXNzIGNvZGUgdGhh biBjYWxjdWxhdGluZyB0aGUgU0hBMjU2IGZpbmdlcnByaW50Lg0KDQoNCj4+IEknbSBva2F5IHdp dGggUENSRSBpbiB0aGVvcnksIGJ1dCBJJ3ZlIHJlYWQgdGhhdCBhIGNvbXBpbGVkIHN0cmlwcGVk DQo+PiBsaWJyYXJ5IGlzIGxhcmdlLCBkbyB5b3Uga25vdz8NCj4NCj4gSSBkb24ndCBrbm93LiBJ IGRvbid0IHdhbnQgZWl0aGVyIDotKQ0KPiBJZiBJIGhhdmUgdG8gcGljayBhIHJlZ2V4IGxpYnJh cnkgKHZzIHNoZWxsLXN0eWxlIGdsb2JiaW5nLi4uKSB0aGVuIA0KPiBJJ2QgcmF0aGVyIHBpY2sg UENSRSBpZiB3ZSBjYW4gZmluZCBhIHN0YWJsZSByZWZlcmVuY2UuDQoNCkFzIGRpc2N1c3NlZCBp biBhbm90aGVyIHRocmVhZCwgSSdtIGJlZ2lubmluZyB0byB0aGluayB0aGF0IHdlIHNob3VsZA0K ZG8gYXdheSB3aXRoIGhhdmluZyBhIHNpbmdsZSB2b3VjaGVyIGZvciBtYW55IGRldmljZXMsIGJl Y2F1c2Ugd2UnZA0Kd2FudCByZXZvY2F0aW9ucyB0byBiZSBhcyBncmFudWxhciBhcyBwb3NzaWJs ZS4NCg0KDQo+PiBBICdiaW5hcnknIHR5cGUgd291bGQgYWxsb3cgdGhlIG5vbmNlIHRvIGJlIGFu eSBsZW5ndGggb2N0ZXQgc2VxdWVuY2UsDQo+PiB3aGljaCBpcyBjb252ZXJ0ZWQgdG8gYmFzZTY0 IGVuY29kZWQgc3RyaW5nIGZvciBKU09OLiAgSXMgdGhpcyB3aGF0DQo+PiB5b3Ugd2FudD8NCj4N Cj4gSSB3YW50IGFzIG11Y2ggZW50cm9weSBpbiBhcyBzbWFsbCBhIHNwYWNlIGFzIHBvc3NpYmxl Lg0KPiBzdHJpbmcgc2VlbXMgdG8gd2FzdGUgMi1iaXRzIHBlciBieXRlIGlmIGl0J3MgYmFzZTY0 IGVuY29kZWQgaW4gYSBiaW5hcnkNCj4gZm9ybWF0IChDQk9SKS4gIElmIEpTT04gaGFzIHRvIGJh c2U2NCBlbmNvZGUgdGhpbmdzLCBJJ20gb2theSB3aXRoIHRoYXQuDQo+DQo+IEkgd291bGQgYXNz dW1lIHRoYXQgaW50ZWdlcnMgZ2V0IG5ldHdvcmstYnl0ZSBvcmRlciBjb25zaWRlcmF0aW9ucyB3 aGljaA0KPiBtaWdodCBsZWFkIHRvIGltcGxlbWVudGF0aW9uIGJ1Z3MsIHdoZXJlIGFzIGJpbmFy eVs4XSAoaWYgc3VjaCBhIHRoaW5nDQo+IGV4aXN0cykgd291bGQgbm90LiAgSSB0aGluayB1aW50 NjQgbWlnaHQgYmUgdG9vIHNtYWxsLg0KDQpPa2F5LCBsZXQncyBjaGFuZ2UgdGhlIG5vbmNlIHRv IGEgYmluYXJ5IHR5cGUuDQoNCg0KS2VudA0KDQoNCg== From nobody Thu Mar 2 18:01:53 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94BB12946E for ; Thu, 2 Mar 2017 18:01:52 -0800 (PST) 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 hPbM0HP0WOLq for ; Thu, 2 Mar 2017 18:01:51 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 B2ECF129455 for ; Thu, 2 Mar 2017 18:01:51 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id s67so11037987pgb.1 for ; Thu, 02 Mar 2017 18:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=th9hPiebWb3cHx+bHXFpTvFM7eAWq/GLsMxECcNWDL8=; b=Kq2Qs+eJe5a0CuenIq5EePAKCEF7bmXboKW6GtTNX8gXvXA1wB6oEvjqAD2bpuIG9d vp0ZEF1aZR/fL9b9tKHh4z5ww6x1E305z6Gf3xuak/ROuuV1krI1Y4AScF566CjT7if3 06YKQdlm2ud/fV0qjDQrahiNUM9lgFgzt4vricirITv+fVQTTqtrV3ZN/ZxraT2BgmSz reVqUgHXdhsZb82zOHWXwnBQy2G0YCuwMCMnBPkrJNedV503EgKG7peXOY57FommFyrs 4mqVQN5EBUSW7vOuqScbXwc3MyWKBfpAQ6lV8Kvxymnmdkqwtx9BDF2FB1q3KwAgZvwA 0vzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=th9hPiebWb3cHx+bHXFpTvFM7eAWq/GLsMxECcNWDL8=; b=lN8hSJIqeyGYmX8pyEJq67L0OTEVwPgjSAnGV69qrBFZARGFSyA9Z3nllvEBEJhSIx i5qfFL7Y9etB+Es3v/0OVeBYCsnW99rDaKPKJLvnnXSTIy/TiPS2tsGFopiBNZVMN/jo r3cSzYkPmfHFra01lsp7xo3k7JA/prxEPQYdN0GItMXt8DXEVmCB2gxbGk41UpfmcluY 8b7fYDQ+dm15hs60kvIB89nT/kbyQ6BVJ8euLLOAjHXfsckKKQqpJNberridgO5N1qxr q20xo+U9+/pV5AWJhG41KZ+BeWfrK3lSsp5rsC0Vgrv9bXxNpkZtUEj2BlDC/E8fM0oT 5S4w== X-Gm-Message-State: AMke39ljrvcbMq58NQaK+7igoASwtqOaTyNMwaBcF/GmJxN1ihhT8XZTu0dkezVX7NLnjw== X-Received: by 10.99.127.14 with SMTP id a14mr440853pgd.64.1488506511320; Thu, 02 Mar 2017 18:01:51 -0800 (PST) Received: from [192.168.178.21] ([118.149.111.252]) by smtp.gmail.com with ESMTPSA id l71sm19608015pga.7.2017.03.02.18.01.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Mar 2017 18:01:50 -0800 (PST) To: Michael Richardson , anima-bootstrap References: <20170221155002.GA8168@faui40p.informatik.uni-erlangen.de> <6b414f54-4164-5c9d-390e-30d21f786cca@gmail.com> <18032.1487866082@obiwan.sandelman.ca> <22816.1488466191@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 3 Mar 2017 15:01:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <22816.1488466191@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Toerless Eckert Subject: Re: [Anima-bootstrap] Brian: GRASP parameter for registrar discovery by proxy X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 02:01:53 -0000 On 03/03/2017 03:49, Michael Richardson wrote: > > Brian E Carpenter wrote: > > That seems a bit disjoint from "proxy needs to find registrar". And it > > definitely > > sounds like a two-way conversation, which would more naturally be > > modelled as > > a negotiation. Can you change that from a "what if?" to a more specific > > requirement that we can model? > > There are two aspects. > 1) In the Circuit Proxy case, it would be good if the Registrar was able to > point the Join Proxy at a different device. Or rather, decline to serve > it, "too busy". M_FLOOD/M_DISCOVER does not provide for this. True, you would have to build it into the initial BRSKI exchange instead. With GRASP negotiation, you would just respond with M_END/O_DECLINE. > 2) In the IPIP case, it might make some implementations easier if the > Registrar was aware of the Join Proxy before the traffic arrives, so > that the Registrar could configure the appropriate virtual interfaces. Yes, you could use a O_WAIT to make the proxy wait while doing the setup and then return any necessary parameters by M_NEGOTIATE, or simply signal success by M_END/O_ACCEPT. As you want. At the GRASP store, objectives are free of charge, and all the best names are still available. Brian > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Fri Mar 3 06:12:37 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A211295E0 for ; Fri, 3 Mar 2017 06:12:35 -0800 (PST) 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, RP_MATCHES_RCVD=-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 5iHkGPgSdqVm for ; Fri, 3 Mar 2017 06:12:34 -0800 (PST) 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 77F6B12944C for ; Fri, 3 Mar 2017 06:12:34 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C881F2009E; Fri, 3 Mar 2017 09:34:57 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2115D636BB; Fri, 3 Mar 2017 09:12:33 -0500 (EST) From: Michael Richardson To: Kent Watsen In-Reply-To: <2C1C2636-DE14-4570-99E8-72AEB0B9D57D@juniper.net> References: <18454.1488305685@obiwan.sandelman.ca> <8CBC8F3C-E796-4042-8AFE-AFDC985DAEF5@juniper.net> <25053.1488422367@obiwan.sandelman.ca> <2C1C2636-DE14-4570-99E8-72AEB0B9D57D@juniper.net> X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: anima-bootstrap Subject: Re: [Anima-bootstrap] voucher yang X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 14:12:36 -0000 --=-=-= Content-Type: text/plain Kent Watsen wrote: >> What I'm saying is that the pledge can't know how the owner was verified. >> The pledge actually has to process the same as for "verified" as for >> "logged". It doesn't change the pledge's behaviour. > But it does. Some pledges may be coded to only support 'verified' > vouchers. I agree, but the verification involved can't be confirmed by the pledge. > The DER itself works for me (the privacy concern seems minor). It's > also more code (relative to just using an openssl command line option), > but actually it's > one step less code than calculating the SHA256 fingerprint. A constrained device might not have a shell to run an openssl command line :-) >>> I'm okay with PCRE in theory, but I've read that a compiled stripped >>> library is large, do you know? >> >> I don't know. I don't want either :-) >> If I have to pick a regex library (vs shell-style globbing...) then >> I'd rather pick PCRE if we can find a stable reference. > As discussed in another thread, I'm beginning to think that we should > do away with having a single voucher for many devices, because we'd > want revocations to be as granular as possible. Good! >>> A 'binary' type would allow the nonce to be any length octet sequence, >>> which is converted to base64 encoded string for JSON. Is this what >>> you want? >> >> I want as much entropy in as small a space as possible. >> string seems to waste 2-bits per byte if it's base64 encoded in a binary >> format (CBOR). If JSON has to base64 encode things, I'm okay with that. >> >> I would assume that integers get network-byte order considerations which >> might lead to implementation bugs, where as binary[8] (if such a thing >> exists) would not. I think uint64 might be too small. > Okay, let's change the nonce to a binary type. Can we say the nonce is 8 to 32 bytes in size? If we have to pick a single number, I'd say 16 bytes. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli5edAACgkQgItw+93Q 3WVg4Qf9EgoHCPBzDAynOX35zXN93u0CfvsAv5nfuoVw4WBywPzmKN62EiXts7F+ +nhD7ZX8FDTyEjY4u8owPSCv0uAF2O58dV925y6PZl8jy8ReYHJSmKx9rLbQt4Hm OzqZ0MAiuvmpCBTby+hZLm5gxJgTaGwyJAzcn4kw3U3xFi/qii7RtEyyH2Iw5ZA0 gqnZfE0/ku07FJ0HyZJNFtLGVMV2TGza1XJNNW9sSdnW5J9boOlDx7prkgD2aEfK yoU0TdUZPLLdSuwIDK47yI43cL+uZ0kxKnFtFFsPqImhI9NhaFu/wSXLhoksYokA rS4a78GjIzAjWmWvEE4di8FuPqsWBQ== =E6HP -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 3 10:37:24 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005C6129977 for ; Fri, 3 Mar 2017 10:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7V7N5jppxcOk for ; Fri, 3 Mar 2017 10:37:22 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0099.outbound.protection.outlook.com [104.47.40.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57674129974 for ; Fri, 3 Mar 2017 10:37:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6pLzbRgjDGTz7PrfxCAJPxTqz7qX/H5bXIHuGErklUQ=; b=AIZuy8rEtzoZicMtxzq10TEOXdxltVAuaNFS5ey5gBtszIqNQGftZRwK/1dqPNWyhfKkwd4GNlYnlDQvzNvbp63qKRdMbrT+NZ2pdnZblgFCDegGu3GXtARcGcZrLY0QcxGMaxRt7WSNUUiYXTJJfWGEeN2utryTgdzytDR/rjw= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Fri, 3 Mar 2017 18:37:21 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0947.015; Fri, 3 Mar 2017 18:37:21 +0000 From: Kent Watsen To: Michael Richardson Thread-Topic: [Anima-bootstrap] voucher yang Thread-Index: AQHSke6O/yztceHfnUmp6ovkVBK+rqGAOr6AgACd0ICAAMHCAIABkjmA///2KQA= Date: Fri, 3 Mar 2017 18:37:21 +0000 Message-ID: <2567C73D-2305-4221-9117-0CD38D4EF5F5@juniper.net> References: <18454.1488305685@obiwan.sandelman.ca> <8CBC8F3C-E796-4042-8AFE-AFDC985DAEF5@juniper.net> <25053.1488422367@obiwan.sandelman.ca> <2C1C2636-DE14-4570-99E8-72AEB0B9D57D@juniper.net> <7371.1488550353@obiwan.sandelman.ca> In-Reply-To: <7371.1488550353@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: a3d1a591-c23b-4b75-3abc-08d46264541a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:ccZJ6TerSrIcpyyZdRaQT4oIQ9ac0HuZ/nAv848gpvtalOxboQ/0TfXz0SZ404j+r4oVBy3NBtandZsMVmbIhtNvhg5oDPfVUxN4cAqQuc1lohaV4Gzy27Ctdy+i20xGNY8PcVu6t1E60VGZt8Hdu8NV5fZauzSAu1uBxkghLtJO8uz86UNPeCU3RM2PUjCSVD5O8/NMVMGmZDAvaFewXnuOf45eK839+Pgj3VpQ1eVxVK1wtX5exyS7MyintaPLjsNmB9lOJ5X1s6eAIY8X7l3f4D+QERQrjQO0FU1cFJkmG0309y9Vxikuj3hiu/pDRkMKLrh4X3YUkhfay+18cA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123558025)(20161123562025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39840400002)(39860400002)(39450400003)(2900100001)(2950100002)(3846002)(6116002)(102836003)(36756003)(66066001)(33656002)(92566002)(122556002)(77096006)(6486002)(6436002)(6506006)(25786008)(6512007)(229853002)(99286003)(6306002)(8676002)(93886004)(106116001)(76176999)(54356999)(50986999)(82746002)(83716003)(83506001)(53936002)(305945005)(81166006)(4326008)(4001350100001)(38730400002)(3660700001)(6246003)(8936002)(189998001)(86362001)(7736002)(3280700002)(110136004)(2906002)(5660300001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 18:37:21.2401 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Cc: anima-bootstrap Subject: Re: [Anima-bootstrap] voucher yang X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 18:37:24 -0000 DQoNCg0KPj4+IFdoYXQgSSdtIHNheWluZyBpcyB0aGF0IHRoZSBwbGVkZ2UgY2FuJ3Qga25vdyBo b3cgdGhlIG93bmVyIHdhcyB2ZXJpZmllZC4NCj4+PiBUaGUgcGxlZGdlIGFjdHVhbGx5IGhhcyB0 byBwcm9jZXNzIHRoZSBzYW1lIGFzIGZvciAidmVyaWZpZWQiIGFzIGZvcg0KPj4+ICJsb2dnZWQi LiAgSXQgZG9lc24ndCBjaGFuZ2UgdGhlIHBsZWRnZSdzIGJlaGF2aW91ci4NCj4+DQo+PiBCdXQg aXQgZG9lcy4gIFNvbWUgcGxlZGdlcyBtYXkgYmUgY29kZWQgdG8gb25seSBzdXBwb3J0ICd2ZXJp ZmllZCcNCj4+IHZvdWNoZXJzLg0KPg0KPiBJIGFncmVlLCBidXQgdGhlIHZlcmlmaWNhdGlvbiBp bnZvbHZlZCBjYW4ndCBiZSBjb25maXJtZWQgYnkgdGhlIHBsZWRnZS4NCg0KVGhlIHBsZWRnZSBj b25maXJtcyB0aGUgdm91Y2hlciBhcyBhIHdob2xlLCB3aGljaCBpbmNsdWRlcyB0aGUgYXNzZXJ0 aW9uDQpzdGF0ZW1lbnQuICBXaGF0IGVsc2UgbWlnaHQgeW91IG1lYW4/DQoNCg0KDQo+PiBUaGUg REVSIGl0c2VsZiB3b3JrcyBmb3IgbWUgKHRoZSBwcml2YWN5IGNvbmNlcm4gc2VlbXMgbWlub3Ip LiAgSXQncw0KPj4gYWxzbyBtb3JlIGNvZGUgKHJlbGF0aXZlIHRvIGp1c3QgdXNpbmcgYW4gb3Bl bnNzbCBjb21tYW5kIGxpbmUgb3B0aW9uKSwNCj4+IGJ1dCBhY3R1YWxseSBpdCdzIG9uZSBzdGVw IGxlc3MgY29kZSB0aGFuIGNhbGN1bGF0aW5nIHRoZSBTSEEyNTYNCj4+IGZpbmdlcnByaW50Lg0K Pg0KPiBBIGNvbnN0cmFpbmVkIGRldmljZSBtaWdodCBub3QgaGF2ZSBhIHNoZWxsIHRvIHJ1biBh biBvcGVuc3NsIGNvbW1hbmQNCj4gbGluZSA6LSkNCg0KSSdtIG9rYXkgd2l0aCBtYWtpbmcgaXQg YSBERVIuDQoNCg0KDQo+PiBPa2F5LCBsZXQncyBjaGFuZ2UgdGhlIG5vbmNlIHRvIGEgYmluYXJ5 IHR5cGUuDQo+DQo+IENhbiB3ZSBzYXkgdGhlIG5vbmNlIGlzIDggdG8gMzIgYnl0ZXMgaW4gc2l6 ZT8NCj4gSWYgd2UgaGF2ZSB0byBwaWNrIGEgc2luZ2xlIG51bWJlciwgSSdkIHNheSAxNiBieXRl cy4NCg0KQWNjb3JkaW5nIHRvIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3OTUwI3Nl Y3Rpb24tOS44LjE6DQoNCiAgIEEgYmluYXJ5IHR5cGUgY2FuIGJlIHJlc3RyaWN0ZWQgd2l0aCB0 aGUgImxlbmd0aCIgKFNlY3Rpb24gOS40LjQpDQogICBzdGF0ZW1lbnQuICBUaGUgbGVuZ3RoIG9m IGEgYmluYXJ5IHZhbHVlIGlzIHRoZSBudW1iZXIgb2Ygb2N0ZXRzIGl0DQogICBjb250YWlucy4N Cg0KQW5kIFNlY3Rpb24gOS40LjQgc2F5czoNCg0KICAgQSBsZW5ndGggcmFuZ2UgY29uc2lzdHMg b2YgYW4gZXhwbGljaXQgdmFsdWUsIG9yIGEgbG93ZXIgYm91bmQsIHR3bw0KICAgY29uc2VjdXRp dmUgZG90cyAiLi4iLCBhbmQgYW4gdXBwZXIgYm91bmQuDQoNCldoaWNoIG1lYW5zIHdlIGNhbiBo YXZlOg0KDQogIGxlYWYgbm9uY2Ugew0KICAgIHR5cGUgYmluYXJ5IHsNCiAgICAgIGxlbmd0aCA4 Li4zMjsNCiAgICB9DQogIH0NCg0KDQpDaGVlcnMsDQpLZW50DQoNCg0KDQo= From nobody Fri Mar 3 12:43:15 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2D71294ED for ; Fri, 3 Mar 2017 12:43:14 -0800 (PST) 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, 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 W3FcCA6M2z1l for ; Fri, 3 Mar 2017 12:43:12 -0800 (PST) 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 B2DAE1295C3 for ; Fri, 3 Mar 2017 12:43:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2485A30049F for ; Fri, 3 Mar 2017 15:43:06 -0500 (EST) 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 0qTpkcLJF8vy for ; Fri, 3 Mar 2017 15:43:04 -0500 (EST) Received: from new-host-5.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 85A8230024A; Fri, 3 Mar 2017 15:43:04 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <14573.1488419571@obiwan.sandelman.ca> Date: Fri, 3 Mar 2017 15:43:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8C184CD7-69EB-424B-9D95-1C64A8FD706F@vigilsec.com> References: <18454.1488305685@obiwan.sandelman.ca> <14573.1488419571@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM , anima-bootstrap Subject: Re: [Anima-bootstrap] [Spasm] SHA1 usage in Anima-bootstrap voucher yang X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 20:43:14 -0000 > On Mar 1, 2017, at 8:52 PM, Michael Richardson = wrote: >=20 >=20 > In the ANIMA ownership voucher YANG model, the absolute latest which = you can > currently see at: > = https://github.com/anima-wg/voucher/blob/master/draft-ietf-anima-voucher-0= 1.txt >=20 > we write at line 574: >=20 > leaf subject-hash { > type binary; > description "The certificate's entire subject field MUST > match this value. This value is calculated as the SHA-1 > hash over the TBSCertificate's subject structure, as > specified by RFC 5280 Section 4.1.2.6, encoded using > the ASN.1 distinguished encoding rules (DER), as > specified in ITU-T X.690. >=20 > Note: by using the SHA-1 algorithm, the result can be > easily compared to OpenSSL's 'subject_hash' > output."; > } >=20 > The voucher is a signed artifact (PKCS7? JWT? CWT? TBD) which = indicates to a > particular device who the devices owner is. ("Are you my mummy?" for = Dr.Who Fans) >=20 > For reasons of key hygiene and longevity, in many cases we do not want = to > point at the public key of the registrar directly, but rather indicate = that > it's DN=3DFoo, as signed by CA=3DBar. It seems like there ought be a = better way > to do this kind of thing than what we specify above, which is = annoyingly SHA1 > linked. >=20 > Can SPASM offer any advice? >=20 > We could list the actual DER itself. Encoded, it might actually not be = bigger > than a SHA256, for instance. That might have privacy implications = though, > which we'd need to think through. >=20 > Some time ago, I proposed replicating the SIDR artifact (RFC3779), and = copy > and pasted it to make: > = https://www.ietf.org/archive/id/draft-richardson-anima-idevid-cert-00.txt >=20 > but, we didn't really want to go exactly that way. Michael: I=E2=80=99m sure you know that there are three important properties for = hash functions. The are: (1) collision resistance: it is computationally infeasible to find two different inputs that hash to the same output; that is, it is really hard to find a and b such that H(a) =3D H(b). (2) preimage resistance: it is computationally infeasible to find any input that hashes to a given output; that is, given y, it is really hard to find x such that H(x) =3D y. (3) second-preimage resistance: it is computationally infeasible to find a second input which has the same output as a specified input; that is, given x, it is really hard to find y such that H(x) =3D H(y). Google has announced a collision for SHA-1. They found to PDF files that produce the same SHA-1 hash value. In the system you describe, it seems that an attacker would need to find a preimage. For SHA-1, we do not know of a way to do that yet, but the 160-bit have value produced by SHA-1 is probably not big enough to be considered safe in today's computing environment. It seems very odd to be developing a new standards that is using a hash function that was deprecated at the end of 2010 by NIST. My personal recommendation ould be to move from SHA-1 to SHA-256. Russ From nobody Fri Mar 3 13:06:29 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A18129505 for ; Fri, 3 Mar 2017 13:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=sn3rd.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 TccebYNqt63V for ; Fri, 3 Mar 2017 13:06:26 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272311295DC for ; Fri, 3 Mar 2017 13:06:26 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id 1so77686442qkl.3 for ; Fri, 03 Mar 2017 13:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9wMP5ewi2ekReV3h+o0QiWmht9Co9egHBX1z4v01OMw=; b=GK2UTPzEdNlKFbcKPInC55fA/9oouT7SwVxAYYOzzPSPcgMPVbTpyHJVx6Cp6JWA9J CrYSK/nFm5aI5vkJnecdtow5HM0fj6Kbz28/OCt06vpCaPBsNc7oMm86Odp0cv+5024n drGovciEOWEViAc1pEEX83n2aSrZeT/a8BGxs= 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=9wMP5ewi2ekReV3h+o0QiWmht9Co9egHBX1z4v01OMw=; b=L3GoO4ucVgXtcR6V9UznXzpeZje6hTBtv93lavpBL9w+l48ehFqzHw8LmlM/wMxLzC a+o0cfCPjie/7dX6sGNuGPDwKnY3bfQiaOGM9kPu9mejD0cYTE9Od3Eh94dhdqwZ7Ci5 C3Ua5n84nVtxKEcrBf4aT/A4vBQKX2nhSsLnuG+OKHVkXbMuWRe+jpsw96BM/X9Twjhg CQ/DBtEGiL2XWumhcew7f7TnjlCck0/iax+OBfyyOpbzbyE9pTLwJDGJ1GC+GxqqF7QD WqpOJOIggI5tGnoY15D5nd1/z9CqWoo8Ftg5M2VFUgE2YgojRZioz4BmGyR7EIY1ZBXa 8sfg== X-Gm-Message-State: AMke39mCYgdVTI00lLDaJAKEjl/ZWuCuO/qtVpXsrKliqEUfuleTmo+l/J9sXXXf0L8EwA== X-Received: by 10.237.59.19 with SMTP id p19mr4840173qte.28.1488575184612; Fri, 03 Mar 2017 13:06:24 -0800 (PST) Received: from [172.16.0.92] ([96.231.228.203]) by smtp.gmail.com with ESMTPSA id r189sm8349723qkf.58.2017.03.03.13.06.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Mar 2017 13:06:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <8C184CD7-69EB-424B-9D95-1C64A8FD706F@vigilsec.com> Date: Fri, 3 Mar 2017 16:06:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18454.1488305685@obiwan.sandelman.ca> <14573.1488419571@obiwan.sandelman.ca> <8C184CD7-69EB-424B-9D95-1C64A8FD706F@vigilsec.com> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SPASM , anima-bootstrap Subject: Re: [Anima-bootstrap] [Spasm] SHA1 usage in Anima-bootstrap voucher yang X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 21:06:28 -0000 > On Mar 3, 2017, at 15:43, Russ Housley wrote: >=20 >>=20 >> On Mar 1, 2017, at 8:52 PM, Michael Richardson = wrote: >>=20 >>=20 >> In the ANIMA ownership voucher YANG model, the absolute latest which = you can >> currently see at: >> = https://github.com/anima-wg/voucher/blob/master/draft-ietf-anima-voucher-0= 1.txt >>=20 >> we write at line 574: >>=20 >> leaf subject-hash { >> type binary; >> description "The certificate's entire subject field MUST >> match this value. This value is calculated as the SHA-1 >> hash over the TBSCertificate's subject structure, as >> specified by RFC 5280 Section 4.1.2.6, encoded using >> the ASN.1 distinguished encoding rules (DER), as >> specified in ITU-T X.690. >>=20 >> Note: by using the SHA-1 algorithm, the result can be >> easily compared to OpenSSL's 'subject_hash' >> output."; >> } >>=20 >> The voucher is a signed artifact (PKCS7? JWT? CWT? TBD) which = indicates to a >> particular device who the devices owner is. ("Are you my mummy?" for = Dr.Who Fans) >>=20 >> For reasons of key hygiene and longevity, in many cases we do not = want to >> point at the public key of the registrar directly, but rather = indicate that >> it's DN=3DFoo, as signed by CA=3DBar. It seems like there ought be = a better way >> to do this kind of thing than what we specify above, which is = annoyingly SHA1 >> linked. >>=20 >> Can SPASM offer any advice? >>=20 >> We could list the actual DER itself. Encoded, it might actually not = be bigger >> than a SHA256, for instance. That might have privacy implications = though, >> which we'd need to think through. >>=20 >> Some time ago, I proposed replicating the SIDR artifact (RFC3779), = and copy >> and pasted it to make: >> = https://www.ietf.org/archive/id/draft-richardson-anima-idevid-cert-00.txt >>=20 >> but, we didn't really want to go exactly that way. >=20 > Michael: >=20 > I=E2=80=99m sure you know that there are three important properties = for hash > functions. The are: >=20 > (1) collision resistance: it is computationally infeasible to find two > different inputs that hash to the same output; that is, it is = really > hard to find a and b such that H(a) =3D H(b). >=20 > (2) preimage resistance: it is computationally infeasible to find any > input that hashes to a given output; that is, given y, it is really > hard to find x such that H(x) =3D y. >=20 > (3) second-preimage resistance: it is computationally infeasible to = find > a second input which has the same output as a specified input; that > is, given x, it is really hard to find y such that H(x) =3D H(y). >=20 > Google has announced a collision for SHA-1. They found to PDF files > that produce the same SHA-1 hash value. >=20 > In the system you describe, it seems that an attacker would need to > find a preimage. For SHA-1, we do not know of a way to do that yet, > but the 160-bit have value produced by SHA-1 is probably not big = enough > to be considered safe in today's computing environment. >=20 > It seems very odd to be developing a new standards that is using a = hash > function that was deprecated at the end of 2010 by NIST. >=20 > My personal recommendation ould be to move from SHA-1 to SHA-256. >=20 > Russ >=20 And, there=E2=80=99s an RFC for that (TM) :) https://datatracker.ietf.org/doc/rfc7093/ spt= From nobody Fri Mar 3 14:52:05 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E206B12965B; Fri, 3 Mar 2017 14:51:59 -0800 (PST) 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, RP_MATCHES_RCVD=-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 j7tWIdKX2Ne7; Fri, 3 Mar 2017 14:51:58 -0800 (PST) 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 6D0D8129657; Fri, 3 Mar 2017 14:51:58 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 53E732009E; Fri, 3 Mar 2017 18:14:23 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 64ED0636BB; Fri, 3 Mar 2017 17:51:57 -0500 (EST) From: Michael Richardson To: Russ Housley In-Reply-To: <8C184CD7-69EB-424B-9D95-1C64A8FD706F@vigilsec.com> References: <18454.1488305685@obiwan.sandelman.ca> <14573.1488419571@obiwan.sandelman.ca> <8C184CD7-69EB-424B-9D95-1C64A8FD706F@vigilsec.com> X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: SPASM , anima-bootstrap Subject: Re: [Anima-bootstrap] [Spasm] SHA1 usage in Anima-bootstrap voucher yang X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:52:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Russ Housley wrote: > I=E2=80=99m sure you know that there are three important properties f= or hash > functions. The are: Yes. > In the system you describe, it seems that an attacker would need to > find a preimage. For SHA-1, we do not know of a way to do that yet, > but the 160-bit have value produced by SHA-1 is probably not big enou= gh > to be considered safe in today's computing environment. > It seems very odd to be developing a new standards that is using a ha= sh > function that was deprecated at the end of 2010 by NIST. > My personal recommendation ould be to move from SHA-1 to SHA-256. Yes, I agree completely. What I'm asking for, is if there is a good, well-established container that we can reference, that essentially gives us the agility to move from SHA1 to SHA256, and to SHA3 if we have to. Alternatively, for the use case involved, which is to refer to a certificate by reference-to-CA + reference-to-DN, if there is some other construct that would better do what we want, and *also* provide us with the agility we wou= ld like. (Some ownership vouchers may sit in filing cabinets for a few decades in a warehouse somewhere) =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli584wACgkQgItw+93Q 3WVAgQf+OVhFGSafm1IM0IeND2snRTHQ98/khgntKpXO4V6VJ9p0g62R6vlfWJ3O P4pxi8YZz/uEw4DGZK2FfEvBOz6vON1BycEgPPpm/4Mz73qioAlxx8vM/7qO7JUH LuX3ji2qfvArmzw5sNFpBcFVYw1mBhr2EqpMU6Yp5uhiyf9I8ApkJBL1Mlw9SkjD oOM+YUe2UXPEBC1eDq2eM38h1gkgn0/9GV8F9DgOQe6JKluBsEVzM+X2Z1PT8nxJ +DrlE+jYFE0Qra/c6Z3MY2skGmT90yEOjn3iC04h2cuBIlyaWrap+BZQWtMigaE/ 4gyfLsl9oVLewY+TDQQoy9KYBQq6nA== =otnx -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 3 15:44:22 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAD6129494 for ; Fri, 3 Mar 2017 15:44:21 -0800 (PST) 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, RP_MATCHES_RCVD=-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 PjTsN_mVo7lQ for ; Fri, 3 Mar 2017 15:44:19 -0800 (PST) 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 E3C0A12948A for ; Fri, 3 Mar 2017 15:44:18 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B9D83203BD for ; Fri, 3 Mar 2017 19:06:42 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AA2AE636BB for ; Fri, 3 Mar 2017 18:44:16 -0500 (EST) From: Michael Richardson To: anima-bootstrap In-Reply-To: <2567C73D-2305-4221-9117-0CD38D4EF5F5@juniper.net> References: <18454.1488305685@obiwan.sandelman.ca> <8CBC8F3C-E796-4042-8AFE-AFDC985DAEF5@juniper.net> <25053.1488422367@obiwan.sandelman.ca> <2C1C2636-DE14-4570-99E8-72AEB0B9D57D@juniper.net> <7371.1488550353@obiwan.sandelman.ca> <2567C73D-2305-4221-9117-0CD38D4EF5F5@juniper.net> X-Mailer: MH-E 8.6; nmh 1.6+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-bootstrap] voucher yang X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:44:21 -0000 --=-=-= Content-Type: text/plain Kent Watsen wrote: >>>> What I'm saying is that the pledge can't know how the owner was verified. >>>> The pledge actually has to process the same as for "verified" as for >>>> "logged". It doesn't change the pledge's behaviour. >>> >>> But it does. Some pledges may be coded to only support 'verified' >>> vouchers. >> >> I agree, but the verification involved can't be confirmed by the pledge. > The pledge confirms the voucher as a whole, which includes the assertion > statement. What else might you mean? Yes, but it can't know if the event having been logged as the MASA said it would, was examined by the Registrar. >>> The DER itself works for me (the privacy concern seems minor). It's >>> also more code (relative to just using an openssl command line option), >>> but actually it's one step less code than calculating the SHA256 >>> fingerprint. >> >> A constrained device might not have a shell to run an openssl command >> line :-) > I'm okay with making it a DER. I'm reading: https://tools.ietf.org/html/rfc7093 at Sean Turner and SPASM WG suggestion. I think that this is the thing we actually need. > According to https://tools.ietf.org/html/rfc7950#section-9.8.1: > A binary type can be restricted with the "length" (Section 9.4.4) > statement. The length of a binary value is the number of octets it > contains. > And Section 9.4.4 says: > A length range consists of an explicit value, or a lower bound, two > consecutive dots "..", and an upper bound. > Which means we can have: > leaf nonce { > type binary { > length 8..32; > } > } Works for me. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli5/84ACgkQgItw+93Q 3WUhuAf/SLRhFC94XfJOs+t5/Fq+huTSCiuHMzTW47AbP44nqGpFtHSL5/+VmZrI it2qrKCabRx1nUVDOEx3rPX9s6KTpWQxQRbvxfRCNBPtUvLN/aVZOSA+18F82qnA LTQzZzi3jjCABEprlNk+/WUWcVvS8X+mtB+jFNaOdutC84PMGUN+ABHUQb5PsARD S2OAsadeaNmDRy16lxRItnEFfFACoc+4f/1p1QryYJrakN3WBGsarjVntwTuN0aM DfkWlUhzF0a7U86KmanSiBgxtUg5xQklJp+8ohQjnaK5w6/w0QC7SQ3D+Xtg21QP mXGHfgo06vIzvPwNgAPGphjHJdb/5g== =IBOy -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 6 07:54:33 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88079129869 for ; Mon, 6 Mar 2017 07:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Sw_q7MZzOYcD for ; Mon, 6 Mar 2017 07:54:30 -0800 (PST) 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 7AEDF129867 for ; Mon, 6 Mar 2017 07:54:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BAF3D3002BC for ; Mon, 6 Mar 2017 10:54:29 -0500 (EST) 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 FdFC66sKqg-j for ; Mon, 6 Mar 2017 10:54:28 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 68343300266; Mon, 6 Mar 2017 10:54:28 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <24239.1488581517@obiwan.sandelman.ca> Date: Mon, 6 Mar 2017 10:54:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <19405A7A-EC2C-4DE5-A18B-300EA10D0B03@vigilsec.com> References: <18454.1488305685@obiwan.sandelman.ca> <14573.1488419571@obiwan.sandelman.ca> <8C184CD7-69EB-424B-9D95-1C64A8FD706F@vigilsec.com> <24239.1488581517@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM , anima-bootstrap Subject: Re: [Anima-bootstrap] [Spasm] SHA1 usage in Anima-bootstrap voucher yang X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 15:54:31 -0000 Michael: > Russ Housley wrote: >> I=E2=80=99m sure you know that there are three important properties = for hash >> functions. The are: >=20 > Yes. >=20 >> In the system you describe, it seems that an attacker would need to >> find a preimage. For SHA-1, we do not know of a way to do that yet, >> but the 160-bit have value produced by SHA-1 is probably not big = enough >> to be considered safe in today's computing environment. >=20 >> It seems very odd to be developing a new standards that is using a = hash >> function that was deprecated at the end of 2010 by NIST. >=20 >> My personal recommendation ould be to move from SHA-1 to SHA-256. >=20 > Yes, I agree completely. >=20 > What I'm asking for, is if there is a good, well-established container = that > we can reference, that essentially gives us the agility to move from = SHA1 to > SHA256, and to SHA3 if we have to. >=20 > Alternatively, for the use case involved, which is to refer to a = certificate > by reference-to-CA + reference-to-DN, if there is some other construct = that > would better do what we want, and *also* provide us with the agility = we would > like. >=20 > (Some ownership vouchers may sit in filing cabinets for a few decades = in > a warehouse somewhere) As Sean said, RFC 7093 gives ways that the CA can compute the Subject = Key Identifier, and the CA can migrate from SHA-256 if needed in the = future. Russ From nobody Thu Mar 9 18:25:09 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845A4126579 for ; Thu, 9 Mar 2017 18:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 pILXPxDFa64G for ; Thu, 9 Mar 2017 18:24:57 -0800 (PST) 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 6F0A51294B2 for ; Thu, 9 Mar 2017 18:24:51 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AFA622054E for ; Thu, 9 Mar 2017 21:10:00 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8FA736381A for ; Thu, 9 Mar 2017 20:47:13 -0500 (EST) From: Michael Richardson To: anima-bootstrap@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+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: [Anima-bootstrap] minutes from meetings since IETF97 X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 02:24:59 -0000 --=-=-= Content-Type: text/plain These are the previous meeting minutes: https://www.ietf.org/mail-archive/web/anima-bootstrap/current/msg00328.html If I've posted a summary since, I can't find it in the archives. 0) we continue to meet at 15:00UTC each Tuesday. Please see meeting details at: https://trac.tools.ietf.org/wg/anima/trac/wiki/Bootstrap the members on the web site say: Max Pritikin (editor), Michael Richardson (editor) Jason Coleman, Sandeep Kumar, Michael Behringer, Alper Yegin, Bing Liu, Brian Carpenter Kent Watson Sheng Jiang (wg chair), Toerless Eckert (wg chair) Typically we have the following people participate in the weekly calls. Michael Richardson Max Pritikin Kent Watson We are frequently joined by Toerless Eckert. We would welcome additional people/viewpoints. But there are a number in the above list which we haven't seen recently. Please chime in and tell us what you are up to, and what your take on the current situation is. The webex link is valid until IETF98. We expect to meet on March 14, but note that north american clocks will have changed, so it will be 11am EDT. We keep running minutes using the etherpad. Yes there is a typo in the link. 1) we posted -04 of anima-bootstrap prior to IETF97, and have been working on the -05, which will get posted this weekend. 2) since October, we posted three versions of draft-ietf-anima-voucher (some under the previous names draft-kwatsen-netconf-voucher, and draft-kwatsen-anima-voucher). 3) all of the drafts are revision controlled in git, and hosted on github.com, at https://github.com/anima-wg/ The bootstrap git tree contains a subdirectory minutes, which is the raw dump from the etherpad. These minutes are organized by topic with ideas taken from the raw minutes, rather than chronologically. TERMINOLOGY =========== We agreed to the terminology proposed from the 6tisch-security design team, and have made the changes in -05. Another email went to this list on that topic. HACKATHON ========= We discussed very early on what we would like to have to interoperate with at the hackathon. We concluded that exchange of vouchers and certificates would make the most sense, even if we were using USB keys or web pastebins for transport rather than HTTPS. As of March 7, after many discussions that lead many places, we have concluded that for IETF98, we will exchange JSON encoded vouchers in PKCS7 containers such are easily produced by cli tools. VOUCHER ======= The voucher format is described at: https://tools.ietf.org/html/draft-ietf-anima-voucher-00#section-4.2 and looks like: { "ietf-voucher:voucher": { "assertion": "logged", "trusted-ca-certificate": "base64-encoded X.509 DER", "owner-id": "Registrar3245", "unique-id": "JADA123456789", "created-on": "2016-10-07T19:31:42Z", "nonce": "987987623489567" } } The following table is now in the dtbootstrap-anima-keyinfra-05, section 2.2: |Assertion |Registrar ID |Pledge ID | Validity | |Log-|Veri- |Trust |CN-ID or|serial | RTC | Nonce | | ged| fied |Anchor |DNS-ID |number | | | --------------------------------------------------------------------| Audit | X | | X | | X | | X | -------------|----|-------|-------|--------|----------|-----|-------| Nonceless | X | | X | | X | | | Audit | | | | | | | | -------------|----|-------|-------|--------|----------|-----|-------| Owner Audit | X | X | X | | X | | X | Owner Role | X | ? | X | X | X | | X | -------------|----|-------|-------|--------|----------|-----|-------| Owner ID | | X | ? | X | X | X | | -------------|----|-------|----------------|----------|-------------| BearerVoucher| X | | wildcard | X | ? | -------------|----|-------|----------------|----------|-------------| MasterVoucher| | | wildcard | wildcard | X | | -------------|------------|----------------|----------|-----|-------| we had a lot of discussion about how each kind of voucher can be used, and what they mean. We have come dangerously close to writing a Use Case / Requirements section/document. REVOCATION of VOUCHERS ====================== Nonceless Vouchers can be issued in advance and stored for many years and used when a device is finally deployed. Reference to the owner by CA+DN (rfc7093 provides a way) permits the registrar's key to be cycled many times. The question has remained: do we need a way to revoke vouchers? If the answer is yes, we considered that maybe the vouchers should be cast in PKIX format as if they were certificates, such that we could use the same kind of CRL or OCSP mechanisms. We are not yet convinced of this; but we do think that we could include a serial number in each voucher such that we could, even if the voucher was not in PKIX format, use OCSP with that serial number. This discussion remains open. What definitely came out of this is that we need more text to explain how each voucher-type should be used to address particular deployment scenarios. From that, we also need to better define the deployment scenarios, probably giving them easily discussed names. BEARER VOUCHER ============== After much discussion, we decided that the operational security problems with providing for a bearer token lead us to conclude that we do not want to standardize one. We think that there are other ways to do almost the same thing. JWT / CWT ========= We discussed having the voucher be in JWT format, as described in RFC7519, RFC7517, etc. This would also permit switch to CWT format as described in draft-ietf-ace-cbor-web-token. This discussion is not over, but for the purposes of IETF98, this is out of scope. A JWT/CWT might look like: { "iss":"Registrar3245", "iat": 1478854302, "nbf": 1478824302, "exp": 9999999999, "cti": "987987623489567" "logged": "true", "aud": "base64-encoded X.509 DER", "sub": "JADA123456789", } CONCURRENT REGISTRATION ======================= We had a discussion over a few meetings about the how much we needed to say about pledges that see multiple Join Proxies, and which have the CPU/RAM to attempt to enroll over all proxies at the same time. One of the reasons to do this is because it eliminates concern where an attacker (operating a rogue proxy, or a fake JRC) attempts to sabotage the enrollment process by very slow TCP communications. The goal would be to annoy the operator who them chooses a less secure alternate mechanism, or the vendor provides some kind of backdoor. Setting "appropriate" timeouts could (and should) be done, but this may result in failures when the network is simply very congested. Doing the work concurrently avoids having any one attempt hold up the others; but as soon as one attempt succeeds, other attempts would be abandonned. We did not figure out how much text we need add about this, but we feel that there are no protocol concerns with concurrent join attempts. mDNS ==== AI: The M_FLOOD vs mDNS initial discovery discussion is not over, and we should invite the DNSSD/mDNS folks to come and make the case. This remains an Action Item, and we need to reach out to the proponents of mDNS to more clearly articulate the reasoning behind their preferences, and also to clearly explain how they would use mDNS. A major difference seems to be that mDNS would not support a passive (listen-only) mode for the pledge. It would have to do a multicast discovery for the service, announcing itself to the entire network. CoAP ==== We have removed the CoAP mechanism until we prepared to properly define it. IPIP ==== We have added an appendix to explain the IPIP proxy mechanism. It is no longer a MUST. Continued GRASP Proxy/Registrar discussion ========================================== A thread was posted to the list already about how we should properly do discovery of the registrar by the Join Proxy. CLOSING LIST? ============= Our WG chair has suggested that it is time to close the anima-bootstrap list. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljCBZ8ACgkQgItw+93Q 3WX/gAgAv762cmf1vr//a9wJ9h5myCP2xTR81dnG+qQ16RO9vNYGA6+407aETwl5 0E3qyhFyakTBJhSD26tjY+Ufxvl0p5kc41PIf/gp9Yfb6rBjfxp5IMdfgZcBfzRt 05Ji4mSFDsCaRcR0EvQgs0N7avhdrpeWTTxLCzJZXRA6KY5Oa2QW12sMkrXFq26E pfwGY0GwvntNSX8zFP/IDjNW4Ew6+TdPkmZnShtt3vLfV6Cyq0yfm+svvi9vKVPH fu9Rz/sBFX/0dJZXD1gQkoM+HED75Q+IupLTe+T8TkzWUwv1lQGdWRIJ5foJJ3XI nCbucLht60PjKCVTLwOuVxzil2klFg== =q8Kj -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 9 18:54:58 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891B312947E for ; Thu, 9 Mar 2017 18:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 C5FNwoSYpU6P for ; Thu, 9 Mar 2017 18:54:53 -0800 (PST) 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 0E9E81294EB for ; Thu, 9 Mar 2017 18:54:53 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 605C0E1FC for ; Thu, 9 Mar 2017 19:52:10 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6C10B6381A for ; Thu, 9 Mar 2017 19:29:23 -0500 (EST) From: Michael Richardson To: anima-bootstrap X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+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: [Anima-bootstrap] March 14 meeting X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 02:54:56 -0000 --=-=-= Content-Type: text/plain The clocks will change this weekend for some of us. The meeting was anchored to UTC, so it moves from 10am to 11am for us. Please speak up if this is an issue. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljB82EACgkQgItw+93Q 3WUCxQf9HPpaxqTYVYxcmXwzmd2/GJOhPssBTdUdXNIDl8HZEmQDBm9zVrBZQrIk FBxoQnzWPgxmwCYiz6KIQxIknv9v8YSle35OItw9uk+butkRdnwpn2M8y/80zNqu qoujahT97q2ucf8DC0G0MDqlfsW7+vpkZA/vk7/6aT/RjW7H//znXZmqQ/8nF0n+ 0eg7PvOD+NhrKq92VJsfX6VsPW4k82l++GH+tgVTBixqbSHTFjyi6pA/eEs/onpQ TAfLKjv25tjdVqovuUF0ZZBU5wKWwoYaMJ8HE48ChsflkZUbs+MGjdkkqw1d8ysB EOoEgBvFl0cTyAbk6yIxHhmXmgsCAg== =Plan -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 10 00:24:27 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E115B1293D9 for ; Fri, 10 Mar 2017 00:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 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, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bx9jTHPvkwGf for ; Fri, 10 Mar 2017 00:24:24 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE592126B6D for ; Fri, 10 Mar 2017 00:24:23 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id v186so4929650wmd.0 for ; Fri, 10 Mar 2017 00:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=4/3GiF74wpIdDz7LLNLbyQ01aLIyrjtHvV7kAGzsZJg=; b=L6h1Y6UM79qAtuqvwbToXIrwkklSdYbZ/L9420stoT87YYk/QhJB2seNnDokuF8KHH 8hQSXaeZrmMQ35SevuKymiZWqa366UmnuxRx+aRvoAVUp6GMKAEzHoWSZZiM9yfkKLVI MMXnGtSG4Wt6CGlMZYrz1FEw7b75v0zlnoWgmUxe3kTq/ws2MvJkTyTU+fGloFHqPQk9 UtMXirU76dmZ6xXraVuTJjHHqW7xaS27YwLPQesJFDrRM2LkzEQyDqxQVdCTDavKx+os cJt3zQgyzhNgQbAGWjJxyw+p8dFCZnqkjqOAgJVfxol9bF6/mTGfUHMYy0/6oM1e8M2p D/uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4/3GiF74wpIdDz7LLNLbyQ01aLIyrjtHvV7kAGzsZJg=; b=pBmFBgxJTzTJsTjK+4HS6k46vrtiu18uEXp5lSSj5K9EyUXjahB1SmI3WwptPifyhK ozgNnLjzSyNrzmISlQxs7Eo4pukKVOAsqvCEh7Hvd71YYDhzOOcLDp+akSnQAk9BqWjW ThD50PlRKZ4hQyUpeFtBWQxRkzsbsFVQHHGISJf1XMWRGY1Y3mO0uflD+Pzc7jvDyzVP OWYZ0ZuS/sDCKlDp/xwqquGZMPaSObtmXfb3ooI/d9EmHKTqR7KN8U9umbd89QzKmjG2 QOsmXFDP2MIsskNi9us//jRRtFclYwf3T35b/P7eMeZCNVH0crbGo7SDvPyZeYle9mpV QvHA== X-Gm-Message-State: AFeK/H28B0dG2zn+BNLY/BAli8loCKQxJ2uPhQn6kftlX6+GmU8y6Y4pNYaWsblEzB4Cwg== X-Received: by 10.28.203.197 with SMTP id b188mr1341324wmg.110.1489134262046; Fri, 10 Mar 2017 00:24:22 -0800 (PST) Received: from [192.168.1.58] (ANice-652-1-365-58.w83-201.abo.wanadoo.fr. [83.201.200.58]) by smtp.gmail.com with ESMTPSA id h3sm11726757wrb.6.2017.03.10.00.24.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Mar 2017 00:24:20 -0800 (PST) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: anima-bootstrap@ietf.org References: <30346.1489110433@obiwan.sandelman.ca> Message-ID: Date: Fri, 10 Mar 2017 09:24:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <30346.1489110433@obiwan.sandelman.ca> Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima-bootstrap] minutes from meetings since IETF97 X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 08:24:26 -0000
Hi Michael,

Sorry I haven't been attending lately, you may be aware of my employment change, which has changed priorities for a while.

However, I do plan to participate actively again and help bring all those docs to RFC. I'll be participating in the upcoming IETF, but only remotely, since I don't have a sponsor at the moment.

I'll be there on Tuesday.

A short request: I'm doing version -03 of the reference draft right now. If you see particular things from the bootstrap side that ought to be changed added in the reference draft, please let me know!

Michael

On 10/03/2017 02:47, Michael Richardson wrote:
These are the previous meeting minutes:
      https://www.ietf.org/mail-archive/web/anima-bootstrap/current/msg00328.html

If I've posted a summary since, I can't find it in the archives.

0) we continue to meet at 15:00UTC each Tuesday.
   Please see meeting details at:
   https://trac.tools.ietf.org/wg/anima/trac/wiki/Bootstrap

the members on the web site say:
    Max Pritikin (editor),
    Michael Richardson (editor)
    Jason Coleman,
    Sandeep Kumar,
    Michael Behringer,
    Alper Yegin,
    Bing Liu,
    Brian Carpenter
    Kent Watson
    Sheng Jiang (wg chair),
    Toerless Eckert (wg chair)

Typically we have the following people participate in the weekly calls.
       Michael Richardson
       Max Pritikin
       Kent Watson
   We are frequently joined by Toerless Eckert.
   We would welcome additional people/viewpoints.

But there are a number in the above list which we haven't seen recently.
Please chime in and tell us what you are up to, and what your take on the
current situation is.

The webex link is valid until IETF98.

We expect to meet on March 14, but note that north american clocks will
have changed, so it will be 11am EDT.
We keep running minutes using the etherpad. Yes there is a typo in the link.

1) we posted -04 of anima-bootstrap prior to IETF97, and have been working on
   the -05, which will get posted this weekend.

2) since October, we posted three versions of draft-ietf-anima-voucher
   (some under the previous names draft-kwatsen-netconf-voucher, and draft-kwatsen-anima-voucher).

3) all of the drafts are revision controlled in git, and hosted on
   github.com, at https://github.com/anima-wg/
   The bootstrap git tree contains a subdirectory minutes, which is the
   raw dump from the etherpad.


These minutes are organized by topic with ideas taken from the raw minutes,
rather than chronologically.

TERMINOLOGY
===========
We agreed to the terminology proposed from the 6tisch-security
design team, and have made the changes in -05.  Another email
went to this list on that topic.


HACKATHON
=========
We discussed very early on what we would like to have to interoperate with
at the hackathon.  We concluded that exchange of vouchers and certificates
would make the most sense, even if we were using USB keys or web pastebins
for transport rather than HTTPS.
As of March 7, after many discussions that lead many places, we have
concluded that for IETF98, we will exchange JSON encoded vouchers
in PKCS7 containers such are easily produced by cli tools.

VOUCHER
=======
The voucher format is described at:
    https://tools.ietf.org/html/draft-ietf-anima-voucher-00#section-4.2

and looks like:
   {
     "ietf-voucher:voucher": {
       "assertion": "logged",
       "trusted-ca-certificate": "base64-encoded X.509 DER",
       "owner-id": "Registrar3245",
       "unique-id": "JADA123456789",
       "created-on": "2016-10-07T19:31:42Z",
       "nonce": "987987623489567"
     }
   }


The following table is now in the dtbootstrap-anima-keyinfra-05, section 2.2:

                  |Assertion   |Registrar ID    |Pledge ID | Validity    |
                  |Log-|Veri-  |Trust  |CN-ID or|serial    | RTC | Nonce |
                  | ged|  fied |Anchor |DNS-ID  |number    |     |       |
     --------------------------------------------------------------------|
     Audit        |  X |       | X     |        | X        |     | X     |
     -------------|----|-------|-------|--------|----------|-----|-------|
     Nonceless    |  X |       | X     |        | X        |     |       |
     Audit        |    |       |       |        |          |     |       |
     -------------|----|-------|-------|--------|----------|-----|-------|
     Owner Audit  |  X |   X   | X     |        | X        |     | X     |
     Owner Role   |  X |   ?   | X     |  X     | X        |     | X     |
     -------------|----|-------|-------|--------|----------|-----|-------|
     Owner ID     |    |   X   | ?     |  X     | X        | X   |       |
     -------------|----|-------|----------------|----------|-------------|
     BearerVoucher|  X |       |   wildcard     | X        | ?           |
     -------------|----|-------|----------------|----------|-------------|
     MasterVoucher|    |       |   wildcard     | wildcard | X   |       |
     -------------|------------|----------------|----------|-----|-------|

we had a lot of discussion about how each kind of voucher can be used, and
what they mean.
We have come dangerously close to writing a Use Case / Requirements section/document.

REVOCATION of VOUCHERS
======================

Nonceless Vouchers can be issued in advance and stored for many years
and used when a device is finally deployed.  Reference to the owner by
CA+DN (rfc7093 provides a way) permits the registrar's key to be cycled
many times.

The question has remained: do we need a way to revoke vouchers?

If the answer is yes, we considered that maybe the vouchers should be cast in
PKIX format as if they were certificates, such that we could use the same
kind of CRL or OCSP mechanisms.  We are not yet convinced of this;
but we do think that we could include a serial number in each voucher
such that we could, even if the voucher was not in PKIX format, use
OCSP with that serial number.  This discussion remains open.

What definitely came out of this is that we need more text to explain
how each voucher-type should be used to address particular deployment
scenarios.  From that, we also need to better define the deployment
scenarios, probably giving them easily discussed names.


BEARER VOUCHER
==============
After much discussion, we decided that the operational security problems with
providing for a bearer token lead us to conclude that we do not want to
standardize one.  We think that there are other ways to do almost the
same thing.

JWT / CWT
=========

We discussed having the voucher be in JWT format, as described in RFC7519,
RFC7517, etc.  This would also permit switch to CWT format as described
in draft-ietf-ace-cbor-web-token.  This discussion is not over, but
for the purposes of IETF98, this is out of scope.

A JWT/CWT might look like:
  {
    "iss":"Registrar3245",
    "iat": 1478854302,
    "nbf": 1478824302,
    "exp": 9999999999,
    "cti": "987987623489567"
    "logged": "true",
    "aud": "base64-encoded X.509 DER",
    "sub": "JADA123456789",
  }

CONCURRENT REGISTRATION
=======================

We had a discussion over a few meetings about the how much we needed to say
about pledges that see multiple Join Proxies, and which have the CPU/RAM to
attempt to enroll over all proxies at the same time.

One of the reasons to do this is because it eliminates concern where an
attacker (operating a rogue proxy, or a fake JRC) attempts to sabotage the
enrollment process by very slow TCP communications.  The goal would be to
annoy the operator who them chooses a less secure alternate mechanism, or the
vendor provides some kind of backdoor.  Setting "appropriate" timeouts
could (and should) be done, but this may result in failures when the
network is simply very congested.  Doing the work concurrently avoids having
any one attempt hold up the others; but as soon as one attempt succeeds,
other attempts would be abandonned.  We did not figure out how much
text we need add about this, but we feel that there are no protocol concerns
with concurrent join attempts.


mDNS
====
   AI: The M_FLOOD vs mDNS initial discovery discussion is not over, and
   we should invite the DNSSD/mDNS folks to come and make the case.

   This remains an Action Item, and we need to reach out to the
   proponents of mDNS to more clearly articulate the reasoning behind their
   preferences, and also to clearly explain how they would use mDNS.
   A major difference seems to be that mDNS would not support a passive
   (listen-only) mode for the pledge.  It would have to do a multicast
   discovery for the service, announcing itself to the entire network.

CoAP
====
  We have removed the CoAP mechanism until we prepared to properly
  define it.


IPIP
====
  We have added an appendix to explain the IPIP proxy mechanism.
  It is no longer a MUST.


Continued GRASP Proxy/Registrar discussion
==========================================

A thread was posted to the list already about how we should properly do
discovery of the registrar by the Join Proxy.


CLOSING LIST?
=============

Our WG chair has suggested that it is time to close the anima-bootstrap list.

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






_______________________________________________
Anima-bootstrap mailing list
Anima-bootstrap@ietf.org
https://www.ietf.org/mailman/listinfo/anima-bootstrap

From nobody Fri Mar 10 07:33:06 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D123129639; Fri, 10 Mar 2017 07:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 R5qGmbuHMLVN; Fri, 10 Mar 2017 07:32:59 -0800 (PST) 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 9D09E12964B; Fri, 10 Mar 2017 07:32:55 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 81EDCE207; Fri, 10 Mar 2017 10:55:43 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5AA086381A; Fri, 10 Mar 2017 10:32:54 -0500 (EST) From: Michael Richardson To: "Panos Kampanakis \(pkampana\)" In-Reply-To: X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "anima-bootstrap@ietf.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "ace@ietf.org" Subject: Re: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: 6tisch-security@ietf.org, anima-bootstrap@ietf.org List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 15:33:01 -0000 --=-=-= Content-Type: text/plain {to reply to an old email with some valid questions, and some questions of my own. I am also clipping the reply-To} Panos Kampanakis (pkampana) wrote: > I am curious about your workflow in > https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html You > are envisioning for the JCE to initiate the bootstrapping to the > pledge, but wouldn't that better be defined in the > anima-bootstrapping-keyinfra doc? Constrained bootstrap is not really in scope for ANIMA. The general constrained bootstrap situation is too big, but 6tisch constrains the possible solution space, which is why we feel that we can make progress there. So, I want to accomodate constrained bootstrap in anima-bootstrap, but not define it. > About 'simple system that can be used with PSKs as authentication', I > was curious. Did you have TLS-PSK, or TLS-SRP or OSCOAP message auth > with PSK/RPK/Cert? Anything more detail about these usecases? This is being proposed as 6tisch-minimal-security, and it uses OSCOAP and EDHOC. > A nit in " <--- CoAP POST /cert----- [PKCS7 Certificate] ". That > message would require the private key to be included with the cert > since the pledge did not generate it by himself. EST defines CMS for > this message. PKCS12 could suffice here as well with the challenge if > the passphrase provisioning being the problem. I'm not sure I understand this. Why do you say that the pledge did not generate it by himself? I"m assuming that it did so at manufacturing time, and that an IDevID certificate was bound to the public part of the key. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljCxyMACgkQgItw+93Q 3WXhWwf/UL6gJbmBQNTQWDcOpV94AhybwzKFHvwf16x6SpTkCZaankGezId9jSic sdjLlKoU1j2YTFW2Iyf/JkV1V5cxSrzXIZFdbFAgt5Zh5XapRO4JzRz3A4u09nwc yDwRAgncVutxQOM+7M0rI/5AiJ+UoqvP0tnaB7w9KAmy1o0JEskwl8zctq1RFw0S eglLq7tgbU096kmW/BMvDwK0bq0csq/nKoR+CjMGITGFr/8Dvsl1sAj8JoclfT9f 9n952+sqgoERhd76yK694LFCG+luYq3Y8crwVli/ldjHEK4zDV/M/PBBZpGhLAYL bvasuIKq1UHCRs44itQ9lX9l6NHjVQ== =QofY -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 11 18:47:25 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920CA129873 for ; Sat, 11 Mar 2017 18:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 ytngeJ8K7NQR for ; Sat, 11 Mar 2017 18:47:23 -0800 (PST) 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 5A5DB12985D for ; Sat, 11 Mar 2017 18:47:23 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 13ABF2009E for ; Sat, 11 Mar 2017 22:10:16 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CE23A6381A for ; Sat, 11 Mar 2017 21:47:21 -0500 (EST) From: Michael Richardson To: anima-bootstrap X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+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: [Anima-bootstrap] voucher updates in git X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 02:47:24 -0000 --=-=-= Content-Type: text/plain I've read through the voucher changes (eliminating VRLs), and the fix ups. I agree with it all. Good work... post it! [My only conplaint is some of the gratuitous whitespace changes in the diff of the xml :-)] -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljEtrcACgkQgItw+93Q 3WUI0gf/UDK3BZUdI2h1wFDekZxrXLJZghQdbrdC+q1qW6eHHlZ1L4fTQ7dPGZup wKKnRSguZoNSLPfVOehoiBlNhS8oPfekLK9I2lKdKU1GaggqPEQdSaQGgjGEQ/cP 2pkCDdwBL9uQXmM1nG4ssgLd+KppilBei3WxH8SwInveWIvEnQuZRX0sJVEMerDF OvP6SgdCreVGvSU4+KBEkGxuO5A+PjQ66oyP5PQoIMudnbZcjzgNOSRJfIUybmWl oi80bbo4Utvf0Nh0wh22TRJe1Ac8jML41oiQH8Y3M4KUVZ2j8qTlcdhU5FZakmZi Om/GWUr/HkDn/H9jYB9sEEJmziaKaQ== =SJ7U -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 13 03:00:47 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B0912954B for ; Mon, 13 Mar 2017 03:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFiQZVLsrMzY for ; Mon, 13 Mar 2017 03:00:44 -0700 (PDT) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (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 7D39912955D for ; Mon, 13 Mar 2017 03:00:43 -0700 (PDT) Received: by mail-lf0-x244.google.com with SMTP id g70so11374023lfh.3 for ; Mon, 13 Mar 2017 03:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=VdqJn9oVVbTbuapV//KVAK3XoOq2674BCJkP0BZzUtc=; b=Lu3NiBdr/Vk2b8j7qKVva3xJKnv8wMiqX5caoyQop9AVa2UUZcNCqoF2sPI6aZZd3v 7KtDhbotrWpkBy9x8bVmvel8IFcSz4+NX0hig3gz1P1YPvMu8iQdUmMjP7k0JL7vFV8g VRygZb6HI7D4XPryUDtkbdmFy+D4oSFi490+Y4Tz3c1c5UcK8piN0mEq7CMe9UV1ZY5u gV2wuJir2us/vBhMHHctY4KEs6NfrqhLx8NJBe6DUiF+jPTxg+VUB/6LBlACpWP+vdoL qhFCxYbx91ulggkMP0I8D7AmUlxHbUDQFZeaYpbeBOsqdDSa+v3X1thy36hMh+AqyUll Yi/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=VdqJn9oVVbTbuapV//KVAK3XoOq2674BCJkP0BZzUtc=; b=ToSlaZDQpxnd1y+/SCzu9FOudMILUEnp1xS8OOidpfJ2Q9MXzJTzKc1RyCOCE1qylK 4NTcr7G++MLdMtvyI06yPCfYuyvhaWLTPLiMWpU6c3FIWHYTVIAyXZuZC0SoOXygb8O9 rvjIZAsJ9IbcM+iIyDjAScS8yAOw7ATyDn1nhYwYqRrlVOzAB46klgfAhxK4EkBy0OXL 8/gdmMp27jiuNXxd10OI8Tdzt1Jpj+j4V+1qikbvZL3SdyGmu/dtqBbcNilfceWUYn39 D/zlkHJkKIxebLVXVFWK3+wZ8L3w27mLe9s+L/+7F0YKVsXKiE7m3v0C3XzI3rfpGc4f utHA== X-Gm-Message-State: AFeK/H0WhdXGzXP2P9Pp7ew/BSFeRJReJQx/JUik3Cp1OWZul2A8PvoW13naxivv7Xa/OQ== X-Received: by 10.25.115.19 with SMTP id o19mr5120002lfc.162.1489399241480; Mon, 13 Mar 2017 03:00:41 -0700 (PDT) Received: from [192.168.1.58] (ANice-652-1-354-117.w83-201.abo.wanadoo.fr. [83.201.77.117]) by smtp.gmail.com with ESMTPSA id 191sm3543012lfz.44.2017.03.13.03.00.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 03:00:40 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: anima-bootstrap@ietf.org Message-ID: <1ceb477e-ccd0-8c9b-388f-1ec6702c84f2@gmail.com> Date: Mon, 13 Mar 2017 11:00:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima-bootstrap] Names of states aligned with reference draft X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 10:00:46 -0000 Max, Michael, Just edited the state diagram in BRSKI, to make the beginning and end state align with the reference document. I think we had already agreed, so I made the edits in github, and issued a pull request. Let me know if this is ok. Michael From nobody Tue Mar 21 07:09:55 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A41D129495 for ; Tue, 21 Mar 2017 07:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 K15kMeD_7Y2W for ; Tue, 21 Mar 2017 07:09:45 -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 420C71201F2 for ; Tue, 21 Mar 2017 07:09:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9F4B3E209 for ; Tue, 21 Mar 2017 10:33:09 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9AD01636BB for ; Tue, 21 Mar 2017 10:09:42 -0400 (EDT) From: Michael Richardson To: anima-bootstrap X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+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: [Anima-bootstrap] webex is going now X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 14:09:53 -0000 --=-=-= Content-Type: text/plain sorry, I was late from an errand and I forgot that only I could start the meeting at the unscheduled time. http://etherpad.tools.ietf.org:9000/p/anima-boostrapping?useMonospaceFont=true JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m00a039327e09fc09340872992b151581 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljRNCYACgkQgItw+93Q 3WWUiwgAomYZhDmEJ7mzmQQSpy0eoqxze03G24aKs9VhzNwGinkD9Lg/xYvXc3Z0 jogSGvkieNGcuk8HBtGCO0wQ4PXVf6V36J4agTIzhzNOtJJP+adKareyYrgaS4jK iVQQ8reSweSrOY8imvSITYpTYo5Et1ltoaECkTIMLkig5M2JqQVu9pfmsTZwmHBB K2n7Xliea61BToq9Vm0mRgsnyqomH0Zn9jWdIr7vOC14Nxq/EuZtTvOBVh/G0rMt Lq1LgfouFRZwmiEgxPBRXApDu3qSCQTgsM9jd3RJYUQBfCDQGxtdx7O9LU7sdHQj lA5RFUfdTV1lF/mlj6JgocokDSjXJg== =Lcql -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 24 11:55:54 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E828F1294BE for ; Fri, 24 Mar 2017 11:55:52 -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, 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 IC9S_9fYE5d4 for ; Fri, 24 Mar 2017 11:55:51 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D58129458 for ; Fri, 24 Mar 2017 11:55:51 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [199.72.36.3]) by relay.sandelman.ca (Postfix) with ESMTPS id 746E91F8FB for ; Fri, 24 Mar 2017 18:55:49 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 448953412; Fri, 24 Mar 2017 12:09:00 -0400 (EDT) From: Michael Richardson To: anima-bootstrap@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 24 Mar 2017 11:09:00 -0500 Message-ID: <32445.1490371740@dooku.sandelman.ca> Archived-At: Subject: [Anima-bootstrap] alternate to domain-certificate-identifier missing from voucher yang X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 18:55:53 -0000 --=-=-= Content-Type: text/plain The MASA can use the combination of: trusted-ca-certificate plus (domain-certificate-identifier.subject xor cn-id xor dns-id) to indirectly point at the JRC's certificate. There could be a series of certificates in the chain between the trusted-ca-certificate and the thing the voucher staples down, clearly. In the yang, we write about trusted-ca-certificate: This field is optional because it may not be needed by all bootstrapping protocols. So I was looking for the other way, where one points right at the JRC's public key. I didn't find it. So I thought: OH, of course, one could specify a certificate chain of zero length, by putting the JRC's subjectKeyInfo into trusted-ca-certificate! Or can I? I don't think we got the reference in trusted-ca-certificate correct (and I don't have 5280 on the plane with me. Bad me, disk space is cheap) to check. I think that: An X.509 v3 certificate structure as specified by RFC 5280, Section 4 is too much, I think we just wanted the subjectKeyInfo as suggested by Sean Turner. (Okay, I will follow up to my email and check) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJY1UScAAoJEJVM4Vb9/EKQvqUIAKbABpp3+rPLLM0eYds0Dndu a12/2iJVGev0k9ZAHbrYJ8hTYgO9CgvDk+QZSwEJ1GuQQPdnqNZrewBQhLc7LNDl xvvuw19+XjyUGtyeAC5H/oiYCxNCtZnmQU2q3/fxKntYSzC9+r82r7XBpdpr61kV Vyb6E6OuUnOLvnBnLCMuUqxYItMdqSJNX9/U3G1M+s3TuALlGAgkwy8c+5GEAoY5 RuXvt/ZVWdvVBe0FyC8u9s6iLD2+u2uZbPaB7EtsLiuzF/Jqr2W6Z777TCXC7A36 gr2sMjW/GK87kPchjbgRo4f/FQwTQA3/iSgbmN7Ecd7GuSeG53Znh6tf8nk+a0Q= =8hdz -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 24 16:07:32 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCFC128CD5 for ; Fri, 24 Mar 2017 16:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 3PvlDIbepZWY for ; Fri, 24 Mar 2017 16:07:30 -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 DF11E12762F for ; Fri, 24 Mar 2017 16:07:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D18DAE19B for ; Fri, 24 Mar 2017 19:31:07 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1AAF0636E0 for ; Fri, 24 Mar 2017 19:07:29 -0400 (EDT) From: Michael Richardson to: anima-bootstrap@ietf.org In-Reply-To: <32445.1490371740@dooku.sandelman.ca> References: <32445.1490371740@dooku.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+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-bootstrap] alternate to domain-certificate-identifier missing from voucher yang X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 23:07:31 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: > Or can I? I don't think we got the reference in trusted-ca-certificate > correct (and I don't have 5280 on the plane with me. Bad me, disk space > is cheap) to check. I think that: An X.509 v3 certificate structure as > specified by RFC 5280, Section 4 Shouldn't it refer to: 4.2.1.2. Subject Key Identifier We can include the literal DER encoding of the the public key, if we want a *KEY* here. > is too much, I think we just wanted the subjectKeyInfo as suggested by > Sean Turner. This is a hash of public key info. It was, again: https://tools.ietf.org/html/rfc7093 abstract: This document specifies additional example methods for generating Key Identifier values for use in the AKI (Authority Key Identifier) and SKI (Subject Key Identifier) certificate extensions. I think that domain-certificate-identifier could be specifying RFC7093 DER. We have said DER and binary, and when translated to JSON, that results in base64 encoding, and we sign that with PKCS7, I think. Note that if we specify hash of public key, we have to use TLS key agreement processes that include the public key itself. That's not a big deal, but it would be wirth making sure that we can all of this for RPK. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljVprAACgkQgItw+93Q 3WWgBAgArb57uWkFfYoNh/fyPqUtMH+81E4u1kBuX6oIqigQ270qHiWpBtquLugR 7ejz4Uo9dzp+juRrHibGtfswx69Y8meCzaiDJUjm8yN/0W3Yt/ZEqDw0z96oLj96 k9/DZelbD3vH6UGCy0VWyDh8frUWZlQw1rugAsVe8pJl0Q6hkRsywXHD3Nqj/YtA Pv4Hlkz2l71xqShk6vXPU86hZT5MDqXABIGmTcC9Pbbu8s9vMzBGHNexZC30w8Hx xtDUljjxJZDHj2WAC/VyZMQKQUyoMf7rVyO3sehBTlh8aW7E7pOY96h1YvHCS9iW zm5N3kL9i9NCGFfBFjzXweiteHVd/Q== =aJtI -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 25 09:00:23 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1CB129445 for ; Sat, 25 Mar 2017 09:00:22 -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, RP_MATCHES_RCVD=-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 LLmrxCq-EhGD for ; Sat, 25 Mar 2017 09:00:20 -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 E2BCD128BBB for ; Sat, 25 Mar 2017 09:00:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 91C95203B2 for ; Sat, 25 Mar 2017 12:23:59 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 63B79636E0 for ; Sat, 25 Mar 2017 12:00:18 -0400 (EDT) From: Michael Richardson to: anima-bootstrap@ietf.org In-Reply-To: <13359.1490396849@obiwan.sandelman.ca> References: <32445.1490371740@dooku.sandelman.ca> <13359.1490396849@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+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-bootstrap] alternate to domain-certificate-identifier missing from voucher yang X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 16:00:22 -0000 --=-=-= Content-Type: text/plain Kent explained the history of how we got to having the full certificate due to DTLS making that anchor certificate optional. I also realize that we can use the extensions in https://tools.ietf.org/html/rfc7250#section-3 so that we can bind directly to public keys, which makes me happy. Michael Richardson wrote: > Michael Richardson wrote: >> Or can I? I don't think we got the reference in >> trusted-ca-certificate correct (and I don't have 5280 on the plane >> with me. Bad me, disk space is cheap) to check. I think that: An >> X.509 v3 certificate structure as specified by RFC 5280, Section 4 > Shouldn't it refer to: 4.2.1.2. Subject Key Identifier > We can include the literal DER encoding of the the public key, if we > want a *KEY* here. >> is too much, I think we just wanted the subjectKeyInfo as suggested by >> Sean Turner. > This is a hash of public key info. It was, again: > https://tools.ietf.org/html/rfc7093 > abstract: > This document specifies additional example methods for generating > Key Identifier values for use in the AKI (Authority Key Identifier) and > SKI (Subject Key Identifier) certificate extensions. > I think that domain-certificate-identifier could be specifying RFC7093 > DER. We have said DER and binary, and when translated to JSON, that > results in base64 encoding, and we sign that with PKCS7, I think. > Note that if we specify hash of public key, we have to use TLS key > agreement processes that include the public key itself. That's not a > big deal, but it would be wirth making sure that we can all of this for > RPK. > -- > Michael Richardson , Sandelman Software Works -= > IPv6 IoT consulting =- -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljWlBIACgkQgItw+93Q 3WX1uwgAwmnuo6DjxjcPZ4Pig/v/dVYJyqwbjR+N5nvo0Z8KKbyC+7hbhR3yhqKM EpDt4XScPMLn+kihZYDk4Pmi9FFmQ2xCr7tg4X66xeT9Irfve4ZnE+T65Ig0ZIsv MRBzFzoKaNYUP5PR1800idUNQoM0VgJeac+dYaBGWueYiFYbcWnzF9Hj4h99UjVx OLev14z6lwAPtNJH5AivACgooYFN8iPbPD1I2CGXIkgG7o5pbB34bYXL3zADhGd9 4n1MKZBrR9ym6AqDqTyyT7r7VUIAn4Km397aa9M07csk/SybCNaz30lTkBV7p3av mnYCDu33oVlBTLWUqIa+39s0EKF9Bw== =fi1Y -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 30 16:29:49 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9845D129515 for ; Thu, 30 Mar 2017 16:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 35B1E_t1howG for ; Thu, 30 Mar 2017 16:29:45 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1523128B38 for ; Thu, 30 Mar 2017 16:29:45 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2D9C3200A3 for ; Thu, 30 Mar 2017 19:53:44 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A2128636BB for ; Thu, 30 Mar 2017 19:29:44 -0400 (EDT) From: Michael Richardson To: anima-bootstrap X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+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: [Anima-bootstrap] no meeting next week? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 23:29:48 -0000 --=-=-= Content-Type: text/plain I'd like to propose we skip Tuesday April 4 meeting, and next meet on April 11. Just to avoid exhausting ourselves :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljdlOgACgkQgItw+93Q 3WXBsAgAwk8yfZ7QwPgMxblUfDaezRrNWE7iPIs29L8pkddk7g1Zz1s00CfV6UMA U44e+rJnoqWXdzCdjlmxlgngjBNXVwUCzSnRdir7gvYa/fORuLxSGjuq2mfwQM4i evzd2i0FeZ2uC4nNtOaGuGOytXwsJGj88pgRXBXivu2S4fcPLOMnm2vqgrinkzm2 iULl7zYh4ZJqLM8mu/CFA1bvSU4q9gtKUNa+C+dCN8VpxPVdgTWc4hY8E8Yhxr8b 4tB8JQa7Jzx5MIzF0DpYRt+NouEzAUgMf8K+PRSIWD7MMdYVp6im/WwFBX8XVcll 0JPezBRtf1AQ0mrfZhB9fmy9gnYl5g== =rFkS -----END PGP SIGNATURE----- --=-=-=--