From nobody Wed Dec 7 11:37:54 2016 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 E6A03129AA2; Wed, 7 Dec 2016 11:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 PqmbnRRalV-h; Wed, 7 Dec 2016 11:37:46 -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 CCCBB129584; Wed, 7 Dec 2016 11:37:35 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 08B19203AE; Wed, 7 Dec 2016 14:55:02 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 71E6A63768; Wed, 7 Dec 2016 14:37:34 -0500 (EST) From: Michael Richardson To: "ace\@ietf.org" , 6tisch@ietf.org, 6tisch-security@ietf.org, anima-bootstrap@ietf.org In-Reply-To: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.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] [Ace] EST over CoAP in ACE wg X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ace@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: Wed, 07 Dec 2016 19:37:49 -0000 --=-=-= Content-Type: text/plain I have read: draft-pritikin-coap-bootstrap and draft-vanderstock-core-coap-est and over in the 6tisch security design team we have been trying to adapt the ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the 6tisch environment as a zero-touch enrollment process. (Yes, I am an author involved in both WGs) Peter (one of the authors of draft-vanderstock-core-coap-est) and Max (author of draft-pritikin-coap-bootstrap) are involved. Both documents have good content, and we could combine them easily and wind up with a relatively straight forward description of how to run EST over COAPS. But I don't think that this really solves the problems that we have. However, the movement in draft-vucinic-6tisch-minimal-security (as phase 2, and one-touch) and draft-richardson-6tisch-dtsecurity-secure-join (as phase 1, zero-touch) [both of which are being considered for adoption] is to move away from DTLS and towards OSCOAP and EDHOC. As such, what we would really like is an EST-like mechanism which runs over OSCOAP with EDHOC keying. Ideally, it would also permit the process to be managed/initiated from the new device (the pledge), or from the JCE (Registrar, which might also be the AS in ACE terminology). We want to initiate from the JCE so that we can: a) simplify the constrained device. b) manage the order and priority of join activities to avoid network congestion in constrained (mesh) networks. On the other hand, some want a really simple system that can be used with PSKs as authentication, with the new nodes initiating. I wrote this email last week to explain some of what I have in mind. https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html I don't know if the EST work fits into ACE's charter, but given that ACE is where OSCOAP and EDHOC seem to be, I'm happy to work on a document here. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhIZP4ACgkQgItw+93Q 3WXOWQf+KBR6EmPppxIOwna8SV1Urd6mO40e5GVek2gMe/waBEc9koF1smIztedO +V149y098pwPFKmUPMKpWDu4uffFYxJX/aA8X5xWQnJRh3V5fDJJqPXYOPkKDs6o XlKZNiMKloERRwDqVo6dvdi3q1RoLvkO95/SRDu6bzBNnIN9McoqgxxKUs7ofuL+ azR6bsragScPy7PjZcZZwALQYsfw/xZdmO/ztbM/fJ48yxxmzNHPZupLoXxJLVbZ 39BuOkICn+DZ57rMDr2gP8Oh/iwmCUYtrsHnNPaQ5EZqJ1cC6RZZGbh9LZaB5i/S CUvQyN/LCy+OwlHH+y9i9YukNUuJrw== =pTHt -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 8 00:12:24 2016 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 91C96129CCA for ; Thu, 8 Dec 2016 00:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 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] 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 855XLK-GLJXS for ; Thu, 8 Dec 2016 00:12:16 -0800 (PST) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A8F129CB3 for ; Thu, 8 Dec 2016 00:12:16 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.195]) by smtp-cloud6.xs4all.net with ESMTP id HLCE1u0034CYHle01LCEJ8; Thu, 08 Dec 2016 09:12:14 +0100 Received: from 2001:983:a264:1:e4b5:c90e:f42d:52ed by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 08 Dec 2016 09:12:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 08 Dec 2016 09:12:14 +0100 From: peter van der Stok To: ace@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <14831.1481139454@obiwan.sandelman.ca> References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> Message-ID: <5ac94ac231bc766afdb72776f6ea5e0f@xs4all.nl> X-Sender: stokcons@xs4all.nl (hXPlVLSW7/ja0OkiFMaSjBRy1n/Lryw4) User-Agent: XS4ALL Webmail Archived-At: Cc: 6tisch@ietf.org, anima-bootstrap@ietf.org, 6tisch-security@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: 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: Thu, 08 Dec 2016 08:12:23 -0000 Hi Michael, > > As such, what we would really like is an EST-like mechanism which runs > over OSCOAP with EDHOC keying. Ideally, it would also permit the > process > to be managed/initiated from the new device (the pledge), or from the > JCE > (Registrar, which might also be the AS in ACE terminology). > About yesterday I started to understand the approach you suggest. Just some more information, to be absolutely sure about what you propose. Do you propose to keep the content formats used by EST unchanged? and keep all the different modes specified in EST RFC? Greetings, Peter From nobody Thu Dec 8 22:04:31 2016 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 204631293EE; Thu, 8 Dec 2016 22:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.418 X-Spam-Level: X-Spam-Status: No, score=-17.418 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 eYOuGX8pPXes; Thu, 8 Dec 2016 22:04:24 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6932128B38; Thu, 8 Dec 2016 22:04:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4048; q=dns/txt; s=iport; t=1481263463; x=1482473063; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Tk/ObWcHBerR5Y0U6HMtC5vA9NyrCvWbZRnEXovn0dU=; b=ZY7ganrAcPhPWjoyFHMNAEUZAaFXyXLgB0cJHPR9TCxVvroRtnMfgcvc RefdqFsFZB0/ZKklZPXgSTOUHWMcZSn1HRN1vTi71AXP604PlZViBUKv8 hOIMELa8CZFMxFxe+J7AVqxJxmpicSC47gjwTK6MLtypxHUWQAG+HqzAj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAQCDSEpY/4UNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgywLAQEBAQEfWoEGB41ClxOVAoIJKYJCgmxKAoF8PxQBAgEBAQEBAQF?= =?us-ascii?q?iKIRoAQEBBDpLBAIBCBEEAQEfCQcyFAkIAQEEARIIiGMOqVmLLAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhj6EW4QaEAIBTYUvBZprAYlehziBfIhGhguOC4QNAR8?= =?us-ascii?q?3YTyDXRyBXXIBiAuBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,323,1477958400"; d="scan'208";a="184901328" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Dec 2016 06:04:22 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id uB964MGk012495 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Dec 2016 06:04:22 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Dec 2016 00:04:21 -0600 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1210.000; Fri, 9 Dec 2016 00:04:22 -0600 From: "Panos Kampanakis (pkampana)" To: "ace@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "6tisch-security@ietf.org" <6tisch-security@ietf.org>, "anima-bootstrap@ietf.org" Thread-Topic: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg Thread-Index: AdJD/4dN3nkys8JpRuSDXvz8bQBVcAM9B64AADuYMdA= Date: Fri, 9 Dec 2016 06:04:21 +0000 Message-ID: References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> In-Reply-To: <14831.1481139454@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.216.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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 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, 09 Dec 2016 06:04:26 -0000 Hi Michael, This are interesting good points. IMO, draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est do not n= ecessarily need to define one transport mechanism. COAPS (over DTLS) is one= obvious option but running over OSCOAP with EDHOC is another. One of the g= oals of these drafts (would need to be merged) is the binding between COAP = messages and BRSKI / EST APIs for all the bootstrapping and cert enrollment= transactions defined in the anima-bootstrapping-keyinfra doc and RFC7030. = draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est address DTLS = as transport mechanism right now, but could be expanded to define more than= one transports. If the WG finds that as a better idea, normative language = would need to be carefully of course and maybe an MTI option would need to = be chosen. I am curious about your workflow in https://www.ietf.org/mail-archive/web/6= tisch/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 an= ima-bootstrapping-keyinfra doc? About 'simple system that can be used with PSKs as authentication', I was c= urious. Did you have TLS-PSK, or TLS-SRP or OSCOAP message auth with PSK/RP= K/Cert? Anything more detail about these usecases? A nit in " <--- CoAP POST /cert----- [PKCS7 Certificate] ". That messag= e would require the private key to be included with the cert since the pled= ge did not generate it by himself. EST defines CMS for this message. PKCS12= could suffice here as well with the challenge if the passphrase provisioni= ng being the problem. Rgs, Panos -----Original Message----- From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On Behalf O= f Michael Richardson Sent: Wednesday, December 07, 2016 2:38 PM To: ace@ietf.org; 6tisch@ietf.org; 6tisch-security@ietf.org; anima-bootstra= p@ietf.org Subject: Re: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg I have read: draft-pritikin-coap-bootstrap and draft-vanderstock-core-coap-est and over in the 6tisch security design team we have been trying to adapt th= e ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the 6tisch en= vironment as a zero-touch enrollment process. (Yes, I am an author involved in both WGs) Peter (one of the authors of draft-vanderstock-core-coap-est) and Max (auth= or of draft-pritikin-coap-bootstrap) are involved. Both documents have good content, and we could combine them easily and wind= up with a relatively straight forward description of how to run EST over C= OAPS. But I don't think that this really solves the problems that we have. However, the movement in draft-vucinic-6tisch-minimal-security (as phase 2, and one-touch) and draft-richardson-6tisch-dtsecurity-secure-join (as phase 1, zero-touc= h) [both of which are being considered for adoption] is to move away from DTLS and towards OSCOAP and EDHOC. As such, what we would really like is an EST-like mechanism which runs over= OSCOAP with EDHOC keying. Ideally, it would also permit the process to be= managed/initiated from the new device (the pledge), or from the JCE (Regis= trar, which might also be the AS in ACE terminology). We want to initiate from the JCE so that we can: a) simplify the constrained device. b) manage the order and priority of join activities to avoid network congestion in constrained (mesh) networks. On the other hand, some want a really simple system that can be used with P= SKs as authentication, with the new nodes initiating. I wrote this email last week to explain some of what I have in mind. https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html I don't know if the EST work fits into ACE's charter, but given that ACE is= where OSCOAP and EDHOC seem to be, I'm happy to work on a document here. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Fri Dec 9 00:13:15 2016 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 A2F4812A19D; Fri, 9 Dec 2016 00:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sandeep.de 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 kNhzJcuRi0G2; Fri, 9 Dec 2016 00:12:59 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19FDA12A192; Fri, 9 Dec 2016 00:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1481271175; l=11443; s=domk; d=sandeep.de; h=Content-Type:Cc:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=jZDElEKRS7vQYNdGdqvR7hCMzGJAC8RutihCTnJS2EE=; b=V8+A0P22Q9NLu1+4NyfRFWMDHb2gKl7ngweypAzI5rmyHRELq2BqiHHxQQQ43ACmMY lZuVmKpJpuIoGjncZCvTOpJolySySNWs9yMm7hdYdRIVzwdo19rk6OszotvFqOmneYNh KYpScTMYWKORhbmFLjctrTtU24Jz9Wj+qzmVA= X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkNEKLhUifTGQRFYQZmh2f X-RZG-CLASS-ID: mo00 Received: from mail-qk0-f173.google.com ([209.85.220.173]) by smtp.strato.de (RZmta 39.10 AUTH) with ESMTPSA id t03c5asB98CsJck (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp384r1 with 384 ECDH bits, eq. 7680 bits RSA)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verification FAILED - unable to get local issuer certificate)) (Client hostname not verified); Fri, 9 Dec 2016 09:12:54 +0100 (CET) Received: by mail-qk0-f173.google.com with SMTP id q130so10398010qke.1; Fri, 09 Dec 2016 00:12:54 -0800 (PST) X-Gm-Message-State: AKaTC01EtXvCHh9f8C0ipQipDiR64G6BR6iKoAwCl4yAXxoQ5tudctDbYHJDvSd+biflWJ7F1G2erXhtj2r0tA== X-Received: by 10.55.43.29 with SMTP id r29mr66929057qkh.211.1481271173885; Fri, 09 Dec 2016 00:12:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.97.33 with HTTP; Fri, 9 Dec 2016 00:12:53 -0800 (PST) In-Reply-To: References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> From: Sandeep Kumar Date: Fri, 9 Dec 2016 09:12:53 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "Panos Kampanakis (pkampana)" Content-Type: multipart/alternative; boundary=001a1147e8e422baba05433552f8 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "anima-bootstrap@ietf.org" , Sandeep Kumar , "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 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, 09 Dec 2016 08:13:06 -0000 --001a1147e8e422baba05433552f8 Content-Type: text/plain; charset=UTF-8 HI Michael Just to add, 6tisch has decided to use OSCOAP as the transport but other external standards like Fairhair and Thread have already decided to use DTLS as the transport for EST since it is already there and does not break the workflow the way it might in 6tisch. So these draft on DTLS transport do solve the problem for some, not for everyone. Kind regards Sandeep On Fri, Dec 9, 2016 at 7:04 AM, Panos Kampanakis (pkampana) < pkampana@cisco.com> wrote: > Hi Michael, > > This are interesting good points. > > IMO, draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est do not > necessarily need to define one transport mechanism. COAPS (over DTLS) is > one obvious option but running over OSCOAP with EDHOC is another. One of > the goals of these drafts (would need to be merged) is the binding between > COAP messages and BRSKI / EST APIs for all the bootstrapping and cert > enrollment transactions defined in the anima-bootstrapping-keyinfra doc and > RFC7030. draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est > address DTLS as transport mechanism right now, but could be expanded to > define more than one transports. If the WG finds that as a better idea, > normative language would need to be carefully of course and maybe an MTI > option would need to be chosen. > > 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? > > 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? > > 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. > > Rgs, > Panos > > -----Original Message----- > From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On Behalf > Of Michael Richardson > Sent: Wednesday, December 07, 2016 2:38 PM > To: ace@ietf.org; 6tisch@ietf.org; 6tisch-security@ietf.org; > anima-bootstrap@ietf.org > Subject: Re: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg > > > I have read: > draft-pritikin-coap-bootstrap > and draft-vanderstock-core-coap-est > > and over in the 6tisch security design team we have been trying to adapt > the ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the > 6tisch environment as a zero-touch enrollment process. > (Yes, I am an author involved in both WGs) > > Peter (one of the authors of draft-vanderstock-core-coap-est) and Max > (author of draft-pritikin-coap-bootstrap) are involved. > > Both documents have good content, and we could combine them easily and > wind up with a relatively straight forward description of how to run EST > over COAPS. > But I don't think that this really solves the problems that we have. > > However, the movement in > draft-vucinic-6tisch-minimal-security (as phase 2, and one-touch) > and draft-richardson-6tisch-dtsecurity-secure-join (as phase 1, > zero-touch) > [both of which are being considered for adoption] > > is to move away from DTLS and towards OSCOAP and EDHOC. > > As such, what we would really like is an EST-like mechanism which runs > over OSCOAP with EDHOC keying. Ideally, it would also permit the process > to be managed/initiated from the new device (the pledge), or from the JCE > (Registrar, which might also be the AS in ACE terminology). > > We want to initiate from the JCE so that we can: > a) simplify the constrained device. > b) manage the order and priority of join activities to avoid > network congestion in constrained (mesh) networks. > > On the other hand, some want a really simple system that can be used with > PSKs as authentication, with the new nodes initiating. > > I wrote this email last week to explain some of what I have in mind. > https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html > > I don't know if the EST work fits into ACE's charter, but given that ACE > is where OSCOAP and EDHOC seem to be, I'm happy to work on a document here. > > -- > Michael Richardson , Sandelman Software Works -= > IPv6 IoT consulting =- > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --001a1147e8e422baba05433552f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

HI Michael

=C2=A0Just to add, 6tisch has decided to us= e OSCOAP as the transport but other external standards like Fairhair and Thread have already decided = to use DTLS as the transport for EST since it is already there and does not br= eak the workflow the way it might in 6tisch. So these draft on DTLS transport do so= lve the problem for some, not for everyone.

=C2=A0Kind regards

Sandeep

=C2=A0


On Fri, Dec= 9, 2016 at 7:04 AM, Panos Kampanakis (pkampana) <pkampana@cisco.com&= gt; wrote:
Hi Michael,

This are interesting good points.

IMO, draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-es= t do not necessarily need to define one transport mechanism. COAPS (over DT= LS) is one obvious option but running over OSCOAP with EDHOC is another. On= e of the goals of these drafts (would need to be merged) is the binding bet= ween COAP messages and BRSKI / EST APIs for all the bootstrapping and cert = enrollment transactions defined in the anima-bootstrapping-keyinfra doc and= RFC7030. draft-pritikin-coap-bootstrap/draft-vanderstock-core-coap-est address DTLS as transport mechanism right now, but could be expanded= to define more than one transports. If the WG finds that as a better idea,= normative language would need to be carefully of course and maybe an MTI o= ption would need to be chosen.

I am curious about your workflow in https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.h= tml You are envisioning for the JCE to initiate the bootstrapping to th= e pledge, but wouldn't that better be defined in the anima-bootstrappin= g-keyinfra doc?

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 wit= h PSK/RPK/Cert? Anything more detail about these usecases?

A nit in " <--- CoAP POST /cert-----=C2=A0 =C2=A0 =C2=A0[PKCS7 Cert= ificate] ". 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.

Rgs,
Panos

-----Original Message-----
From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On Behalf Of Michael Rich= ardson
Sent: Wednesday, December 07, 2016 2:38 PM
To: ace@ietf.org; 6tisch@ietf.org; 6tisch-security@ietf.org; anima-bootstrap@ietf.org
Subject: Re: [Anima-bootstrap] [Ace] EST over CoAP in ACE wg


I have read:
=C2=A0 =C2=A0 draft-pritikin-coap-bootstrap
and draft-vanderstock-core-coap-est

and over in the 6tisch security design team we have been trying to adapt th= e ANIMA WG draft-ietf-anima-bootstrapping-keyinfra for use in the 6tis= ch environment as a zero-touch enrollment process.
(Yes, I am an author involved in both WGs)

Peter (one of the authors of draft-vanderstock-core-coap-est) and Max = (author of draft-pritikin-coap-bootstrap) are involved.

Both documents have good content, and we could combine them easily and wind= up with a relatively straight forward description of how to run EST over C= OAPS.
But I don't think that this really solves the problems that we have.
However, the movement in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-vucinic-6tisch-minimal-securit= y (as phase 2, and one-touch)
and=C2=A0 =C2=A0draft-richardson-6tisch-dtsecurity-secure-join (as pha= se 1, zero-touch)
[both of which are being considered for adoption]

is to move away from DTLS and towards OSCOAP and EDHOC.

As such, what we would really like is an EST-like mechanism which runs over= OSCOAP with EDHOC keying.=C2=A0 Ideally, it would also permit the process = to be managed/initiated from the new device (the pledge), or from the JCE (= Registrar, which might also be the AS in ACE terminology).

We want to initiate from the JCE so that we can:
=C2=A0 a) simplify the constrained device.
=C2=A0 b) manage the order and priority of join activities to avoid
=C2=A0 =C2=A0 =C2=A0network congestion in constrained (mesh) networks.

On the other hand, some want a really simple system that can be used with P= SKs as authentication, with the new nodes initiating.

I wrote this email last week to explain some of what I have in mind.
=C2=A0 https://www.ietf.org/mail-<= wbr>archive/web/6tisch/current/msg05020.html

I don't know if the EST work fits into ACE's charter, but given tha= t ACE is where OSCOAP and EDHOC seem to be, I'm happy to work on a docu= ment here.

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



_______________________= ________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

--001a1147e8e422baba05433552f8-- From nobody Tue Dec 13 08:59:27 2016 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 51BFB129AE4 for ; Tue, 13 Dec 2016 08:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.095 X-Spam-Level: X-Spam-Status: No, score=-7.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 qBUr9XnxcMVk for ; Tue, 13 Dec 2016 08:59:21 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E23129B6C for ; Tue, 13 Dec 2016 08:59:04 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 72F6658C4AE; Tue, 13 Dec 2016 17:59:03 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 56163B0B0EF; Tue, 13 Dec 2016 17:59:03 +0100 (CET) Date: Tue, 13 Dec 2016 17:59:03 +0100 From: Toerless Eckert To: "Max Pritikin (pritikin)" Message-ID: <20161213165903.GA13281@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "anima-bootstrap@ietf.org" Subject: [Anima-bootstrap] Max: voucher terminology / explanations in next draft round 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: Tue, 13 Dec 2016 16:59:25 -0000 Hi Max, *: Wrt to the new text you are trying to work out for voucher terminology, that is captured in todays notes on the etherpad: I think that the voucher terminology will be confusing as long as the name "audit" (voucher) implies the use of a public key (line 144 in etherpad), and the "ownership" (voucher) implies the use of a certificate (via DN of certificate). audit vs. ownership are just describing the type of assertion. Whether i want to use public-key or Cert-DN is IMHO orthogonal (i think we already allow that in the voucher draft), and it could help if we are also clearer in the language. Aka: - classical anima voucher, call it: public key audit voucher - classical netconf voucher, call it: certificate ownership voucher - Can i have a certificate audit voucher ? Absolutely! - Can i have a public key ownersip voucher ? Absolutely! - Can i have a certificate or public key audit AND ownership voucher ? I think yes, but that would be icing on the cake. Which IMHO leaves to explain the differences semantically: - ownership vs. audit i think is simple - ownership: strong assertion by vendor. Can be pricy to support by vendor. - audit: lightweight assertion by vendor. - certificate vs. public key - low end solutions may want to be lightweight and not rely fully on a certificate system. Just using public key is more lightweight. - Even if a system wants to use certificates, relying only on public key decouples enrolment from PKI. Aka: more modular design: use public key enrolment, and use normal PKI Cert enrolment afterwards (using the trust relationship established via the public key). This is the option that ANIMA chooses because EST already provides such a standalone enrolment method. - Including certificate in the voucher allows those vouchers to lie around at an owner much longer. Their validity is as long as that of the included CA certificate (eg: >= 10 years). The validity of a public key is typically much shorter (eg: <= 1 year). - If vouchers are handled "offline" shipped via sneakernet/usb-sticks vendor->registrar in a solution where certificates are used (all the way into the pledge), certificate vouchers are the complete data needed. public key vouchers would require the certificate data to be encoded on the side too. Hope all four are correct. Thats high level how i'd try to explain the difference. Even if not correct, i hope it makes sense trying to figure out these type of explanations of differences in the choices our voucher solution offers. Cheers Toerless From nobody Sat Dec 17 11:50:38 2016 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 A350E1296EC for ; Sat, 17 Dec 2016 11:50:37 -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, 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 JfQ1I0-lnwtz for ; Sat, 17 Dec 2016 11:50:36 -0800 (PST) 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 884181293DC for ; Sat, 17 Dec 2016 11:50:36 -0800 (PST) Received: from dooku.sandelman.ca (CPEbc4dfb402cc3-CMbc4dfb402cc0.cpe.net.cable.rogers.com [174.113.238.167]) by relay.sandelman.ca (Postfix) with ESMTPS id 160DC1F905; Sat, 17 Dec 2016 19:50:35 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id F098731E7; Sun, 18 Dec 2016 04:50:33 +0900 (KST) From: Michael Richardson To: Toerless Eckert In-reply-to: <20161213165903.GA13281@faui40p.informatik.uni-erlangen.de> References: <20161213165903.GA13281@faui40p.informatik.uni-erlangen.de> Comments: In-reply-to Toerless Eckert message dated "Tue, 13 Dec 2016 17:59:03 +0100." 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: Sat, 17 Dec 2016 14:50:33 -0500 Message-ID: <11339.1482004233@dooku.sandelman.ca> Archived-At: Cc: "Max Pritikin \(pritikin\)" , "anima-bootstrap@ietf.org" Subject: Re: [Anima-bootstrap] Max: voucher terminology / explanations in next draft round 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: Sat, 17 Dec 2016 19:50:37 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > I think that the voucher terminology will be confusing as long as the > name "audit" (voucher) implies the use of a public key (line 144 in > etherpad), and the "ownership" (voucher) implies the use of a > certificate (via DN of certificate). audit vs. ownership are just I agree. I also think that the audit promise is orthogonal to how the owner is indicated. It might be that all combinations are not useful, but I'd like to enumerate them anyway. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYVZcJAAoJEJVM4Vb9/EKQ/UYH/jq9Ofx9nAaWB00WDqoCutd+ hpHI9zWIVr9OKZ/Ip4EPzqRyOmDX5n+Kiuap09d536HRf1dGtI4RVmOamy2+6PKn 97TNlZov+BP+8twylZEqvPylQaoT3A/PrWTXUkpcLik/MC74gJRxY75vtfbm20S5 9BgrB19V09GQaDrh80+4c7ydg47x3uTshGE/RUDm16NGsznFPBUIGoJSm5l5mUH7 re6ZihUtmHQi0C7Mutx7FgRRpA7sj2fTBWVCIfzM/45wmqU/CzGLgLgB2bKLkVpL ZcN68FMT6DEwCixlQHjOp9xuKwLqn++E4xCKIIkRh6tevcMWD1/ksigeJSq6yWI= =Px3L -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Dec 17 11:56:53 2016 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 16BE6129A63 for ; Sat, 17 Dec 2016 11:56:52 -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, 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 Y5vhxsfq6Mx2 for ; Sat, 17 Dec 2016 11:56:51 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 059ED12995D for ; Sat, 17 Dec 2016 11:56:51 -0800 (PST) Received: from dooku.sandelman.ca (CPEbc4dfb402cc3-CMbc4dfb402cc0.cpe.net.cable.rogers.com [174.113.238.167]) by relay.sandelman.ca (Postfix) with ESMTPS id C30681F905; Sat, 17 Dec 2016 19:56:49 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 898751771; Sun, 18 Dec 2016 04:56:48 +0900 (KST) From: Michael Richardson To: Toerless Eckert In-reply-to: <20161213165903.GA13281@faui40p.informatik.uni-erlangen.de> References: <20161213165903.GA13281@faui40p.informatik.uni-erlangen.de> Comments: In-reply-to Toerless Eckert message dated "Tue, 13 Dec 2016 17:59:03 +0100." 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: Sat, 17 Dec 2016 14:56:48 -0500 Message-ID: <11825.1482004608@dooku.sandelman.ca> Archived-At: Cc: "Max Pritikin \(pritikin\)" , "anima-bootstrap@ietf.org" Subject: Re: [Anima-bootstrap] Max: voucher terminology / explanations in next draft round 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: Sat, 17 Dec 2016 19:56:52 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > - Including certificate in the voucher allows those vouchers to > lie around at an owner much longer. Their validity is as long as that > of the included CA certificate (eg: >= 10 years). The validity of > a public key is typically much shorter (eg: <= 1 year). A certificate is valid as long as the CA that vouches for the DN renews the certificate. They keys can be renewed, and algorithms can even be replaced. That's the payoff from the overhead of the PKI. => This is what we need to capture into the document. A public key has no expiry date, since it has no date associated with it. When you say that a public key is "typically" shorter, you are really expressing a good crypto-hygiene suggestion to the owner of the public. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYVZiAAAoJEJVM4Vb9/EKQK0sH/jJmHjS4pHfh1S6UqgZFPgo1 ExgjQucnC5392LqdXQsQiI6B/KO+0Eh4o9eoQw4TLd9qYU3aNVZPDRUeuuzPDHuc BLqiyANdeKxAy+nIBTa5gO34buA1TEdmoShLCBq6MqSeixg4Wvx3SIVREaYQTNgO 0BzYYm4RFo6H+8iwbbStfSZQ6tfTlR1ywdBejcfPBviAtIkPl1QicepKija4AeeV cdnGZrM9SDBBaot4UgA3QvO3nVcQ4g2Y55AdPM0EFgTXxGNGyjhLjmhQzdJZHqkY LF4Rx8jzGWs0Q0QiaNHh2blo8+IZcmfG6r+JGh4u/iE7GgObfVD2+WjZUeCkQ2o= =huCb -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 19 14:18:42 2016 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 3E4A6129423 for ; Mon, 19 Dec 2016 14:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 9Hu8PqqQARrr for ; Mon, 19 Dec 2016 14:18:39 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE96129422 for ; Mon, 19 Dec 2016 14:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9480; q=dns/txt; s=iport; t=1482185919; x=1483395519; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xbdfO48EBuGQWoHlrAaPEnSpP2UcbfABqmFpOxgF9EE=; b=YwzMcxpyH8GzppKZ9FPgLSf0H/7EuBJyigfGeUm6aS40UtQ1zu6HfIFL k9ggLx8Wzyn6IHU/s/9MCIKabh5o4FF00l/2UBMaEnkDZN6mwFzwnyiw9 1Tzsb0xLWtifgIROjq+qujhRBwJHOzyUkBhUoMZuzSwtXQEsSvZ3JxMMa Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQAyXFhY/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR9agQYHjUiWWZUOggosgkCDNgIagWg/FAECAQEBAQE?= =?us-ascii?q?BAWIohGgBAQEDARIRETgNBQsCAQgYAgImAgICMBUQAgQBDQUiiEEIDpsvAY12g?= =?us-ascii?q?iiLEAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuHKIJchCYagwQtgjAFiGKGH4t?= =?us-ascii?q?vAYZRimKQTY4ZhA4BHzeBJToBhAGBRXKHfYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,375,1477958400"; d="scan'208";a="363114228" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Dec 2016 22:18:38 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id uBJMIcmt024789 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Dec 2016 22:18:38 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Dec 2016 16:18:37 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Mon, 19 Dec 2016 16:18:37 -0600 From: "Max Pritikin (pritikin)" To: Michael Richardson , Toerless Eckert Thread-Topic: [Anima-bootstrap] Max: voucher terminology / explanations in next draft round Thread-Index: AQHSVWI45q6GAxJkQEKUZle6H8APoqEM+TcAgANMSYA= Date: Mon, 19 Dec 2016 22:18:37 +0000 Message-ID: <527E573B-A83F-4C0A-A9F8-9F0B40A76195@cisco.com> References: <20161213165903.GA13281@faui40p.informatik.uni-erlangen.de> <11825.1482004608@dooku.sandelman.ca> In-Reply-To: <11825.1482004608@dooku.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.3] Content-Type: text/plain; charset="utf-8" Content-ID: <9A8193E31C200C4B85021AEBEFDF9F28@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "anima-bootstrap@ietf.org" Subject: Re: [Anima-bootstrap] Max: voucher terminology / explanations in next draft round 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, 19 Dec 2016 22:18:41 -0000 VGFrZSBhIGxvb2sgYXQgdGhlIHByZSB2NSB2ZXJzaW9uIEnigJl2ZSBwb3N0ZWQuIFNlY3Rpb24g Mi4yIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmc6DQpodHRwczovL2dpdGh1Yi5jb20vaWV0Zi1yb2xs L2FuaW1hLWJvb3RzdHJhcC9ibG9iL21hc3Rlci9kdGJvb3RzdHJhcC1hbmltYS1rZXlpbmZyYS0w NS50eHQNCg0KRG9lcyB0aGlzIGhlbHA/DQoNCi0gbWF4DQoNCjIuMi4gIFNlY3VyZSBJbXByaW50 aW5nIHVzaW5nIFZvdWNoZXJzDQoNCiAgIEEgdm91Y2hlciBpcyBhIGNyeXB0b2dyYXBoaWNhbGx5 IHByb3RlY3RlZCBzdGF0ZW1lbnQgdG8gdGhlIFBsZWRnZQ0KICAgZGV2aWNlIGluZGljYXRpbmcg YXV0aG9yaXppbmcgYSB6ZXJvLXRvdWNoIGltcHJpbnQgb24gdGhlIFJlZ2lzdHJhcg0KICAgZG9t YWluLiAgR2VuZXJpY2FsbHkgdGhlIHZvdWNoZXIgaW1wYXJ0cyB0aGUgZm9sbG93aW5nIGluZm9y bWF0aW9uIHRvDQogICB0aGUgUGxlZGdlOg0KDQogICBBc3NlcnRpb24gQmFzaXMgIEluZGljYXRl cyB0aGUgbWV0aG9kIHRoYXQgcHJvdGVjdHMgdGhlIGltcHJpbnQuDQogICAgICBUaGlzIG1pZ2h0 IGluY2x1ZGUgZGlzY3JldGUgb3duZXJzaGlwIHZlcmlmaWNhdGlvbiwgYXNzdXJlZA0KICAgICAg bG9nZ2luZyBvcGVyYXRpb24gb3IgcmVsaWFuY2Ugb24gUGxlZGdlIGVuZHBvaW50IGJlaGF2aW9y IHN1Y2ggYXMNCiAgICAgIHNlY3VyZSByb290IG9mIHRydXN0IG9mIG1lYXN1cmVtZW50LiAgT25s eSBzb21lIG1ldGhvZHMgYXJlDQogICAgICBub3JtYXRpdmVseSBkZWZpbmVkIGluIHRoaXMgZG9j dW1lbnQuICBPdGhlciBtZXRob2RzIGFyZSBsZWZ0IGZvcg0KICAgICAgZnV0dXJlIHdvcmsuDQoN CiAgIFJlZ2lzdHJhciBBdXRoZW50aWNhdGlvbiAgSW5kaWNhdGVzIGhvdyB0aGUgUGxlZGdlIGNh biBhdXRoZW50aWNhdGUNCiAgICAgIHRoZSBSZWdpc3RyYXIuICBUaGlzIG1pZ2h0IGluY2x1ZGUg YW4gaW5kaWNhdGlvbiBvZiB0aGUgUEtJWCB0cnVzdA0KICAgICAgYW5jaG9yIHVzZWQgYnkgdGhl IFJlZ2lzdHJhciwgb3IgYW4gaW5kaWNhdGlvbiBvZiBzaGFyZWQgUEtJWA0KICAgICAgdHJ1c3Qg YW5jaG9yIGFuZCBhZGRpdGlvbmFsIENOLUlEIG9yIEROUy1JRCBpbmZvcm1hdGlvbiB0bw0KICAg ICAgY29tcGxldGUgYXV0aGVudGljYXRpb24uICBTeW1ldHJpYyBrZXkgb3Igb3RoZXIgbWV0aG9k cyBhcmUgbGVmdA0KICAgICAgZm9yIGZ1dHVyZSB3b3JrLg0KDQogICBBbnRpLVJlcGxheSBQcm90 ZWN0aW9ucyAgVGltZSBvciBub25jZSBiYXNlZCBpbmZvcm1hdGlvbiBjb25zdHJhaW4NCiAgICAg IHZvdWNoZXJzIHRvIHRpbWUgcGVyaW9kcyBvciBib290c3RyYXAgYXR0ZW1wdHMuDQoNCiAgIEEg bnVtYmVyIG9mIGJvb3N0cmFwcGluZyBzY2VuYXJpb3MgY2FuIGJlIG1ldCB1c2luZyBkaWZmZXJp bmcNCiAgIGNvbWJpbmF0aW9ucyBvZiB0aGlzIGluZm9ybWF0aW9uLiAgQWxsIHNjZW5hcmlvcyBh ZGRyZXNzIHRoZSBwcmltYXJ5DQogICB0aHJlYXQgb2YgYSBNaVRNIFJlZ2lzdHJhciBnYWluaW5n IGNvbnRyb2wgb3ZlciB0aGUgUGxlZGdlIGRldmljZS4NCiAgIFRoZSBwcmltYXJ5IHZvdWNoZXIg Y29tYmluYXRpb25zIGFyZSByZWZlcnJlZCB0byB3aXRoaW4gdGhpcyBkb2N1bWVudA0KICAgYnkg bmFtZToNCg0KICAgICAgICAgICAgICAgIHxBc3NlcnRpb24gICB8UmVnaXN0cmFyIElEICAgIHxQ bGVkZ2UgSUQgfCBWYWxpZGl0eSAgICB8DQogICAgICAgICAgICAgICAgfExvZy18VmVyaS0gIHxU cnVzdCAgfENOLUlEIG9yfHNlcmlhbCAgICB8IFJUQyB8IE5vbmNlIHwNCiAgICAgICAgICAgICAg ICB8IGdlZHwgIGZpZWQgfEFuY2hvciB8RE5TLUlEICB8bnVtYmVyICAgIHwgICAgIHwgICAgICAg fA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS18DQogICBBdWRpdCAgICAgICAgfCAgWCB8ICAgICAgIHwgWCAgICAg fCAgICAgICAgfCBYICAgICAgICB8ICAgICB8IFggICAgIHwNCiAgIC0tLS0tLS0tLS0tLS18LS0t LXwtLS0tLS0tfC0tLS0tLS18LS0tLS0tLS18LS0tLS0tLS0tLXwtLS0tLXwtLS0tLS0tfA0KICAg Tm9uY2VsZXNzICAgIHwgIFggfCAgICAgICB8IFggICAgIHwgICAgICAgIHwgWCAgICAgICAgfCAg ICAgfCAgICAgICB8DQogICBBdWRpdCAgICAgICAgfCAgICB8ICAgICAgIHwgICAgICAgfCAgICAg ICAgfCAgICAgICAgICB8ICAgICB8ICAgICAgIHwNCiAgIC0tLS0tLS0tLS0tLS18LS0tLXwtLS0t LS0tfC0tLS0tLS18LS0tLS0tLS18LS0tLS0tLS0tLXwtLS0tLXwtLS0tLS0tfA0KICAgT3duZXIg QXVkaXQgIHwgIFggfCAgIFggICB8IFggICAgIHwgICAgICAgIHwgWCAgICAgICAgfCAgICAgfCBY ICAgICB8DQogICAtLS0tLS0tLS0tLS0tfC0tLS18LS0tLS0tLXwtLS0tLS0tfC0tLS0tLS0tfC0t LS0tLS0tLS18LS0tLS18LS0tLS0tLXwNCiAgIE93bmVyIElEICAgICB8ICAgIHwgICBYICAgfCA/ ICAgICB8ICBYICAgICB8IFggICAgICAgIHwgWCAgIHwgICAgICAgfA0KICAgLS0tLS0tLS0tLS0t LXwtLS0tfC0tLS0tLS18LS0tLS0tLS0tLS0tLS0tLXwtLS0tLS0tLS0tfC0tLS0tLS0tLS0tLS18 DQogICBCZWFyZXJWb3VjaGVyfCAgWCB8ICAgICAgIHwgICB3aWxkY2FyZCAgICAgfCBYICAgICAg ICB8ID8gICAgICAgICAgIHwNCiAgIC0tLS0tLS0tLS0tLS18LS0tLXwtLS0tLS0tfC0tLS0tLS0t LS0tLS0tLS18LS0tLS0tLS0tLXwtLS0tLS0tLS0tLS0tfA0KICAgTWFzdGVyVm91Y2hlcnwgICAg fCAgICAgICB8ICAgd2lsZGNhcmQgICAgIHwgd2lsZGNhcmQgfCBYICAgfCAgICAgICB8DQogICAt LS0tLS0tLS0tLS0tfC0tLS0tLS0tLS0tLXwtLS0tLS0tLS0tLS0tLS0tfC0tLS0tLS0tLS18LS0t LS18LS0tLS0tLXwNCg0KDQoNCg0KUHJpdGlraW4sIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEp1 bmUgMjIsIDIwMTcgICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgICBCUmV3U0tJICAgICAgICAgICAgICAgICAgIERlY2VtYmVyIDIwMTYNCg0K DQogICBBdWRpdCBWb3VjaGVyICBBbiBBdWRpdCBWb3VjaGVyIGlzIG5hbWVkIGFmdGVyIHRoZSBs b2dnaW5nIGFzc2VydGlvbg0KICAgICAgbWVjaGFuaXNtcyB0aGF0IHRoZSBSZWdpc3RyYXIgdGhl biAiYXVkaXRzIiB0byBlbmZvcmNlIGxvY2FsDQogICAgICBwb2xpY3kuICBUaGUgUmVnaXN0cmFy IG1pdGlnYXRlcyBhIE1pVE0gUmVnaXN0cmFyIGJ5IGF1ZGl0aW5nIHRoYXQNCiAgICAgIGFuIHVu a25vd24gTWlUTSByZWdpc3RyYXIgZG9lcyBub3QgYXBwZWFyIGluIHRoZSBsb2cgZW50cmllcy4N CiAgICAgIFRoaXMgZG9lcyBub3QgZGlyZWN0IHByZXZlbnQgdGhlIE1pVE0gYnV0IHByb3ZpZGVz IGEgcmVzcG9uc2UNCiAgICAgIG1lY2hhbmlzbSB0aGF0IGVuc3VyZXMgdGhlIE1pVE0gaXMgdW5z dWNjZXNzZnVsLiAgVGhpcyBhZHZhbnRhZ2UNCiAgICAgIGlzIHRoYXQgYWN0dWFsIG93bmVyc2hp cCBrbm93bGVkZ2UgaXMgbm90IHJlcXVpcmVkIG9uIHRoZSBNQVNBDQogICAgICBzZXJ2aWNlLg0K DQogICBOb25jZWxlc3MgQXVkaXQgVm91Y2hlciAgQW4gQXVkaXQgVm91Y2hlciB3aXRob3V0IGEg dmFsaWRpdHkgcGVyaW9kDQogICAgICBzdGF0ZW1lbnQuICBGdW5kYW1lbnRhbGx5IHRoZSBzYW1l IGFzIGFuIEF1ZGl0IFZvdWNoZXIgZXhjZXB0IHRoYXQNCiAgICAgIGl0IGNhbiBiZSBpc3N1ZWQg aW4gYWR2YW5jZSB0byBzdXBwb3J0IG5ldHdvcmsgcGFydGlvbnMgb3IgdG8NCiAgICAgIHByb3Zp ZGUgYSBwZXJtYW5lbnQgdm91Y2hlciBmb3IgcmVtb3RlIGRlcGxveW1lbnRzLg0KDQogICBPd25l cnNoaXAgQXVkaXQgVm91Y2hlciAgQW4gQXVkaXQgVm91Y2hlciB3aGVyZSB0aGUgTUFTQSBzZXJ2 aWNlIGhhcw0KICAgICAgdmVyaWZpZWQgdGhlIFJlZ2lzdHJhciBhcyB0aGUgYXV0aG9yaXplZCBv d25lci4gIFRoZSBNQVNBIHNlcnZpY2UNCiAgICAgIG1pdGlnYXRlcyBhIE1pVE0gUmVnaXN0cmFy IGJ5IHJlZnVzaW5nIHRvIGdlbmVyYXRlIEF1ZGl0IFZvdWNoZXIncw0KICAgICAgZm9yIHVuYXV0 aG9yaXplZCBSZWdpc3RyYXJzLiAgVGhlIFJlZ2lzdHJhciB1c2VzIGF1ZGl0IHRlY2huaXF1ZXMN CiAgICAgIHRvIHN1cHBsaW1lbnQgdGhlIE1BU0EuICBUaGlzIHByb3ZpZGVzIGFuIGlkZWFsIHNo YXJpbmcgb2YgcG9saWN5DQogICAgICBkZWNpc2lvbnMgYW5kIGVuZm9yY2VtZW50IGJldHdlZW4g dGhlIHZlbmRvciBhbmQgdGhlIG93bmVyLg0KDQogICBPd25lcnNoaXAgSUQgVm91Y2hlciAgQW4g T3duZXJzaGlwIElEIFZvdWNoZXIgaXMgbmFtZWQgYWZ0ZXINCiAgICAgIGluY2x1c2lvbiBvZiB0 aGUgUGxlZGdlJ3MgQ04tSUQgb3IgRE5TLUlEIHdpdGhpbiB0aGUgdm91Y2hlci4gIEFuDQogICAg ICBleGFtcGxlIE93bmVyc2hpcCBWb3VjaGVyIGlzIGRlZmluZWQgaW4NCiAgICAgIFtJLUQuaWV0 Zi1uZXRjb25mLXplcm90b3VjaF0uICBUaGUgTUFTQSBzZXJ2aWNlIG1pdGlnYXRlcyBhIE1pVE0N CiAgICAgIFJlZ2lzdHJhciBieSBpZGVudGlmeWluZyB0aGUgc3BlY2lmaWMgUmVnaXN0cmFyIGF1 dGhvcml6ZWQgdG8gb3duDQogICAgICB0aGUgUGxlZGdlLg0KDQogICBCZWFyZXIgVm91Y2hlciAg QSBCZWFyZXIgVm91Y2hlciBpcyBuYW1lZCBhZnRlciB0aGUgaW5jbHVzaW9uIG9mIGENCiAgICAg IFJlZ2lzdHJhciBJRCB3aWxkY2FyZC4gIEJlY2F1c2UgdGhlIFJlZ2lzdHJhciBpcyBub3Qgc3Bl Y2lmaWNhbGx5DQogICAgICBpZGVudGlmaWVkIHRoaXMgdm91Y2hlciB0eXBlIG11c3QgYmUgdHJl YXRlZCBhcyBhIHNlY3JldCBhbmQNCiAgICAgIHByb3RlY3RlZCBmcm9tIGV4cG9zdXJlIGFzIGFu eSAnYmVhcmVyJyBvZiB0aGUgdm91Y2hlciBjYW4gY2xhaW0NCiAgICAgIHRoZSBQbGVkZ2UgZGV2 aWNlLiAgVGhlb3JldGljYWxseSAibm9uY2VkIiBhbmQgIm5vbmNlbGVzcyIgYmVhcmVyDQogICAg ICB2b3VjaGVzIGNhbiBleGlzdC4gIFB1Ymxpc2hpbmcgYSBub25jZWxlc3MgYmVhcmVyIHZvdWNo ZXINCiAgICAgIGVmZmVjdGl2ZWx5IHR1cm5zIHRoZSBzcGVjaWZpZWQgUGxlZGdlIGludG8gYSAi VE9GVSIgZGV2aWNlIHdpdGgNCiAgICAgIG1pbmltYWwgbWl0aWdhdGlvbiBhZ2FpbnN0IE1pVE0g UmVnaXN0cmFycy4NCg0KICAgTWFzdGVyIFZvdWNoZXIgIEEgTWFzdGVyIFZvdWNoZXIgaXMgbmFt ZWQgYWZ0ZXIgdGhlIGluY2x1c2lvbiBvZiBhDQogICAgICBQbGVkZ2UgSUQgd2lsZGNhcmQuICBC ZWNhdXNlIHRoZSBQbGVkZ2UgaXMgbm90IHNwZWNpZmljYWxseQ0KICAgICAgaWRlbnRpZmllZCBw dWJsaXNoaW5nIGEgbm9uY2VsZXNzIE1hc3RlciBWb3VjaGVyIHdvdWxkIHR1cm4gYWxsDQogICAg ICBQbGVkZ2VzIHRoYXQgdHJ1c3QgdGhlIE1BU0EgaW50byBUT0ZVIGRldmljZXMuICBUaGlzIHdv dWxkIGJlIGENCiAgICAgIHNpZ25pZmljYW50IHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gYXMgaXQg cHV0cyB0b28gbXVjaCBwb3dlciBpbg0KICAgICAgdGhlIGhhbmRzIG9mIHRoZSB2ZW5kb3IgTUFT QSBzZXJ2aWNlLiAgV2lsZGNhcmQgUGxlZGdlIElEcyBNVVNUDQogICAgICBOT1QgYmUgYWNjZXB0 ZWQuDQoNCiAgIFtbRUROT1RFOiBFeGFjdCBkZWZpbml0aW9ucyBvZiBBc3NlcnRpb24sIElEIGFu ZCBWYWxpZGl0eSBtZXRob2RzDQogICBjb21lIGZyb20gdGhlIHZvdWNoZXIgZG9jdW1lbnQuICBJ bmNsdWRlZCBhcmUgbm9ybWF0aXZlIHN0YXRlbWVudHMgb24NCiAgIGhvdyBSZWdpc3RyYXIgYW5k IFBsZWRnZSBvcGVyYXRlIG9uIHRoZXNlIGluZm9ybWF0aW9ucyBhZnRlcg0KICAgdmVyaWZ5aW5n IHRoZSB2b3VjaGVyXV0NCg0KDQo+IE9uIERlYyAxNywgMjAxNiwgYXQgMTI6NTYgUE0sIE1pY2hh ZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCj4gDQo+IA0KPiBU b2VybGVzcyBFY2tlcnQgPHR0ZUBjcy5mYXUuZGU+IHdyb3RlOg0KPj4gLSBJbmNsdWRpbmcgY2Vy dGlmaWNhdGUgaW4gdGhlIHZvdWNoZXIgYWxsb3dzIHRob3NlIHZvdWNoZXJzIHRvDQo+PiBsaWUg YXJvdW5kIGF0IGFuIG93bmVyIG11Y2ggbG9uZ2VyLiBUaGVpciB2YWxpZGl0eSBpcyBhcyBsb25n IGFzIHRoYXQNCj4+IG9mIHRoZSBpbmNsdWRlZCBDQSBjZXJ0aWZpY2F0ZSAoZWc6ID49IDEwIHll YXJzKS4gVGhlIHZhbGlkaXR5IG9mDQo+PiBhIHB1YmxpYyBrZXkgaXMgdHlwaWNhbGx5IG11Y2gg c2hvcnRlciAoZWc6IDw9IDEgeWVhcikuDQo+IA0KPiBBIGNlcnRpZmljYXRlIGlzIHZhbGlkIGFz IGxvbmcgYXMgdGhlIENBIHRoYXQgdm91Y2hlcyBmb3IgdGhlIEROIHJlbmV3cw0KPiB0aGUgY2Vy dGlmaWNhdGUuICBUaGV5IGtleXMgY2FuIGJlIHJlbmV3ZWQsIGFuZCBhbGdvcml0aG1zIGNhbiBl dmVuIGJlDQo+IHJlcGxhY2VkLiAgVGhhdCdzIHRoZSBwYXlvZmYgZnJvbSB0aGUgb3ZlcmhlYWQg b2YgdGhlIFBLSS4NCj4gDQo+ID0+IFRoaXMgaXMgd2hhdCB3ZSBuZWVkIHRvIGNhcHR1cmUgaW50 byB0aGUgZG9jdW1lbnQuDQo+IA0KPiBBIHB1YmxpYyBrZXkgaGFzIG5vIGV4cGlyeSBkYXRlLCBz aW5jZSBpdCBoYXMgbm8gZGF0ZSBhc3NvY2lhdGVkIHdpdGggaXQuDQo+IFdoZW4geW91IHNheSB0 aGF0IGEgcHVibGljIGtleSBpcyAidHlwaWNhbGx5IiBzaG9ydGVyLCB5b3UgYXJlIHJlYWxseQ0K PiBleHByZXNzaW5nIGEgZ29vZCBjcnlwdG8taHlnaWVuZSBzdWdnZXN0aW9uIHRvIHRoZSBvd25l ciBvZiB0aGUgcHVibGljLg0KPiANCj4gLS0NCj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVU RkBzYW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MNCj4gLT0gSVB2NiBJb1Qg Y29uc3VsdGluZyA9LQ0KPiANCj4gDQo+IA0KDQo= From nobody Sat Dec 31 14:23:13 2016 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 CA2EB12946F for ; Sat, 31 Dec 2016 14:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 WaWkfodU29LQ for ; Sat, 31 Dec 2016 14:23:09 -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 B21391295C1 for ; Sat, 31 Dec 2016 14:23:09 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 48D7B205A5 for ; Sat, 31 Dec 2016 17:41:58 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 81E4A638D5 for ; Sat, 31 Dec 2016 17:23:07 -0500 (EST) From: Michael Richardson To: anima-bootstrap 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] [Spasm] New Version Notification for draft-turner-est-extensions-07.txt (fwd) Sean Turner: Re: [Spasm] New Version Notification for draft-turner-est-extensions-07.txt 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: Sat, 31 Dec 2016 22:23:12 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain In case you were unaware of this: --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=246 Content-Description: forwarded message Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3::184] by obiwan.sandelman.ca with IMAP (fetchmail-6.3.26) for (single-drop); Fri, 30 Dec 2016 19:26:14 -0500 (EST) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus v2.4.16-Debian-2.4.16-4+deb7u2) with LMTPA; Fri, 30 Dec 2016 15:27:39 -0500 X-Sieve: CMU Sieve 2.4 Received: from colo19.roaringpenguin.com (unknown [IPv6:2604:1f80:1:478::19]) by tuna.sandelman.ca (Postfix) with ESMTPS id E473EE1A1 for ; Fri, 30 Dec 2016 15:27:39 -0500 (EST) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by colo19.roaringpenguin.com (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id uBUK8pks002744 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 30 Dec 2016 15:08:52 -0500 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 947131295F8; Fri, 30 Dec 2016 12:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1483128531; bh=z1h2ICSfJeJzq58aoAcL7xISi26BApXgNZyxcdV0uJ0=; h=From:In-Reply-To:Date:References:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=RH3h6Gu4L2VMJuRuj939Pdx96x/M3uoAg66ETCdNo8/wcHvSp6hEbcrnZIGKJq2KX hsMT8QPiTPJrqA25LNhSEv7NmAxx70sgf7mT/PTykXUfdfaGx7O5TAqM/Ieiw30vwl wu6w+699xl65G8Ccaw6vR7hZG0ZmMaFc+/rq456o= X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0D7129602 for ; Fri, 30 Dec 2016 12:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Score: 0.00 () [Hold at 5.10] HEADER_FROM_DIFFERENT_DOMAINS:0.001,SPF(pass:0),DKIM(pass:0) X-Spam-Level: X-Spam-Status: No, score=-2.701 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] 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 HS1R7uV4LmJp for ; Fri, 30 Dec 2016 12:08:49 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 CB4731295FE for ; Fri, 30 Dec 2016 12:08:48 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id h201so165616817qke.1 for ; Fri, 30 Dec 2016 12:08:48 -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 :content-transfer-encoding:message-id:references:to; bh=8hjeGwaR4iZ3/qkQkxfVy4r8CefEM0MsLJ51d6VF6IY=; b=RY7rgcs7F9I/FpxT7ZzjZIY39jC5uz7A+8IezTKo367IfE3Obpd3UEGZ1LkT4sMhWH KaMAG0rlRHB5GeoUmMMn6IZqnB02ordh2TgjXZ64dvddhDkz/H4ZbZyZDXhfv4v+DSG4 O3OJNC0+2AGu9sjm5EPZzMyzZhFikAl9rpo64= 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 :content-transfer-encoding:message-id:references:to; bh=8hjeGwaR4iZ3/qkQkxfVy4r8CefEM0MsLJ51d6VF6IY=; b=aOlP8K1nAQs9sw+gdzq9C0tKzJtMAIZUGVBQ0VtRZlQ6Xa+RmPH2RCghCQ1qdsDVrM DYZiJ7VxA7sP3XCoi8pW7Bsx1J6hAiStOAZAGMHVjT3gXgTJyCHT2ZD0RAG1lZnC/LZQ We+dtz/coppZpL5l1wmJBiPa/ojUiU1ayCYD1wFoUcWJLB/QS2pP0QdlNvEoQf3yTY/7 b2gyunKOuyE2kuCJhN07mVU4XNC8tmW+Nz4FOv25Ue4+R+J4d0iSq3UIGGJ2UVujMyWX BivNoKMYn7/HOegO8OsCnbYWj1Fn7tU0vlXj0NO6dg5WjZT5jntZUQO9tbMjIAEvjKTe 5JtA== X-Gm-Message-State: AIkVDXJsPdOG6Mwt4KI6RS4F5I4jl6EZErX+DGe141guwg+kdZAZb8pGkSXZNGEWGSDaCQ== X-Received: by 10.55.21.196 with SMTP id 65mr46756607qkv.230.1483128527839; Fri, 30 Dec 2016 12:08:47 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id k143sm8830979qke.37.2016.12.30.12.08.47 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 30 Dec 2016 12:08:47 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <148312836283.21869.11769344292871693674.idtracker@ietfa.amsl.com> Date: Fri, 30 Dec 2016 15:08:46 -0500 Message-Id: References: <148312836283.21869.11769344292871693674.idtracker@ietfa.amsl.com> To: SPASM X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Spasm] New Version Notification for draft-turner-est-extensions-07.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: spasm-bounces@ietf.org Sender: "Spasm" X-Bayes-Prob: 0.0001 (Score 0, tokens from: mcr, @@RPTN) X-CanIt-Geo: ip=4.31.198.44; country=US; region=California; city=Redwood City; latitude=37.4914; longitude=-122.2110; http://maps.google.com/maps?q=37.4914,-122.2110&z=6 X-CanItPRO-Stream: sandelman-ca:mcr (inherits from sandelman-ca:default,rp-01:default,base:default) X-Canit-Stats-ID: 0gSqk8Qzz - 451eb4cd4bf6 - 20161230 X-Antispam-Training-Forget: https://antispam.roaringpenguin.com/canit/b.php?i=0gSqk8Qzz&m=451eb4cd4bf6&t=20161230&c=f X-Antispam-Training-Nonspam: https://antispam.roaringpenguin.com/canit/b.php?i=0gSqk8Qzz&m=451eb4cd4bf6&t=20161230&c=n X-Antispam-Training-Phish: https://antispam.roaringpenguin.com/canit/b.php?i=0gSqk8Qzz&m=451eb4cd4bf6&t=20161230&c=p X-Antispam-Training-Spam: https://antispam.roaringpenguin.com/canit/b.php?i=0gSqk8Qzz&m=451eb4cd4bf6&t=20161230&c=s X-CanIt-Archive-Cluster: irqpXI7aJGyo4Ewta7qVH399FOg Received-SPF: pass (colo19.roaringpenguin.com: domain of spasm-bounces@ietf.org designates 4.31.198.44 as permitted sender) receiver=colo19.roaringpenguin.com; client-ip=4.31.198.44; envelope-from=; helo=mail.ietf.org; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) FYI - I went ahead and incorporated the comment I got in Seoul: Add JSON and use HTTP Accept headed to allow the client to indicate whether they support XML or JSON for the PAL. spt > On Dec 30, 2016, at 15:06, internet-drafts@ietf.org wrote: > > > A new version of I-D, draft-turner-est-extensions-07.txt > has been successfully submitted by Sean Turner and posted to the > IETF repository. > > Name: draft-turner-est-extensions > Revision: 07 > Title: EST Extensions > Document date: 2016-12-29 > Group: Individual Submission > Pages: 47 > URL: https://www.ietf.org/internet-drafts/draft-turner-est-extensions-07.txt > Status: https://datatracker.ietf.org/doc/draft-turner-est-extensions/ > Htmlized: https://tools.ietf.org/html/draft-turner-est-extensions-07 > Diff: https://www.ietf.org/rfcdiff?url2=draft-turner-est-extensions-07 > > Abstract: > The EST (Enrollment over Secure Transport) protocol defined a Well- > Known URI (Uniform Resource Identifier): /.well-known/est. EST also > defined several path components that clients use for PKI (Public Key > Infrastructure) services, namely certificate enrollment (e.g., > /simpleenroll). In some sense, the services provided by the path > components can be thought of as PKI management-related packages. > There are additional PKI-related packages a client might need as well > as other security-related packages, such as firmware, trust anchors, > and symmetric, asymmetric, and encrypted keys. This document also > specifies the PAL (Package Availability List), which is an XML > (Extensible Markup Language) file or JSON (Javascript Object > Notation) object that clients use to retrieve packages available and > authorized for them. This document extends the EST server path > components to provide these additional services. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlhoL8sACgkQgItw+93Q 3WXAkgf+OiQ11AkkYWLCv5tySJt2eW+4TKrChO3ZEJ6Xw9Btq0urv25ad9jNseRv baDEyfFh8XT3T6weQjvJJqNwttO3RK+c0pT1BIUxBGUPVbA19hJSPQi7r5lyDUNQ D59Z/xLHzF/WDu7Mnk1XaEZ4H+b/F0ss8h3GG7eDPii/fE/dIg78FQ3SMwO28tfp iYMBjFGkjB82+6Au3jJTszfyH1WOgFx8h24b51KQ4LMXhjcy4evx8Sl4AlYGWbbc e+h+boe2Thf4aqd7VIcr4QsxUf0lp3N0W/yPHo5pB7N1dF/3b+TxrTFl9h4YeWQr bCu8BMb+u2Qu5VTPx6f2TLXcIX3e0A== =iYGU -----END PGP SIGNATURE----- --==-=-=--