From nobody Sun Jul 2 10:38:38 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C821B12EC63 for ; Sun, 2 Jul 2017 10:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, HTML_OBFUSCATE_05_10=0.26, 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 1hNmKhxU2c_t for ; Sun, 2 Jul 2017 10:38:34 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 59437129789 for ; Sun, 2 Jul 2017 10:38:34 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id x187so10612893oig.3 for ; Sun, 02 Jul 2017 10:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=d8iZrV1a+piPVvp4Td9hE73KFWG36N1E/s+vBREI12o=; b=SrdTdCiDBxjEgFuhn+HiiHcJ5OiEfrEO9l4HemJAighgYIjhVP1f7IEUsJs0kORpvc eCDvF9LQUAv12moFoFuEy3qn0g1mimMgKBz+s6OqIv1UsNFjy3t85pSSpD+yXrgLQmzS 9VODOOcrWWjkn1AelC/R0O6q3a6SUmgWWajPqA8rRnEbSqHejBGRLjgakn+MgqJJ2PYY 10sjNYU0iOVHbbmvBGWYvIYyDNvEr8YKmvKE2WQCPMzhI1uNC2sjtr2ZXG3wzKd5E3Zm hMqEtuEctg+NRyXLlzd/Wj8+VSY1dGFlzhR/NRtmXMSUdmMj8O9H0tq8swnSsPfmfFl5 5Quw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=d8iZrV1a+piPVvp4Td9hE73KFWG36N1E/s+vBREI12o=; b=FGV5ICwX6ooZ8xtIyp7HfN5CDYR+911I53/f8w8iBP5US6BlMTFNsldvbHCQH32MWy J8dap70aTw29FWwhQzBlqkGmdC8kQ1NlGIsoXdzzpWeETP7q4+4DDHCtwlvxtnvI/Olo M90DEjWquFREK+GJq5iWhRrKbbEJhnygKyFESU/CyFlUZPt1k0f3l/hX7VTMpzH+0Ds4 zcJ9DbSza7HDvO4WephvJm2u60IAIizuE2r3D3mlfaH6H/UFRZ2R0FMxh/7POl7I6N/L h91elnV7lEANpcAkQRDyZmx4PZkvup6lRWwOC9M/UjROPJ4eKqJO3hl3nsZk1OfLujx+ 5iSA== X-Gm-Message-State: AIVw111syb0ptSOKpeGE54/hCdp5/ytT2dlSUN6e3OvBVWqAhtqD+yIK VeXFg3KNcI3NVNUfNLhQGnSkTTMVxI/3nTI= X-Received: by 10.202.58.136 with SMTP id h130mr8393435oia.159.1499017113548; Sun, 02 Jul 2017 10:38:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.237.18 with HTTP; Sun, 2 Jul 2017 10:38:33 -0700 (PDT) In-Reply-To: <149901692647.17218.7654069086751009731.idtracker@ietfa.amsl.com> References: <149901692647.17218.7654069086751009731.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Sun, 2 Jul 2017 20:38:33 +0300 Message-ID: To: "saag@ietf.org" Content-Type: multipart/alternative; boundary="001a113ce05a90bd1c0553591ecd" Archived-At: Subject: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 17:38:37 -0000 --001a113ce05a90bd1c0553591ecd Content-Type: text/plain; charset="UTF-8" Hello, I've uploaded a document decribing a proposal of changing the certificate validation process for application needs. It provides more flexible way of trust limitations than CRL does. ---------- Forwarded message ---------- From: Date: Sun, Jul 2, 2017 at 8:35 PM Subject: New Version Notification for draft-belyavskiy-certificate- limitation-policy-02.txt To: Dmitry Belyavskiy A new version of I-D, draft-belyavskiy-certificate-limitation-policy-02.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-belyavskiy-certificate-limitation-policy Revision: 02 Title: Certificate Limitation Policy Document date: 2017-07-01 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-belyavskiy-certif icate-limitation-policy-02.txt Status: https://datatracker.ietf.org/doc/draft-belyavskiy-certifica te-limitation-policy/ Htmlized: https://tools.ietf.org/html/draft-belyavskiy-certificate-li mitation-policy-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-belyavskiy-cert ificate-limitation-policy-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-certific ate-limitation-policy-02 Abstract: The document provides a specification of the application-level trust model. Being provided at the application level, the limitations of trust can be distributed separately using cryptographically protected format instead of hardcoding the checks into the application itself. The IETF Secretariat -- SY, Dmitry Belyavsky --001a113ce05a90bd1c0553591ecd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I've uploaded a document dec= ribing=C2=A0a proposal of changing the cer= tificate validation process for application needs.=C2=A0
<= span style=3D"font-size:12.8px">It provides more flexible way of trust limi= tations than CRL does.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: S= un, Jul 2, 2017 at 8:35 PM
Subject: New Version Notification for draft-b= elyavskiy-certificate-limitation-policy-02.txt
To: Dmitry Belyavski= y <beldmit@gmail.= com>



A new version of I-D, draft-belyavskiy-certificate-limitation-policy-0= 2.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-belyavskiy-certificate-= limitation-policy
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate Limitation Policy
Document date:=C2=A0 2017-07-01
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draf= ts/draft-belyavskiy-certificate-limitation-policy-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-belyavskiy= -certificate-limitation-policy/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-belyavskiy-certificate-= limitation-policy-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-bel= yavskiy-certificate-limitation-policy-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddra= ft-belyavskiy-certificate-limitation-policy-02

Abstract:
=C2=A0 =C2=A0The document provides a specification of the application-level= trust
=C2=A0 =C2=A0model.=C2=A0 Being provided at the application level, the limi= tations of
=C2=A0 =C2=A0trust can be distributed separately using cryptographically pr= otected
=C2=A0 =C2=A0format instead of hardcoding the checks into the application i= tself.



The IETF Secretariat




--
SY, Dmitry Belyavsky
--001a113ce05a90bd1c0553591ecd-- From nobody Mon Jul 3 12:49:57 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A39C126BFD; Mon, 3 Jul 2017 12:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 XqhBA409Ac2E; Mon, 3 Jul 2017 12:49:47 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 563A2131768; Mon, 3 Jul 2017 12:49:47 -0700 (PDT) Received: from [192.168.88.73] (unknown [88.135.141.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A2EC6827C2; Mon, 3 Jul 2017 21:51:02 +0200 (CEST) Cc: iarce@quarkslab.com, "secdir@ietf.org" , "privsec-program@iab.org" From: Fernando Gont To: "saag@ietf.org" Message-ID: Date: Mon, 3 Jul 2017 22:49:59 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] Predictable Numeric Identifiers -- progress? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 19:49:50 -0000 Folks, We have published a revision of a number of I-Ds we had published on the topic of "security/privacy properties of numeric identifiers", in the hopes of helping improving the security and privacy properties of the numeric identifiers employed in IETF protocols. The main revised I-D is available at: Based on feedback received from SAAG, we have also published the same content, but split into three stand-alone document (which might be easier to digest and progress): * History of flawed numeric identifiers: * Generation of numeric identifiers: * A proposed update to RFC3552, wrt numeric identifiers: The first version of these I-Ds were published one year ago now, and to some extent were stalled waiting for progress on rfc3552bis. As expected, rfc3552bis will take time to be published, but the IETF is still published documents with no proper requirements regarding numeric I-Ds... which is not a good thing. At this point we'd like to receive feedback on the topic (whether for the main/big document, or for the split I-Ds), and also would like to make progress on these document. Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jul 3 13:57:55 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3482C127B57 for ; Mon, 3 Jul 2017 13:57:54 -0700 (PDT) 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, FREEMAIL_FROM=0.001, 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 (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 NGoZijogj8IG for ; Mon, 3 Jul 2017 13:57:52 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c: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 7E8D8126B72 for ; Mon, 3 Jul 2017 13:57:52 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id w126so178544252wme.0 for ; Mon, 03 Jul 2017 13:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xOoX4Vu8D8/BYYOK09G/3FZOAQbmui1WTu8dWA65EsU=; b=MnusBwLxovty6C6bD2kW5EgCsz2aGOrL5tN8OsmmNuku4/drz1YYUsHutQIS8jG4E4 D7tukWin32WrY76s0fHY/0Mk7NOU8bO+HWyYiMm4tkIVlo0rQKM8nmbUrvAQs3OCu3vF DZ5l+uXFdkskfuxmHtWZFvcXhVYwx6RQR0o6HQr5IKxhFSoqhBTNFd7Wf6FNAB3kYZ50 K/RQ4Hx9eklb2yRdiCz4sbUNr9z9iSGP6cAH8XoNOMTDSL00XqA/eLXiCD8gfHOX/g17 gJuFC9BhBhIb+ulMURTs6F9BA5N6Frjbu2CZmIgk0ZNlhywf2mdX4Oh4iIhSLbC4B68y fDAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xOoX4Vu8D8/BYYOK09G/3FZOAQbmui1WTu8dWA65EsU=; b=Zr+zmVO6vaYvteSMEfAkj6mv0s5bFF+wkM+OXsKSqoJA5CbfT196xmSPSJCUEjxVr5 yh55/nVqbP9NIJzwJ0ACm4qX0P7aGDPIWMSeIWYdyYRMuHl4aH0DAkviLqeFtNXWZnNX DuG0DpcNv9kX+ukWoX0O22h1+vYY+KEF3RWDyquyK+w1TYIJqV+CVFJRpflqip071DpY 1BwykDfQy0/M4jSQalF8FPHGlVjId8fYhpqCustAKZo6SGxvHUYuG9v/HpGuFFFeYooV pJm249xIHp8P5+EcnxviiHzVV2kAaGXMNTzRrPXLAygD8y+NPbeheLTm1aj38jZvcRYe 0HyQ== X-Gm-Message-State: AKS2vOxlt+Nc0oRfFMlXq0LaPzmfMFp+R5qmRxMjM1MfzBYBAq0xlf4m 5EAbrddTTL87DQ== X-Received: by 10.80.216.5 with SMTP id o5mr13092826edj.178.1499115471122; Mon, 03 Jul 2017 13:57:51 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id e37sm3005822edb.65.2017.07.03.13.57.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jul 2017 13:57:49 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_98AB0F29-BCA8-4855-B720-214D18BDE808"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 3 Jul 2017 23:57:47 +0300 In-Reply-To: Cc: Security Area Advisory Group To: Fernando Gont References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [saag] [secdir] Predictable Numeric Identifiers -- progress? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:57:54 -0000 --Apple-Mail=_98AB0F29-BCA8-4855-B720-214D18BDE808 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 3 Jul 2017, at 22:49, Fernando Gont wrote: > The first version of these I-Ds were published one year ago now, and = to > some extent were stalled waiting for progress on rfc3552bis. As > expected, rfc3552bis will take time to be published, but the IETF is > still published documents with no proper requirements regarding = numeric > I-Ds... which is not a good thing. I think at this point it is very clear that there is no energy behind = the rfc3552bis effort, and that it is not going forward. Whatever the merits and disposition of the predictable numeric = identifier work, it should not be stalled waiting for rfc3552bis. Hope this helps Yoav --Apple-Mail=_98AB0F29-BCA8-4855-B720-214D18BDE808 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZWq/LAAoJELhJCxUKWMyZiN8H/1xMSbhobvpMjeKKOmu184Y1 baFGkl91oBEvLH+EotelGthaczl7MDAKt03CUh7pjKWz4Bi82NQKnVBpk31wo4l0 2vPgg7PvYZNJKI/iFC/SpW8p2+I7pBae65oyGNXGVdqAOGZnFUe7ewOSTqzysWFc mMdPgBCHU6wA3uW6DnpTFlkmZjyb3StTLIqzWcFdoKC+mt5u7dK5oiZoeEXv0ZLJ vrxGXwldP2QSIRv7ObvqaZiWjdrY80jzFGUshaSkZGXjleETPD16S0Y4n6r5tVa1 AEtV1yJw04ysYXATEB9/OgPD40DXhUtassC9CQjnSOYTTmyBSx6RYfdBhvvgYXg= =rsVI -----END PGP SIGNATURE----- --Apple-Mail=_98AB0F29-BCA8-4855-B720-214D18BDE808-- From nobody Mon Jul 3 15:07:42 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1921315E6 for ; Mon, 3 Jul 2017 15:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 cIayWk13hWqi for ; Mon, 3 Jul 2017 15:07:40 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D75313154D for ; Mon, 3 Jul 2017 15:07:35 -0700 (PDT) Received: from [192.168.88.73] (unknown [88.135.141.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E265F827B9; Tue, 4 Jul 2017 00:08:51 +0200 (CEST) To: Yoav Nir Cc: Security Area Advisory Group References: From: Fernando Gont Message-ID: <59d830a5-db39-46df-b7af-ffd321f5255f@si6networks.com> Date: Tue, 4 Jul 2017 00:57:17 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [secdir] Predictable Numeric Identifiers -- progress? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 22:07:41 -0000 On 07/03/2017 11:57 PM, Yoav Nir wrote: > >> On 3 Jul 2017, at 22:49, Fernando Gont wrote: > > > >> The first version of these I-Ds were published one year ago now, and to >> some extent were stalled waiting for progress on rfc3552bis. As >> expected, rfc3552bis will take time to be published, but the IETF is >> still published documents with no proper requirements regarding numeric >> I-Ds... which is not a good thing. > > I think at this point it is very clear that there is no energy behind the rfc3552bis effort, and that it is not going forward. > > Whatever the merits and disposition of the predictable numeric identifier work, it should not be stalled waiting for rfc3552bis. Agreed. > Hope this helps Indeed! Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jul 4 00:51:53 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A93C13152F for ; Tue, 4 Jul 2017 00:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 JErh7EvwZbpN for ; Tue, 4 Jul 2017 00:51:50 -0700 (PDT) Received: from smtp.mu.afrinic.net (smtp.afrinic.net [IPv6:2001:43f8:90:606::169]) (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 0F7B512785F for ; Tue, 4 Jul 2017 00:51:50 -0700 (PDT) Received: from [2001:43f8:90:250:f0ff:742f:f008:2e88] (port=41204) by smtp.mu.afrinic.net with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1dSIca-000C0F-9K for saag@ietf.org; Tue, 04 Jul 2017 07:51:44 +0000 To: saag@ietf.org References: <59d830a5-db39-46df-b7af-ffd321f5255f@si6networks.com> From: Loganaden Velvindron Message-ID: <99c5751c-28df-c8c1-d31d-e457dee6c3b5@afrinic.net> Date: Tue, 4 Jul 2017 11:51:52 +0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <59d830a5-db39-46df-b7af-ffd321f5255f@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [secdir] Predictable Numeric Identifiers -- progress? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 07:51:52 -0000 On 07/04/2017 01:57 AM, Fernando Gont wrote: > On 07/03/2017 11:57 PM, Yoav Nir wrote: >> >>> On 3 Jul 2017, at 22:49, Fernando Gont wrote: >> >> >> >>> The first version of these I-Ds were published one year ago now, and to >>> some extent were stalled waiting for progress on rfc3552bis. As >>> expected, rfc3552bis will take time to be published, but the IETF is >>> still published documents with no proper requirements regarding numeric >>> I-Ds... which is not a good thing. >> >> I think at this point it is very clear that there is no energy behind the rfc3552bis effort, and that it is not going forward. >> >> Whatever the merits and disposition of the predictable numeric identifier work, it should not be stalled waiting for rfc3552bis. > > Agreed. > > > >> Hope this helps > > Indeed! > > Thanks, > [Speaking for myself], What is there left to be done for RFC3552bis ? -- Join us for the AFRINIC-27 meeting in Lagos, Nigeria, 26November to 02 December 2017 From nobody Tue Jul 4 03:16:01 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82EA131DC1 for ; Tue, 4 Jul 2017 03:16:00 -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 G7PoOthHvcEo for ; Tue, 4 Jul 2017 03:15:59 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF43131DC2 for ; Tue, 4 Jul 2017 03:15:59 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id p21so164975348qke.3 for ; Tue, 04 Jul 2017 03:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=N6BMVU9b2oauNONYHEyZ2wll+08zDb3vXt4vzegQ/aM=; b=cWAjcH3r+A/UHW0r3WMVwjUjF+R3o+StOXG0I9TipnH79wjV4MzqFA33jXC6qpwLpR 4OWJ0b6Ap/IkF6GV+ZghGAV4ZifVRxkXh/sXzNyfES67lO9KdK1zLf7FjAFLPEWE03sp OX8DUruSsYiddzGbjvEpPy+IUSsIzgkNQMI5X0GUP6U/LJx+NsK8/AjgxGMRlpeLEPMd EW2rJnWYD51BZSLa0U/qWhIr7jM7rtfd4aIZwKOmyjMqSnqQIpTLD6XBTJ1bgFwbCOEX gVQgikK6NIUGGfhiMGbog9NzE7PM//ylBqr8lBLgNCAKol1HUQlxtZSIHr6iR9kYYgez M2qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=N6BMVU9b2oauNONYHEyZ2wll+08zDb3vXt4vzegQ/aM=; b=CjFv0QSRQZiKjBS5VCW93BDO0bQSF4jWtJEXngYmNpI/+cFw4WtdWVXpMI1U4ou74Q 6gfScR8t2Nt+EVW0DmFI+HfEbZxVsAKoPbD1SgXZ/zH8MVYECRCrlTVU9hhzkexwJzeD Q/AWOFRGXPsLHKSYd4hOWXl6y6Gn9cduu35QOSVms3MSmPK64ioU1AUOVTtINjPCkhJf v+GJERPi6aAI2fdUXcSgDTCdNgC2GndudpWwkcG2+eugkiZHzZ9aSNJ4Ma26Vw1Kh4lw eKxUzpKvBBLlLjRH7g97b6CQg0ImyytLwhWZJMxiPxiKEH7L8kwBKESL4MrVhVlv29Zd cAuw== X-Gm-Message-State: AIVw1114q+0/dinaXOvyCx6M9ueItDzeMCsU3Slm4Ha3MCUr1vgjX3NZ COZCNHLa8t4qNQ== X-Received: by 10.55.99.18 with SMTP id x18mr24825076qkb.187.1499163358295; Tue, 04 Jul 2017 03:15:58 -0700 (PDT) Received: from sio_centos_lt ([147.178.6.131]) by smtp.googlemail.com with ESMTPSA id x40sm15783121qta.66.2017.07.04.03.15.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 03:15:57 -0700 (PDT) Message-ID: <1499163354.4388.3.camel@gmail.com> From: Yoav Nir To: Loganaden Velvindron Cc: saag@ietf.org Date: Tue, 04 Jul 2017 13:15:54 +0300 In-Reply-To: <99c5751c-28df-c8c1-d31d-e457dee6c3b5@afrinic.net> References: <59d830a5-db39-46df-b7af-ffd321f5255f@si6networks.com> <99c5751c-28df-c8c1-d31d-e457dee6c3b5@afrinic.net> Organization: Dell-EMC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 (3.12.11-22.el7) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [secdir] Predictable Numeric Identifiers -- progress? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 10:16:01 -0000 On Tue, 2017-07-04 at 11:51 +0400, Loganaden Velvindron wrote: > > On 07/04/2017 01:57 AM, Fernando Gont wrote: > > On 07/03/2017 11:57 PM, Yoav Nir wrote: > >> > >>> On 3 Jul 2017, at 22:49, Fernando Gont wrote: > >> > >> > >> > >>> The first version of these I-Ds were published one year ago now, and to > >>> some extent were stalled waiting for progress on rfc3552bis. As > >>> expected, rfc3552bis will take time to be published, but the IETF is > >>> still published documents with no proper requirements regarding numeric > >>> I-Ds... which is not a good thing. > >> > >> I think at this point it is very clear that there is no energy behind the rfc3552bis effort, and that it is not going forward. > >> > >> Whatever the merits and disposition of the predictable numeric identifier work, it should not be stalled waiting for rfc3552bis. > > > > Agreed. > > > > > > > >> Hope this helps > > > > Indeed! > > > > Thanks, > > > > [Speaking for myself], > > What is there left to be done for RFC3552bis ? Pretty much everything. I've converted the old RFC 3552 into XML and updated some of the references to newer RFCs for things like IPsec, TLS and the like. We asked for community participation in making substantive changes, but got no emails at all, even after prodding a few times in SAAG meetings. So we figured there was not enough energy to do this. It's missing a modernization of the advice, probably a replacement or elimination of the examples, and perhaps some privacy / mass surveillance text. Yoav From nobody Wed Jul 5 04:52:51 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60056131E5C for ; Wed, 5 Jul 2017 04:52:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 mx-D0CyruRP0 for ; Wed, 5 Jul 2017 04:52:47 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 9608113296F for ; Wed, 5 Jul 2017 04:52:46 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1dSirJ-0003la-AX; Wed, 05 Jul 2017 13:52:41 +0200 Date: Wed, 5 Jul 2017 13:52:41 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: =?UTF-8?Q?Hern=C3=A2ni_Marques_=28p=E2=89=A1p_foundation=29?= cc: saag@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="37663318-567971419-1499250972=:9696" Content-ID: X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: Re: [saag] Documenting the pretty Easy privacy (pEp) protocols X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 11:52:50 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --37663318-567971419-1499250972=:9696 Content-Type: text/plain; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: Hernani, I read your draft (draft-birk-pep-00) have a couple of minor questions: Do you also intend to mitigate spam (using signed emails) or is this just a potential positive side effect? Furthermore, I was looking at a the recent publication on "Sliding right into disaster: Left-to-right sliding windows leak" , that reveals possible attacks on libraries using sliding windows such as Libgcrypt, which is used by GnuPG. Is the pEp approach also using affected libraries (as GPG does) and thus susceptible to such attacks? cheers, Bernie "Hernâni Marques (p≡p foundation)" -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology On Thu, 29 Jun 2017, Hernâni Marques (p≡p foundation) wrote: > Dear saag list members > > We, the p≡p (or pEp) foundation, have worked for some time on an > architecture and system to achieve "Privacy by Default". pEp stands for > pretty Easy privacy. Our goal is automatic message encryption (starting > with email) to bring not just good, but also easy message encryption for > the masses. That is, including people without any specialized computer > expertise -- which effectively are the vast majority in any general > population. :) > > There is a reference implementation to automatize key management, > message transport and including a peer-to-peer key synchronization > protocol to enable all sorts of users to securely engage in end-to-end > encryption and with their messages (including email) readable across > their different devices. > > We would be very happy if other people would engage in our efforts. We > are interested in having pEp not just as software, but also documented > as RFCs (for opportunistic encryption [RFC 7435], without vendor lock-in > and with a peer-to-peer approach by design) to achieve what we call > "Privacy by Default". > > To help the community to interoperate with the pEp implementions, we > believe engaging with the IETF and documenting our work in RFCs is the > way to go. We intend to document the general principles, message formats > and alike and would like to get input and comment from IETF participants > as we do that. > > We have published the most general Internet-Draft on pEp recently, > outling the basic ideas and principles: > > https://datatracker.ietf.org/doc/draft-birk-pep/ > > Besides that, we have already been working on further Internet-Drafts > (not yet submitted) that you can find (alongside with our reference > implementation and some libraries we depend on) on our repos site: > > https://letsencrypt.pep.foundation/dev/ > > In addition, you can find a white paper outlining the necessity, spirit > and concepts at: > > https://pep.foundation/docs/pEp-whitepaper.pdf > > What is your opinion regarding our IETF contribution? > We are looking forward to your opinions and feedback. > > Best regards > > Hernani (council member of p≡p foundation) > > PS: > ISOC just announed their support of this work with a Beyond the Net > Large Grant: > > > https://www.internetsociety.org/blog/community-grants-community-projects/2017/06/announcing-beyond-net-results-june-2017-grants > > -- > p≡p foundation council member (https://pep.foundation) > --37663318-567971419-1499250972=:9696-- From nobody Wed Jul 5 16:06:48 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF337129482 for ; Wed, 5 Jul 2017 16:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoxHVVXF8kvg for ; Wed, 5 Jul 2017 16:06:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 6ACFD120227 for ; Wed, 5 Jul 2017 16:06:44 -0700 (PDT) Received: from [192.168.91.199] ([5.148.12.26]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M4nM5-1dca4t11SP-00yygV for ; Thu, 06 Jul 2017 01:06:42 +0200 To: saag From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5fd97e02-1d04-703a-0324-3ca36f9e5db6@gmx.net> Date: Thu, 6 Jul 2017 01:06:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:HegllVAgIkYuXnEdN79o0H7w0i54ImEaxsSP16Fh2XEPko+E3DK 9v9OGeYJq/YEmnZ8dp5bvzfBSTI+G9hEjZvszB24jEVuzgoKuOK7XcPn4a0xuEsus5d4o0q UsmVYsaZAEIcbL3EE1ABut409qR0b5WLKeGKE6WtFJ+HBiAm1KKiNMXgEVacqazo1FQAWV/ eUGCkl07dOrhIzTsDsMmA== X-UI-Out-Filterresults: notjunk:1;V01:K0:BQZz4NH2LtA=:0RqbjeXVwGx9cUX5ooCYd0 kNGQiScu58+wrQz/utOBuQVNtEN6eimWpXJQtLKoanCQAOoXr6MeN9d3boduxIL2ADG71YbTe ve1UpwuFAD8VbNsXc0qiSBf/GhoBTF7LMZ734rtVWNLDXXIDKQ0NG68QVkQtxXkqVzHnJFCwd vnkDyZTjk7M+3WUOGFofJSDaruCtbywvtnIYZHSiCvfKy0o1Tcxd0B20Hu5gdS8/LNplIrVse xshJLCMLy1QsHSRdNJlwKEYt88iMcWuthopQnysvKOBRqntZmVRY75QsCe/feMtsOjOQEDYCZ jLnIeXDI9gq0CQIv86Q2x6J4EZ/kfqwXTBYfJ6ZstCuev0Bn5tDRia5TpF1tYwvUeQcINlGaQ l5fKBGrdUPGi8C+KtfwSUH/BE9RB5vdJlhCff+UexhlOCg2GpJnEVIA4gqCrbS4s7FieDu7+8 nEyHxIqhjorzNlioZCjyQ5kqxFnpTDqgKXF80iYYqF66s0B2ZQDayQwRzzUMYuSe59zW2g33k 0Fr3fexWyfhf51e1p8ATY+jSGO4kn7AX+sr6URm8/dbqkKC67nxz97GxGy2VX5JM8xEgTpSRr xX4s5ZeOLX7A+NaHWrsDJhwR+jeOxA84taWfrNcNMG9m/WxTLDQV8zg5DD3XQU1N1OlZNh7II J5ts0G420Oj6Y/juT7sd01J22usbdlF9peR0fEcTtgfl4qcgQkNUaSkv9s21+FWTxZNNPjQvH bsUrdcGQli2/COLErqidejLzWkcJQQRIO0k7ES5DON+qzxx4rn5ybW5cxWkfciAu0hz+yIt++ K1R/bVB Archived-At: Subject: [saag] Webinar on TrustZone X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 23:06:47 -0000 For those of you following the TEEP effort note that there will be a webinar about TrustZone next week. TrustZone is the ARM instantiation of a Trusted Execution Environment. We will also hear about the Intel versions next. Please indicate your preference at this Doodle poll: http://doodle.com/poll/vkiy5rt366rdq8cv Ciao Hannes From nobody Wed Jul 5 17:44:19 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9ECA131535 for ; Wed, 5 Jul 2017 17:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 empMgrrnE6gu for ; Wed, 5 Jul 2017 17:44:14 -0700 (PDT) Received: from dragon.pibit.ch (dragon.pibit.ch [94.231.81.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6211292F5 for ; Wed, 5 Jul 2017 17:44:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by dragon.pibit.ch (Postfix) with ESMTP id DBC5E171C05E; Thu, 6 Jul 2017 02:44:10 +0200 (CEST) Received: from dragon.pibit.ch ([127.0.0.1]) by localhost (dragon.pibit.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RF3N51-d5op; Thu, 6 Jul 2017 02:44:08 +0200 (CEST) Received: from [10.0.0.25] (77-58-54-109.dclient.hispeed.ch [77.58.54.109]) by dragon.pibit.ch (Postfix) with ESMTPSA id 1EAAF171C05B; Thu, 6 Jul 2017 02:44:08 +0200 (CEST) To: Bernie Hoeneisen References: Cc: saag@ietf.org From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgZm91bmRhdGlvbik=?= Openpgp: id=31733E0C598D3A1CF70955D6CB5738652768F7E9 Message-ID: <9d32c4c7-6f05-f662-b1ef-e1800d08211f@pep.foundation> Date: Thu, 6 Jul 2017 02:44:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VpoWbK1FtoLHMwcJ4PU4MWFh7Fv86DgBI" Archived-At: Subject: Re: [saag] Documenting the pretty Easy privacy (pEp) protocols X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 00:44:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VpoWbK1FtoLHMwcJ4PU4MWFh7Fv86DgBI Content-Type: multipart/mixed; boundary="cjN7vpj78c5UoiiXOxVCM3HhPoT2KBsSa"; protected-headers="v1" From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgZm91bmRhdGlvbik=?= To: Bernie Hoeneisen Cc: saag@ietf.org Message-ID: <9d32c4c7-6f05-f662-b1ef-e1800d08211f@pep.foundation> Subject: Re: [saag] Documenting the pretty Easy privacy (pEp) protocols References: In-Reply-To: --cjN7vpj78c5UoiiXOxVCM3HhPoT2KBsSa Content-Type: multipart/mixed; boundary="------------D63A76F9E78C9D73C9A8F539" This is a multi-part message in MIME format. --------------D63A76F9E78C9D73C9A8F539 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05.07.2017 13:52, Bernie Hoeneisen wrote: > Hernani, Hello Bernie > Do you also intend to mitigate spam (using signed emails) or is this > just a potential positive side effect? In the current implementation status, we don't have any special measures a priori against spam. However, two aspects 1) If users can more easily verify their contacts (using Trustwords and color signaling), some (little) spam, and more importantly -- (spear-)phising messages -- might be detected. The Privacy Status would turn red and read "under attack" if the underlying fingerprints wouldn't match. 2) Furtherly, if users would expect to receive at the very least encrypted messages (e.g., from a bank or from an online shop), this could raise their attention. An encypted message would show yellow or "secure" (in terms of being encrypted properly) at least, given the vendor would have the custuomer's pubkey and some system in place to automatically send encrypted messages. By the adapter concept of pEp this can easily be implemented, e.g. with the Python Adapter: https://letsencrypt.pep.foundation/dev/repos/pEpPythonAdapter/ > Furthermore, I was looking at a the recent publication on "Sliding righ= t > into disaster: Left-to-right sliding windows leak" > , that reveals possible attacks o= n > libraries using sliding windows such as Libgcrypt, which is used by Gnu= PG. >=20 > Is the pEp approach also using affected libraries (as GPG does) and thu= s > susceptible to such attacks? Yes, for all platforms despite iOS we use GnuPG, which means it's in principle affected. A new version of libgcrypt was released: https://lists.gnupg.org/pipermail/gnupg-announce/2017q2/000408.html What concerns the OpenPGP & email side, we require keys (available) to be at least RSA-2048 -- by default pEp generates RSA-4096 key pairs for each email account. However, as Werner Koch himself states, you're screwed anyways if you can run code on the target's machine: "Note that this side-channel attack requires that the attacker can run arbitrary software on the hardware where the private RSA key is used. Allowing execute access to a box with private keys should be considered as a game over condition, anyway." (cf. above link) Greets Hernani --=20 p=E2=89=A1p foundation council member (https://pep.foundation) --------------D63A76F9E78C9D73C9A8F539 Content-Type: application/pgp-keys; name="0x2768F7E9.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x2768F7E9.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFWozlEBEADAIFgjylzzPH7JKRJPbiEGoSsrSaCrbWLdy4sNGD4fS7GsuZ9f o/E9iYzC7WwGhN8rB4jsLv/ZfGVbAsmpypvZdReVs/BPidR8Vo1WMOK3lww1L6j8 7UV7TwUzG72u0zMXCUWMtX3+7kWZVlohXPCzDe7xyLu5tdfPWIAxDrI3h/+a4qAR ySVo8RwzILDwjbLF8at0w52oTRIWcr9CAus8ktRKBhc3MiUsSXHGgZLujUsXKAYg Vmh53uEVsjigeHZh6XPrzQPTnQ/VDcqNSRl4n+fQ2e/sZV7CQttcqb9zfj8P6Lyk jG3pe1AUSm9A0o75bi8PUluPWyH0wdt4D29xabFFyBANyYqKiLyZvnBqGSkqswnW 00QoYtMaEBh7nyuoUCa0bTMCRn8NaXRCnuINx+E2llqJqeQ0sMJ5WSQe4RbkWRsF PJOdiouLyHEZUpyQlMFesu/mN565eZsw3a7u9hxnoFgX0tF0hoONMRSAU1y3aZeb a+DvwXDQcSaHmBARQ2v8qWdql16Zhvf7KFo5Cris9jNknInzs2L6pHVZN8AY2ESO 2UXQJ+Fyy5BEHXS4LzEnWRPLYkAE5eVi+ZDcRMQeO2L3ZenqhcRRcQUAaRObho0L WzE+EE8ZvQxlA5hn/4/lHQLk8ZiEgenl+y/mtL8TeXB1HO4DrqahXvlu2QARAQAB tDxIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBmb3VuZGF0aW9uKSA8aGVybmFuaUBw ZXAuZm91bmRhdGlvbj6JAjwEEwEIACYCGyMHCwkIBwMCAQYVCAIJCgsEFgIDAQIe AQIXgAUCVyc6XQIZAQAKCRDLVzhlJ2j36ZLSD/4kywpRTvMvijdNM+3B8W4rLQSo 5BZUvkOEczZl0F4FzGgfaTLyGwj+hZtdatdxhk9jC5uYKaCAR+dP3wl8VjxmnjEc ir796Tw20sJuye4Qz+R9sghnJZM7NDZ7YmV2zpi4RXWY7CIYthpzUq1L3ujDlDNf KdKYd39PiGtyotx2lESw+LBlCddooPLSyPNp7fjWsRCgmg+2+yrVdl7TEO0QFcGs fLaNpjwVs2UXl+JzJql/CzV4Z9QxZAkhgpeObpiu4t/RJuPjmKS8lst7zJirhlwO rlXp5VkGyrmsPkXq/jFDkzNrAAX5uX34jTBgTveCRBr4MElVApq6sgbGfOOqvhU5 SZ2qWPw+t2yHiDbl9tE2Mac2UiodFPbFSlOnHd5KHh+ghWDyxCAkAcwxWexk4PTC WwGxqcvz95JcHXx6PAHDOkCB+zCHX65JOVpYxdb89xb1nBpqKphkXax7fyQbA8Pe Kf3ehp/x1gF94Cb6xevgUw1GeqZoURV65O9fzO0M+xSNjcyL+V1ps2IcZEOfKJtW nQYcfz0GZghSXl5KdKSAUlmt77nGuizsLL4qUaDIV0pvVAmBZmLbJ8vO9XSBDFnw 2mIrFZgUikcNpmZwKP7IwEcY6qz1BACG8xiS93j58qo9D9Ji2DqohIvsMTBFM2KQ p/VmXK9SPyVkNQa4vokCOQQTAQgAIwUCVyc6NQIbIwcLCQgHAwIBBhUIAgkKCwQW AgMBAh4BAheAAAoJEMtXOGUnaPfpJJAQALsvRmAU1dkCxdTMMiPtlzIbjWNwhoWg HP5XIjP/vbOyvu1Hjr1ur1C6WcR2GvlnFr6xlq5P62S2Z6GlCmTABlFdviMdrBIx UbDOywp6FR76w32uuQgq8Vsowdwv9lSJoUo0vR1f+1u0D+VkbAxIaUT3HUFY8pcm uqIpSm+TbvyMXCQ5/H6bNVK64hwifajbkEzqfjDFCcOLNwRLZn2dfJjNIFqC9bS/ Yuw4Rq1iAIWhPG47fu48dcvc2WGKlHHl18jEqNfnOvYM7EpxLtI+Kj1wYnxnmAGN 8LcHKhl9BWatHSV8jFlW0VPNHybL584sOEvlT7dFVsYccePMlljTdrxFSlxawyv6 WyiBIfiHnPxCCTB+FPIEBQhx7AdTnXbx1Ebyb7B9NMedAUKmZ3RCXdt5FsCE397F DHlomrzWs8Pt26dC0oHuLKIOkeMtYnbZoGvvkaNJ8XTkavguAswWQBPOumeVfJG4 u1nRNNRFbD6nGKYsm79KafkIpQKUlrIY6CnxrpuY2XGfqWLpJlWjK79L1EJRZMHP Z2y/6IOOT8truBwvHCu2R/bAXG9q5prHkGNegSc4CwPXbAXdKevrKYBGHrmtn4L8 dqJGlRehQUhZSHSBGckdr4Q7FerbAoEm6Xm2hOU4SKor3e9XAouU+COIRjk0cRTv OkTuySRdioqEtERIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBmb3VuZGF0aW9uKSA8 aGVybmFuaS5tYXJxdWVzQHBlcC5mb3VuZGF0aW9uPokCOQQTAQgAIwUCVyc6TgIb IwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEMtXOGUnaPfpn3gP/1V3n9Xt 8ha1juDe11jq0y0g1jQr1JMhZOoBOp6ttSpYCe9HCoJwVyvO1iGLex6XHSe8zrWv P38aihFoK7jQBc8xwYht1DcpTM7HFyXJ5/Pch8BNS4dsc8eozvm96pBPPmFDcm+i gG6dkO81/9oLqP8+Bagz8G58BktcFhvnjmLrkJftJAJQ4LyP5KlXgmUIxu9l//Wa 8AMkty+feHTIIbrQGDTM44a9N+uHwJ4OQjHNvvOprg4UZAhehLAzCk+gi68uHfhH 0AtKwZ/v/lag7OYle0KZelxFsHnVE+Dhe8HlyKqtCCOCvkWGtz5CBJDO/V/xUQXB SJxJd4Q4w9Gyf0mJ+Ljr8iu1fyaEor68u1ZGkaWbzQSF8Ycx7o6MWV1fAyFpUNUs 3M3vpmJpwrWQdNeCpQaczexnNcrzrYdFDLx8z7MMHEy86QSmjmaDSA+VgAHzV3oo 4R3Wu3wZKDwm4eFDBj8N5IBxMMfjfinnJb01WkAeRtAqK9KdXeWGs6eO6OBm8OSp ao2V/lw3IZIiCdowPaEFzw96DwmES/zTAis74mENrhnbvDrzFVFkNOUdf2Sn9x81 FJ7X13TEjENUhJJI87W+Ttk9eKUarkjtKdHfVpEMnO3Lg6NJiAvwpcYfarzfmorr wp1pscLZBEFGiAuHVgNzY1YwXMirPVnY7MnztDpIZXJuw6JuaSBNYXJxdWVzIChw 4omhcCBwcm9qZWN0KSA8aGVybmFuaUBwZXAtcHJvamVjdC5vcmc+iQI5BBMBCAAj BQJXJzp2AhsjBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQy1c4ZSdo9+kE ng//VY+l7xtGPe9q/FwmZ4ZyAPJn/hnwDjGhPeuEgsT4IgX220NB3UEXFAx8tCSu GY85862dC/AGQeGnzoM5u7rlTRFGuv92EtE2n/2Lfbte6yb5MRmzTgdR7cP1aNpv jCN+kEp4FfmHl1XPBFyX6WLEQG+ZnUDFIyHt2I7dehdN8UogJHdIfZ9y3IEhwPqA Yq4CRkf7P8Zkk2km2Jh8XjjgL5dsjCQKuNAnyktDpxUM3N/ifsOfrNulEIKlDA2y W3kcGL3CPj2ugwXgkSykeXaBzVoqbqRcPOO8/J7mVEOoLVjPwYq8f5NGWq2U0rbJ nRTHX4benaxw7rCi+6nbAEHTj0zbpx6FH8fezuzx86dWlFngqzQDOkiZWzc7ql/e b7pzHXuQ3QC1D+zzNn9TSTSDAjRFpgIuPWkAb/7/WyRfwqd0XzqinisA78I+E+0M OhjpQab/i9hoQRB2LfGaI+gBtaRX3aRotXNT1E5R1fq67r890Sjt3XTzADK9B6Rq pMa6T0LDe4zS2CYnDbUBjljsYGR5WZ7K03Qx2p9qfCFBTt2wvy2J0b526b0yCRIN c6TWDs/SlRqSs/ATaPSbOKfVUhXI8k0k2SV6FSBEPwIY0cUSRPSoANfv+IXjiW3R BbjNkvpbVtu98CDSbMBefAc3X8oVtrZ+rigZzd41QAhaOp20Qkhlcm7Dom5pIE1h cnF1ZXMgKHDiiaFwIHByb2plY3QpIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLXByb2pl Y3Qub3JnPokCOQQTAQgAIwUCVyc6hgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4B AheAAAoJEMtXOGUnaPfprZcQAL4wyuQHrMUb56gfvipTZNAV0YQopEeUtJlNPT3M DYTyD4AiTDmsDZwYaPI7O5m2bNSeLOmhAdqkUXhUOvEIWI0ABqkWVHL93nSEzFiI 5HYIbmh0UqpYf0myXQdWE1qjN6n1xnqk1mmZ7RSuIJ/9zwliiX5Qyr/RVfxOVU3i Bskn5iwGNs0N2anU6oA6EoD3VsuV650aIJN1c1e7bOd0QT4Z+FuYHPqsuZ/gnbD7 AKJIrpO/DoWMG/Ayzw3M746Ff6GKlQFaCmMja6pkfX8NqylbPY+lDlznu9LYXK3z /7gcNSZL3y53d1G5DvbK33sDXpHEpQOVbl6cAR6cgN0jyjh5Pg4VXKWTntAMlK9E /f+3HmH7EILxF6x9kl/TJet94igOvAU3v6Ktd3CPhc2XLvp6oik7NbE4hOFmkgJY q1pW9hffzh9NGzF5l10r9Z4j0bvxbbqXZCsn2/WvK4FhidZhyHgceM/kbH6jZdOE ZPw+Kxxlfsy4CeNDexas2OO1coz68lBiO6uD9+QgoV207hy4D5txTRF3YnR3TDdP bxiXnA8T/xNKOfMvWzfT4pmsuQdK9+DLmDPHDCZli3/5fLh2B2tb/r/SxLRNEaJj LEzbgPxxH53G5FOvjGR4isUbsZz0n2K2KZSxzVAEpkG1qmMhtGM4KZB2l+KTHBpx zElRtC9IZXJuYW5pIE1hcnF1ZXMgKHBFcCkgPGhlcm5hbmlAcGVwLXByb2plY3Qu b3JnPohGBBMRAgAGBQJV7/dAAAoJEHuDbkH3q5zl2OgAn12XbKVf0usg/exDv8tO xOzPTr8eAJ9b4QFCS/Bayw5zE3Fy650owknfJIkCHAQQAQIABgUCVfCW0wAKCRA9 g02NGPgJNGo+D/0ew5kut7hDw8dADIPpHaaSHfCu+7TskdQxUsbrg/4wvmiQ5lZv FBDtbqvtBHXVQ1Oj2xtPRRdlL5wuiBqf6hpnR8dQclggnALakVi8D+c38AKQFFBp APTraa6bCRawSS74+nOyrSpR/hUsYXmDyOvQCBxKpwS7Qi/Ob/JpfVZpLwD+297Z +ILNFixbYlYuA7V8z+ErQdkhSpkgtBoeB20gbw/FmqyQKvtM0ul43mINJpNzYP4y vU4YsDCNClGOYWLLPFLcnvVowmhRmMO7rM0eF6FfhLOGhbb31H8akl2Op2C7EiMv 2D8DGiZtV5QtVt9r/PCdl9LLEnw1kjULA50yCD0F4eXFLPLU1S6APqKFtSv9esSI NLjo0q1b4S5ekmUEqhBMRHvREPwGmsWjodp7pe1QPNPqb7prNAOwBxyKveXWIbL0 TaYbPhBQ4az7cUsWmlW9Bgn08zu9Jl9t9SdoEp6BV8qk7y6VmimMLYe2pST5dZjw eb7+u4Sfnfttxlt6kwu+hyz/c1RX9VdvgkzaJ+8i+pWvHyijmiStQTiHtJEcKbzh gHcEDfOkvFMGmNpHlVuB8skUnb9HeGheb6QZ2mRmCwZlKQQIMDYHE6xOIw8RJBHi IhvXOr73mXcORAsBvEAkGKQRldjtuQpb2dWEaL8oz3p4TA6vI/8y4qj7mYkCHAQQ AQgABgUCVe/3TgAKCRBLSiQj0EHGPcmQD/9ngwa9R8nsM0CTCMioJEbWJ4INnaDN D8uvnPzRT+vyUkTJzM+RCvVOoGgrmCFeqOeCQhdf20ExsANsqtv9XQEyDDI7PvnA nprJLSYozfpYscPe7N2MSwTBiPz70t03L5j6YfJhooCok921U0+xCNUl3LXzfIkX TxMC0z77VxSqEiHiPgQH4owqnDuEhRPte/ZtzvMgCRIk8L8+9UZazl8hF4r9XPP+ h8EFVJW0MB2ANICvmHcspiVd6QJdPTYHZIwZ2LMrb5Dt1QwyNkTDKvoImgR6qiaR 06GDyMhis6l8seu6GuAtOZGh2RGsGGPDPozcTi1kdytFmGC0W2J+bMoYeEMiAH4I p4o4KvLwvEIhU1RTMWg3Qo172w1Y2FLQSQLar5kVvjHfAdpgAeZMliPl7+ydziDF +EYP2p4d6kw6aPZNoB7uD1mhdgxts0lBuU3iRQwhOQTcrrJj/2DtUPdoFGoR5OTV Drmb1lodw5WWzI8FtTZ7C6ZyGPjj+V7COTSHGP4R7YLXKrPFK+5AjxzozK+cIgvY SZol8ZfAusxzz5mHXeTZqpHkQNdfCCHWCJ7og2W5baprUgkQn2O9AqEMSLQW9hpM GbzKIVh6ZFl6n2is/dZubS5aCH9+bNJqEi8Vd/pMsW9MMEeteGKc1WoGtDFFDM0Y ocgvF1CsSfGfMIkCOQQTAQgAIwUCVajOUQIbIwcLCQgHAwIBBhUIAgkKCwQWAgMB Ah4BAheAAAoJEMtXOGUnaPfpw2sP/3YEftsFv83sPLBclsA5HFNRr4FsXzbRv9F7 grDsqnvecgD8ItwUJ0G/Z/0uqXCPKecnq6mNhRZiX+AtNkGiMle6xcWI2kacAi/L 61GPyXWohsy7d42ej+FK2/lyKScTg979XBAXGJCCfyGoaVU0Rt9zlHyOOB3091YC 4gSYkMJ2i7jsdp7lqqvTwM6oPnEQkS75XliTDKesvYdrK87MTcF5tlBNVq0ycGmp GDOY5+d5HvkaJyhfUeJcknvMPIcObsH674vyhTejXabQg2uUhiWyOFEz4T2Xw72X dvtXhB8eIGNJOrGP8HqG0fhejoyXV7m2n0X9taYB+VqFrRnT9WeoStaMHzLhEAvO gLIXGe5bDPVkE0fV6SASvClAATtgsrunsYIuhQ5qHmcAxofCr0D4CA4YDhnRQbdb RaEKrHPFKkdtw9W8D2HO8X0xq6FmykYNuKI9k7w5oPgzuGnftBX/8VpKEaSAOaIX 4q4MrelsbyaJ8Ujx4fUFaGHQW2s1rmmJf8BnEEntyDSi3Tq7JABSeA0O5/JUJS9a 4rSMvvssdtYSSAtBD0N8yZTtdjdhaFffPbpv0PKmuNbjX1Fs0NOJDPWKwrSohXDW qr36ott5ap3/3wf/5upgKNR8AKoqjCF0hmPS2L3S+LNnqlZY8eomhf9YA1gSN49y R+2hAje7iQI8BBMBCAAmAhsjBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AFAlZf iokCGQEACgkQy1c4ZSdo9+lrTg/9FOyKWzceXttk0a3cnUpop7AQkQC9FfE9QQzF OW4VHk1ZKTlH7V1QrOrzU5fadd8C71oHbf75fVTlmNtcl9OE0fnx0T6G+FKvTyJV +W9LIRbsNe8+q7eRRtf/HsjQdblEIqkdUlAhVRgCjBI6K/reMYVoz5FxSGoIMjfx ds1K3kQICxS+uu+zRm6ff8VuWHMSESC34IxlIvfBf3vbPYnUPhu4Cn0UTxH3pmHm k+teJ1uFWiX98HAxDpv0ZobKNa9imcSCKhYTqdm89XBXND01bUd44w3RCmSqgzEQ oRi0Jj+ieg4XSn98lOItIBPE2pi92NskdSJr7C5++0fO9xrzURZjqGiEPmiegW+O MvnI6X9O2SBzXYU7GBiqpprWsa/y0WKRJ8O+kEVzGUI1BngeqvZ52QHGN9v5Wnho 0gvAWgiAmDVn6n3yfcnI+SBJHmvy+Im6TI8aNSX4G9xQjVukM/iWyjsNzAyxjtdk buOBiKAOADDqTC39HwsGoHXuKIzEZMGTFx7vA1yutogtg8MfUsqX18Ilt8p6v+dt JJY14MzF9fyVIfVr83Fc0IPuv3f59+7VQPY4AO9rUN+bcjggdKY9peLGizcT1msW ew4byIIjU39EfCx1ojfYkDFmV6fQOMOLWT62RgIiyORRKI0Ma2LnrHUqPDU6kWM7 8skVH+e0Pkhlcm5hbmkgTWFycXVlcyAocEVwIENvdW5jaWwpIDxoZXJuYW5pLm1h cnF1ZXNAcGVwLmZvdW5kYXRpb24+iQI5BBMBCAAjBQJWX4p+AhsjBwsJCAcDAgEG FQgCCQoLBBYCAwECHgECF4AACgkQy1c4ZSdo9+lsdw/9Ea0y2n0Indyhw8RaC7u/ Lu+OV5a03ATiWuV16vyYFXiJaVTCildscXCRpSRHrT84zk4eYf6ysRuzlXZUcg00 9nF6lajuzDm6E66ZJXkoInGpwEcGMx5odUeSKxcaZ5IQveEWyJahLbHf4FgQts2r 8BsChkoSEvhxojBhHQT5FYxdYNcKnrNj63UZw+xwTbg/79PWOjB141OEwNOT4rgg XSZ67w8O1JtMtMGYAgI2KiHIxUPruEudiJI8DvXUakX9LJRTpJnqSacgkC/ahL8m 5//7ePriUO2FR6ZeDkGp5z6g59+liruJhOcmbjpr7wAo6hVzdkpLT8qu4uuoaWM/ kRayEKfhlUj0SCcG751ucTE+yH9HMRBDUV/8fhVuoLsEHnq49/J/cVx7qr1y4EfD DaN8zW8ILe4vcZwGgbD0lI5r6tey2YyvwVEKDEe1vIiarbRsHa+6haX885SAyooI fdqKDcn6NGM12AVAPOIe2+2Q7GZV6AACD+j7GWX/jiNaV4HwJ2/SsNBFPw2/lDow sHnhFdvwEROynRlGG3FbHMGJ5HrNhQJWWZDPF40hDpuJpQRUuc5uzOzQUptag9m5 gfxCQNQXCtlIpIJ3CdlJJjPzndIHktV6/eo2xiAn24b2yBeiBnKjET6OE5iswAd4 DO3BjAKTBYYmqD2OMC+QCzS5Ag0EVajOUQEQALy+1UBEbXWX5iE1YezJ1qHy2DtT +0JUHiEMbY2iGO/cV4qXOwC5+w6ASp2Udoy52iHznW6AcktoQF/bf8JCxXGGISJM I0tS+1b61NuKW+vkXDiSgYn5X5V+mjqS4fFmTMoqo5ig4jqIunmEuwLlJxkP30s8 tUeGMRzcWSF5MvSKqQu0yXqg7N4MhEzMt4M4dV+I59HyoORJ805VBOFhr8jCtlg4 ug0HrySlLqRp20hhKL8lBUA5opyQkMNSbA+I0S5gFq9sZz31lLVC7sYm6ckap6FB ziAwcfnTfnFL4YFfTH4CIdkDFElCZ9318/cSnqbbhilRzvXh8aZfZl5wGntS6cIM JYbbKKGwdsPTkA5IR5yEVH1RbvD/m1d4cu5jqGfTeeRNMIngVirIa7W1Z49x/tTK ykUM6/mheqnzEqbbJsXLrnKN6Y+eu6mJLQgQhj/HNfk09j/wtgo1aRQgL/UVZDVT cuP0MuG9tTeZ39nt6dFaI3+IsTa4QhnDcO1dJ+eYsuCJmVY3CtuZ5Sh3GcNGk6sX +eeEMkfZ0jN9uwIWqhva5dqvetoO0VMfQyZiAauNxB0cjo2Cpl+xv+vQHEqPfFcY dY3QCay5Alsn3ttd6Ht+S2IB/BukcO9N+EmYT1HgJkS1c4UR6x512b0NTGRC6yMF AGSshsx3z9DInGvRABEBAAGJAh8EGAEIAAkFAlWozlECGwwACgkQy1c4ZSdo9+kp hw//Sw7Ji9eTyfJHdzRXNa1cA335dY1QYKq9/6eGhSjcyRGz4bHyHUDt5G5dmKwm aYrPGS3Hr2H1+Z3w9BD5X/V1ZVgsKYYVM18N0CsnarJdcugdwC1difyMzo2NJGz6 btuFey6ZiMZo6EQKgsH/0sLChHSLM5sjBgdmWswkWh7L8oNrFv/p091FVj6rFeda /e7g3xK2NjPSk3+oX5aLgcCrUSeWJCZflyEL6NEf3EOAahzzoqUfN9D6aTjZWPSm TVTO21t8s86XeSPuYBVGGODyIkCXWJxkm2WXY5AoPLYJWmmm9TwOJE0FgM/nTj04 cBNW91q8tCCaCx//2dGfW+EdAMew/G8aa2cJgbF7iJs5IWpMRUxujMM7rWJdxXjA h6Y3FiVc5UtYO87HmthC953QiJntDTa/72Oi7HrGw/wUtSRm2S9G/jdpXZ7WBaPD 0R4/QcXS9590nMfFahWfQs6cdAOtLBJzCL6JMX4sHqaycwxErzd0jvtohCGJW0Ks c8GjTxWtmgBpCVzkTidkWgXICzd7EKE36z5Ir6jvN7NLe4qbPQF+uDWmxQqAK92/ Iwt/NBALQ2oWAiHN5j8v2/ObJDuZH5Q4DGzzVmXYAeKjVMyH9Upsutnu8iYrvghK yC1RKKPPjqzJvcZkDO24NIw8RM1VxPH/3UxXFg+hWD+7KMw=3D =3DaXrV -----END PGP PUBLIC KEY BLOCK----- --------------D63A76F9E78C9D73C9A8F539-- --cjN7vpj78c5UoiiXOxVCM3HhPoT2KBsSa-- --VpoWbK1FtoLHMwcJ4PU4MWFh7Fv86DgBI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEMXM+DFmNOhz3CVXWy1c4ZSdo9+kFAlldh9YACgkQy1c4ZSdo 9+nruQ//ahxLg5GboqM3JOOiyHGK60GvSd0LM/lEKO8EM94iq9sJJrBg9P//ECrJ Aa3L3cXhuVm6o1Otk9XoFjRudcpkbVbFi0C4LyeWZ9z4gu9ZeUAwZShMLnp/tib7 xWCSst/5Uq3EneBFmR7R+IsMOwDOCgI33I/v+GPSKCa5rVBxMnz5dSNeXPlo6TzU QXy7XRZ1ZuQ3L1RfqD/h9ZwZnYMjjdG6kOfpQKR5FqMn3EICuW9YXCXi4J38gIyz Xzym4WoCi8+15GwB/c4T/QUaI9RF+hYt0mmDeU7qUwwxAY0UaDUQHl1cqXxSfEoa 9PFAzRu7vYmGWTPeP01qv/telbqxBMM/rTn/EfNWw9i2AgvGT/m8GfhJs092IyoL 5TmDI5ggyN8+mVilE/2DA2DdsiuQTJ+49W31mO5Qimz4XKeQlj6XoeTEScIM4pIR gFEw2Lsd/2Ve3TVU/Cg90KJs3X0vtY59P1loW73auo7PglbMlwe9hVS02eS6z7sW J6U31bFn+uCGc+SOoQVWZWi1UCkccQEilwMtbnJeNwm2DkyH/NeiScncogX/fMEE Y/ABlGWRD1KZKWejByF2B7Fyk2VB/JXcL2t4quYEFkbS1phs2sElzLwjT27Jy3jM 1Dy8O0rLkAbcHXMQ8cA278ZADC7xnyKpzfLHsIFh95waPqZ3sy8= =K687 -----END PGP SIGNATURE----- --VpoWbK1FtoLHMwcJ4PU4MWFh7Fv86DgBI-- From nobody Thu Jul 6 08:08:37 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CD313168C for ; Thu, 6 Jul 2017 08:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 cGuVGj6N2t8K for ; Thu, 6 Jul 2017 08:08:32 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 2D6E51315F9 for ; Thu, 6 Jul 2017 08:08:32 -0700 (PDT) X-AuditID: c1b4fb25-5efff70000001eeb-32-595e526e064c Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2D.D9.07915.E625E595; Thu, 6 Jul 2017 17:08:30 +0200 (CEST) Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.352.0; Thu, 6 Jul 2017 17:08:29 +0200 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 3A5774F724 for ; Thu, 6 Jul 2017 18:12:58 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id CCE3D4E6D8 for ; Thu, 6 Jul 2017 18:12:57 +0300 (EEST) References: <149911220825.22857.6798854749521543392.idtracker@ietfa.amsl.com> To: "saag@ietf.org" From: Mohit Sethi X-Forwarded-Message-Id: <149911220825.22857.6798854749521543392.idtracker@ietfa.amsl.com> Message-ID: <2ca02a15-e029-d6bc-a6e4-a4b279116c58@ericsson.com> Date: Thu, 6 Jul 2017 18:08:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149911220825.22857.6798854749521543392.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------0624A932011297D7EC3A83A7" Content-Language: en-US X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7lm5eUFykwe+vwhZT+juZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0Tx/KVvBB/2KKcsbmBsYt6p2MXJwSAiYSJx8Id7FyMkhJHCE UWL6j9QuRi4gezujxLs1D5kgEscYJS6ezINIbGWUmPXzHxtIQljAS2Lf82dQRb4S6+4uYgax RQSUJZb/ec4OYrMJ6El0njsOFpcQiJTYc38OWC+vgL1Ea1MLWJxFQEViZ981sDmiAhESu64f YIWoEZQ4OfMJC4jNKeAncWblT7CZzAJhEmdOL2KDsMUlbj2ZzwQxX03i6rlNzBD3qEts7TjA OIFReBaSUbOQtM9C0g5hW0jMnH+eEcKWl9j+dg4zhK0h0TpnLjuy+AJG9lWMosWpxUm56UbG eqlFmcnFxfl5enmpJZsYgbFycMtv1R2Ml984HmIU4GBU4uGdbRcXKcSaWFZcmXuIUYKDWUmE d6skUIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv474LEUIC6YklqdmpqQWpRTBZJg5OqQbGCQ6J a+3Mjp63+yYtstd2Yqy+/vraDoUzk+w/mr5aXepSHdL68KLdtsnahzr4jL/VTVSePvVNfuOj A4djzNezz1BsZHCYMXu5zN9nDCe6axYrTjc46st8Z6mxRseEqweTp4dHX8xdtuFBwqqnX12W Cm+dfMazkmPmCe0L6gH9F5RnPlzd5nBkgRJLcUaioRZzUXEiAHSSeSORAgAA Archived-At: Subject: [saag] Fwd: New Version Notification for draft-mattsson-eap-tls13-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 15:08:35 -0000 --------------0624A932011297D7EC3A83A7 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Dear all, We have submitted a new draft on EAP authentication with TLS 1.3. While much work remains to be done, a very early version of the draft can be found here: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00 We thought this would be of interest to the SAAG community. Comments and feedback are welcome as always. --Mohit -------- Forwarded Message -------- Subject: New Version Notification for draft-mattsson-eap-tls13-00.txt Date: Mon, 03 Jul 2017 13:03:28 -0700 From: internet-drafts@ietf.org To: Mohit Sethi , John Mattsson A new version of I-D, draft-mattsson-eap-tls13-00.txt has been successfully submitted by Mohit Sethi and posted to the IETF repository. Name: draft-mattsson-eap-tls13 Revision: 00 Title: The EAP-TLS Authentication Protocol Document date: 2017-07-03 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-mattsson-eap-tls13-00.txt Status: https://datatracker.ietf.org/doc/draft-mattsson-eap-tls13/ Htmlized: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-mattsson-eap-tls13-00 Abstract: Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. Transport Layer Security (TLS) provides mutual authentication, integrity-protected cipher suite negotiation, and key exchange between two endpoints. This document specifies an EAP authentication method to provide support for certificate-based mutual authentication and key derivation using the version 1.3 of the TLS protocol. This document obsoletes RFC5216. 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 --------------0624A932011297D7EC3A83A7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit

Dear all,

We have submitted a new draft on EAP authentication with TLS 1.3. While much work remains to be done, a very early version of the draft can be found here: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00

We thought this would be of interest to the SAAG community. Comments and feedback are welcome as always.

--Mohit

-------- Forwarded Message --------
Subject: New Version Notification for draft-mattsson-eap-tls13-00.txt
Date: Mon, 03 Jul 2017 13:03:28 -0700
From: internet-drafts@ietf.org
To: Mohit Sethi <mohit@piuha.net>, John Mattsson <john.mattsson@ericsson.com> 


A new version of I-D, draft-mattsson-eap-tls13-00.txt
has been successfully submitted by Mohit Sethi and posted to the
IETF repository.

Name:		draft-mattsson-eap-tls13
Revision:	00
Title:		The EAP-TLS Authentication Protocol
Document date:	2017-07-03
Group:		Individual Submission
Pages:		14
URL:            https://www.ietf.org/internet-drafts/draft-mattsson-eap-tls13-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mattsson-eap-tls13/
Htmlized:       https://tools.ietf.org/html/draft-mattsson-eap-tls13-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mattsson-eap-tls13-00


Abstract:
   Extensible Authentication Protocol (EAP) provides support for
   multiple authentication methods.  Transport Layer Security (TLS)
   provides mutual authentication, integrity-protected cipher suite
   negotiation, and key exchange between two endpoints.  This document
   specifies an EAP authentication method to provide support for
   certificate-based mutual authentication and key derivation using the
   version 1.3 of the TLS protocol.  This document obsoletes RFC5216.

                                                                                  


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
--------------0624A932011297D7EC3A83A7-- From nobody Mon Jul 10 00:52:06 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3751C13166A; Mon, 10 Jul 2017 00:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 A6rcqlDZDD0g; Mon, 10 Jul 2017 00:52:01 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 3C7CF1275AB; Mon, 10 Jul 2017 00:52:00 -0700 (PDT) X-AuditID: c1b4fb3a-803ff70000001b2f-73-5963321e0186 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F0.4C.06959.E1233695; Mon, 10 Jul 2017 09:51:58 +0200 (CEST) Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.352.0; Mon, 10 Jul 2017 09:51:58 +0200 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 859E24E9FC; Mon, 10 Jul 2017 10:56:31 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 0BA354E6D8; Mon, 10 Jul 2017 10:56:30 +0300 (EEST) From: Mohit Sethi To: CC: "saag@ietf.org" , "tuomas.aura@aalto.fi" Message-ID: <55ef9e9a-465c-ea7d-65dd-fad8d92aca84@ericsson.com> Date: Mon, 10 Jul 2017 10:51:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A2AB96361112A9ECE637ECBF" Content-Language: en-US X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2K7tK6cUXKkweFjGha/2j8wWkzp72Sy eDNxI7sDs8fx14tZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfHy6kSmgq+WFT9WL2BsYLyi0sXI ySEhYCJxZuYLti5GLg4hgSOMEktetDBDODsYJZ5OWMsC4WxilPi94QIrhLOQUWLzzJvsIP1s AnoSneeOA7VwcAgL6Et86pMFCYsISEhsW3mMGcRmFgiRWHV/Blg5r4C9xOnFq5lAbBYBVYl1 k5axgtiiAhESfW8vQ9UISpyc+YQFojdM4v73DWwQtrjErSfzmSDOVpO4em4T2HwhAXWJrR0H GCcwCs5C0j4LSfssJO0QtoXEzPnnGSFseYntb+cwQ9gaEq1z5rLDxJu3zmZewMi+ilG0OLW4 ODfdyEgvtSgzubg4P08vL7VkEyMwOg5u+W21g/Hgc8dDjAIcjEo8vLzyyZFCrIllxZW5hxgl OJiVRHgnqAOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8zrsuxAhJJCeWJKanZpakFoEk2Xi4JRq YHSS29PjlKL06PjHI7uuPmk4GHcjyK06+1wU7/5HyhEfT5k3VWyYtD9H/vOSbfMPxbhu3xea rZm6ln2S+cR7rCbcF/cnPt0nUedd8O+USn3fl933Fd/Fal78cfN1f51R6dHk3y33K60sHvf8 sRZVvTr/lWqBXE36Jv7ua6/9HPWvcOt9278jI1GJpTgj0VCLuag4EQCdV9aLigIAAA== Archived-At: Subject: [saag] Secure IoT bootstrapping with EAP-NOOB X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 07:52:04 -0000 --------------A2AB96361112A9ECE637ECBF Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Dear all We will be working on the EAP-NOOB protocol during the hackahton. We look forward to your contributions. If you are interested in IoT bootstrapping security, please drop by to test the demo and give us feedback. * Champion(s) o Mohit Sethi (mohit.m.sethi@ericsson.com) o Shiva Prasad TP o Tuomas Aura (tuomas.aura@aalto.fi) o Raghavendra Mudugodu * Project(s) o Implementing EAP-NOOB with open source wpa_supplicant and hostapd: https://tools.ietf.org/html/draft-aura-eap-noob-02 + EAP-NOOB is an EAP method where the authentication is based on a user-assisted out-of-band (OOB) channel between the server and peer. + It is intended as a generic bootstrapping solution for Internet-of-Things devices which have no pre-configured authentication credentials and which are not yet registered on the authentication server. Consider devices you just bought or borrowed. o Working code on github: https://github.com/tuomaura/eap-noob o During the hackathon we plan to work on the following: + Various bug fixes + Testing improved cryptoagility and error handling version -02 + Fuzz testing + Testing the code with new kinds of IoT devices and OOB channels such as audio + User experience in real deployment + Try it out sessions + We are happy to have your contribution. It could be simple feedback on some missing features or more detailed protocol improvements. * Specifications o https://tools.ietf.org/html/draft-aura-eap-noob-02 * Implementation o https://github.com/tuomaura/eap-noob --------------A2AB96361112A9ECE637ECBF Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Dear all

We will be working on the EAP-NOOB protocol during the hackahton. We look forward to your contributions. If you are interested in IoT bootstrapping security, please drop by to test the demo and give us feedback.  

  • Champion(s)
  • Project(s)
    • Implementing EAP-NOOB with open source wpa_supplicant and hostapd: https://tools.ietf.org/html/draft-aura-eap-noob-02
      • EAP-NOOB is an EAP method where the authentication is based on a user-assisted out-of-band (OOB) channel between the server and peer.
      • It is intended as a generic bootstrapping solution for Internet-of-Things devices which have no pre-configured authentication credentials and which are not yet registered on the authentication server. Consider devices you just bought or borrowed.
    • Working code on github: https://github.com/tuomaura/eap-noob
    • During the hackathon we plan to work on the following:
      • Various bug fixes
      • Testing improved cryptoagility and error handling version -02
      • Fuzz testing
      • Testing the code with new kinds of IoT devices and OOB channels such as audio
      • User experience in real deployment
      • Try it out sessions
      • We are happy to have your contribution. It could be simple feedback on some missing features or more detailed protocol improvements.
  • Specifications
  • Implementation
--------------A2AB96361112A9ECE637ECBF-- From nobody Mon Jul 10 01:54:11 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7D8131683 for ; Mon, 10 Jul 2017 01:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 vzSmCgpKz4uP for ; Mon, 10 Jul 2017 01:54:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 9D3C512EBFA for ; Mon, 10 Jul 2017 01:54:07 -0700 (PDT) Received: from [192.168.91.199] ([80.92.121.224]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LeRKD-1e2W133bTx-00q6oa for ; Mon, 10 Jul 2017 10:54:05 +0200 From: Hannes Tschofenig To: saag References: <5fd97e02-1d04-703a-0324-3ca36f9e5db6@gmx.net> Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <33e41131-f7d2-7dac-de72-9d880b4c4d74@gmx.net> Date: Mon, 10 Jul 2017 10:54:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <5fd97e02-1d04-703a-0324-3ca36f9e5db6@gmx.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:ne9rrW0XPJjpl/mGdO/D5xFJwI7Vb20xa7q1zrgEkLA3Oqeulu/ EXD9deUcPzmApDZ2aVMmvCZM8ZNTEfkIjFXu3miRbGIqRb804PiQi2SgHPq+KHHIIqP2MsX S/GxKG8bNCDgZIzdW+8ZoHGCNbvbJi/6T8qNa+ld4kjlw0qS/9sXje2pHHZuEpAKWaUheof I0/Kb3q9UYZ6HNTjrHiDw== X-UI-Out-Filterresults: notjunk:1;V01:K0:l/uYgotx+x8=:12Ah5CA4FoJ7TSmX9BJGXE yKBXtJjnGB9XdUPyam8l2MS6mdwzk1SYZy3u8CQIL2jlRu+UcNDUi6+TevEeP6sW0+FSYK97F g7z+fZX7cl4EUVuyvXrWyiv8kdNzhWMEuNKS2DCyS5yLCrvEbUuuTL8keMa/0ru3mjZm8LsZm RsQaonqDRdJNes93VxfpnDve5C7Zko8TkBlHmEeb/iz75qyko1WW/gZfgB2ayGUiTEKLvE0xh c4H0IwhtA2cxvxJlFaUgo00HMDsc3iJgviICz85zeM4FLxaNuKMcyhOfHwp+TfB1gsVoZLVuZ ea0ZCcGJVwCO6AQJkww5Z/f5DztxCh/JNr2eI0+ZUdYwrpWIMxLBlqNin73kscLRnFhmCNhN9 2gwNpAsYZnPnKbItZfeN7I5eEzFtfvKx+AGT084n/FGhOQR3iW2X3bhKIlEE9I5abHdOH/Xx+ rucvX5AD/1NaRKLkqG7zZGndrWEu74uWMc45HJO2OiolohTSZUxlBpgNmBhUIX1DrV3pYnRnC I7/HSx49pe0akxtooQHXLgC1cCFQ8nOAtvrSk3Bm056VdoH117tTP7Y/BF+4ga1F4pmZTQUmx lUHlaXF7YqO4KSylwGphYL7sREMMnqSxptHqdimgru61FlhCjiHgdiJw/YywmhLbCftdgRAeF LJNPrbyCFKKFKEQ9Tblh599rPg8qBUaeTdXEDjf1TT89aG2wbOHOfYNVOrWorW8pPvoxvMv44 gktYxIY0awVXkTMqbFwT2fidEvfhtm8ONYKxqiEp4OcSYr8Oupy+3HdsCgTPeAKTjU6T5eiGb 2EJZ4W3 Archived-At: Subject: [saag] Webinar on TrustZone -- Today X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 08:54:10 -0000 Here are the details for the webinar today: Date: 10 July Time: 5pm CEST = 11am EDT Link: https://arm-onsite.webex.com/arm-onsite/j.php?MTID=md9a1ee42a5b96bb14095bfc2300fa48c Meeting number (access code): 804 392 554 Meeting password: Bj62y7Qd Join by phone +1-408-792-6300 Call-in toll number (US/Canada) +1-877-668-4490 Call-in toll-free number (US/Canada) Global call-in numbers https://arm-onsite.webex.com/arm-onsite/globalcallin.php?serviceType=MC&ED=585835812&tollFree=1 Toll-free calling restrictions https://www.webex.com/pdf/tollfree_restrictions.pdf The conference bridge details have also been posted to the TEEP list. On 07/06/2017 01:06 AM, Hannes Tschofenig wrote: > For those of you following the TEEP effort note that there will be a > webinar about TrustZone next week. TrustZone is the ARM instantiation of > a Trusted Execution Environment. We will also hear about the Intel > versions next. > > Please indicate your preference at this Doodle poll: > http://doodle.com/poll/vkiy5rt366rdq8cv > > Ciao > Hannes > From nobody Mon Jul 10 07:20:53 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289A212F3D6 for ; Mon, 10 Jul 2017 07:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie 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 7xjm5N_LEC-S for ; Mon, 10 Jul 2017 07:20:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C41131448 for ; Mon, 10 Jul 2017 07:20:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 48D41BE6F; Mon, 10 Jul 2017 15:20:48 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urbBS6fddaSp; Mon, 10 Jul 2017 15:20:48 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 81410BE5F; Mon, 10 Jul 2017 15:20:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499696447; bh=sIBSG18ye5XiDjnhrY1ed7mdHX4sP91ywyfI0tHio3A=; h=Subject:To:References:From:Date:In-Reply-To:From; b=KDZh6pLMPemnbLWlI1lpibN5jEGZOBgtdxoIeqQqHzD04fWBcm+81ONC4YwYeM29F owcP/1o9BGMyZvJ4Px39XRiUiCPSUcIVi6zcP95Ga+K2gL0qz+X9VgnP6is59B7uwl 8pCQsTeyZX2+pLlvQsgR1/bPH+WSET4wXyfg97Ig= To: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgZm91bmRhdGlvbik=?= , saag@ietf.org References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 10 Jul 2017 15:20:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lmOeLUc5gtlquHHUAwdxgkAxpWJEfxlIM" Archived-At: Subject: Re: [saag] Documenting the pretty Easy privacy (pEp) protocols X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 14:20:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lmOeLUc5gtlquHHUAwdxgkAxpWJEfxlIM Content-Type: multipart/mixed; boundary="TDEGhkefcibDV41UTNLkJhnhsoK1mUAVX"; protected-headers="v1" From: Stephen Farrell To: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgZm91bmRhdGlvbik=?= , saag@ietf.org Message-ID: Subject: Re: [saag] Documenting the pretty Easy privacy (pEp) protocols References: In-Reply-To: --TDEGhkefcibDV41UTNLkJhnhsoK1mUAVX Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, First, I'd encourage you to keep on at this, it's good that we keep striving for ways to improve e2e interpersonal messaging security. That said, I think it might be useful to try enumerate the barriers to progress there and which of those are being tackled in this work. For example, both smime and pgp were designed at a time when we mostly had one desktop MUA and don't really support multiple MUAs and esp not web MUAs. I guess you are trying to address that for folks who buy into using plug-ins, but it's not clear to me if that can really scale without support for whatever solution one wants being available at the major mail service providers and in widely-used MUAs. (I wish it could scale, but fear it can't, at least not without support from others who control some of those MUAs and mail services.) Anyway, I think it'd be useful to have a discussion about that, i.e., being explicit about the set of barriers to e2e security and the extent to which the pEp scheme addresses some of those problems, which wasn't really that clear to me from your current draft. Cheers, S. On 29/06/17 04:44, Hern=C3=A2ni Marques (p=E2=89=A1p foundation) wrote: > Dear saag list members >=20 > We, the p=E2=89=A1p (or pEp) foundation, have worked for some time on a= n > architecture and system to achieve "Privacy by Default". pEp stands for= > pretty Easy privacy. Our goal is automatic message encryption (starting= > with email) to bring not just good, but also easy message encryption fo= r > the masses. That is, including people without any specialized computer > expertise -- which effectively are the vast majority in any general > population. :) >=20 > There is a reference implementation to automatize key management, > message transport and including a peer-to-peer key synchronization > protocol to enable all sorts of users to securely engage in end-to-end > encryption and with their messages (including email) readable across > their different devices. >=20 > We would be very happy if other people would engage in our efforts. We > are interested in having pEp not just as software, but also documented > as RFCs (for opportunistic encryption [RFC 7435], without vendor lock-i= n > and with a peer-to-peer approach by design) to achieve what we call > "Privacy by Default". >=20 > To help the community to interoperate with the pEp implementions, we > believe engaging with the IETF and documenting our work in RFCs is the > way to go. We intend to document the general principles, message format= s > and alike and would like to get input and comment from IETF participant= s > as we do that. >=20 > We have published the most general Internet-Draft on pEp recently, > outling the basic ideas and principles: >=20 > https://datatracker.ietf.org/doc/draft-birk-pep/ >=20 > Besides that, we have already been working on further Internet-Drafts > (not yet submitted) that you can find (alongside with our reference > implementation and some libraries we depend on) on our repos site: >=20 > https://letsencrypt.pep.foundation/dev/ >=20 > In addition, you can find a white paper outlining the necessity, spirit= > and concepts at: >=20 > https://pep.foundation/docs/pEp-whitepaper.pdf >=20 > What is your opinion regarding our IETF contribution? > We are looking forward to your opinions and feedback. >=20 > Best regards >=20 > Hernani (council member of p=E2=89=A1p foundation) >=20 > PS: > ISOC just announed their support of this work with a Beyond the Net > Large Grant: >=20 >=20 > https://www.internetsociety.org/blog/community-grants-community-project= s/2017/06/announcing-beyond-net-results-june-2017-grants >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --TDEGhkefcibDV41UTNLkJhnhsoK1mUAVX-- --lmOeLUc5gtlquHHUAwdxgkAxpWJEfxlIM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZY40/AAoJEC88hzaAX42iHuIIALbOEBdwsc+dj+uSdjJI/L1E aeQr7brlrO1N4lVRSS5aUdCWwEO2p42fnPEweF5OUp/b6a9ZBR9qqETrun1R1xDF wq6/FiDupg158lZZ+BKeVYvwoTeh9QmHMqK10v7DhwyAjWTtBGmO7Wc75q/O0gjM rB+K99aVab46gXCpl4m6b3aOWk3uuIvKgr8QhoJeop+2aZTTpKoKK2S4KqgpC2sg uQBDy85Kszn3NEsRDr6+IUiI1ZRjhnMdJn/keT737xjPtvca3Rtsn1AhHxK2Fydh Ug7dBQCt+Fb5oPALLMZKg/bIDGNGq9aQoQUlq9PzbPnWrj5oBSjL4yAGsF3fzHs= =qBbf -----END PGP SIGNATURE----- --lmOeLUc5gtlquHHUAwdxgkAxpWJEfxlIM-- From nobody Tue Jul 11 03:53:06 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C270129AA0 for ; Tue, 11 Jul 2017 03:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie 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 F1Zm2y3RfgYx for ; Tue, 11 Jul 2017 03:53:02 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC62126C0F for ; Tue, 11 Jul 2017 03:53:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 926FDBF4C for ; Tue, 11 Jul 2017 11:53:01 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG2uBP9YgiKx for ; Tue, 11 Jul 2017 11:53:01 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3C532BF48 for ; Tue, 11 Jul 2017 11:53:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499770381; bh=RsiToLZ6y8xKZcgO5wGp3ZZPKEfyJPrGet29r/iV210=; h=From:Subject:To:References:Date:In-Reply-To:From; b=rSlsIJcF8hFM+OKkyLhRMw4lrN1mhki07GdwEKCwMayPDz/zb3FtpqhjoszuPAQcs PO3dwfjy8RGtz/v6dce59s+LTWOxXGhlmLRU55TBzRJcphJaIQXLaNFvaseCUZcw2q oKFwLBQqrLDpKoJQ6H+whPPQn4TzfZkve9hzqwm4= From: Stephen Farrell To: "saag@ietf.org" References: <1777c26d-4e8c-453d-422e-b1f238105bd5@cs.tcd.ie> Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <3fb50656-14f2-193d-dca1-2e542197478d@cs.tcd.ie> Date: Tue, 11 Jul 2017 11:52:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1777c26d-4e8c-453d-422e-b1f238105bd5@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LxteSTrIR39Ec3Wp8HKI41Ts2kIq760oH" Archived-At: Subject: Re: [saag] [TLS] wiretapping draft - collecting rebuttal arguments X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 10:53:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LxteSTrIR39Ec3Wp8HKI41Ts2kIq760oH Content-Type: multipart/mixed; boundary="veur36RgxCtcOjkIrah1CSWNj4Bd6CAQf"; protected-headers="v1" From: Stephen Farrell To: "saag@ietf.org" Message-ID: <3fb50656-14f2-193d-dca1-2e542197478d@cs.tcd.ie> Subject: Re: [TLS] wiretapping draft - collecting rebuttal arguments References: <1777c26d-4e8c-453d-422e-b1f238105bd5@cs.tcd.ie> In-Reply-To: <1777c26d-4e8c-453d-422e-b1f238105bd5@cs.tcd.ie> --veur36RgxCtcOjkIrah1CSWNj4Bd6CAQf Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable FYI. Contributions from folks here would be welcome if you're interested, Cheers, S. PS: This relates to ongoing discussion on the TLS list. On 11/07/17 11:48, Stephen Farrell wrote: >=20 > Hiya, >=20 > I've asked the chairs for a slot in Prague to allow > for rebutting the claims made by the proponents of > the most recent wiretapping draft we're (sadly, still) > discussing. [1] >=20 > So far the chairs seem un-keen, but I'm gonna keep > asking as I think having a rebuttal for this kind > of bad idea is needed. (And again, I'd prefer the > chairs ditch the entire idea of discussing this at > all.) >=20 > In any case, and perhaps with a view to longer-term > documenting the arguments against the various "let's > break TLS" proposals we continually see, I've started > to collect some of those arguments in a github repo [2]. >=20 > I would welcome contributions to [2] however folks > would like to provide 'em (but ideally via PRs) so > we can provide a nice crowd-sourced rebuttal in > Prague, either as a presentation or via a lively > mic-line if need be. >=20 > Cheers, > S. >=20 > PS: I've just started on this, but will go through > the list archive to extract others' arguments and > add acks. Not sure if that'll get done before we > end up in Prague but please do let me know if I've > used an argument you made so I can ack that later. >=20 > [1] https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 > [2] https://github.com/sftcd/tinfoil >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --veur36RgxCtcOjkIrah1CSWNj4Bd6CAQf-- --LxteSTrIR39Ec3Wp8HKI41Ts2kIq760oH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZZK4LAAoJEC88hzaAX42i3tMH/03GHYVFQ0cer9kQ6K1rfzcM 57kYphg3QXEPP/hm/PLKYtwFw5P2RQb2Gc/qBlI2j4uAL7Ab0ZhxuP9KFQuaGtVm vB1IE5mdZpuGDIRXb1ukuXuiE3TXu77/sJXiDcxiA7ajvRjwogG/Lr9rATetjJMq CYSXi6t9tU9m9f7XmSVKdJgQOnrZeRHXkUR/hpz8yqaoZiU+ykjcimZM2aGMEHXo uaCtYVRt+PUPljj15CJwUu53lIo3Dtr7Y69/xcAl/w+KKb+/wunPjMGyG+Zj+VrR ObU7TmRXMLrU5PM/nbe38hnI5Zqn2TFs07FZ9FRnvs0fhAKytJukFnUc59IjvIA= =t5qF -----END PGP SIGNATURE----- --LxteSTrIR39Ec3Wp8HKI41Ts2kIq760oH-- From nobody Wed Jul 12 03:39:45 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1B8129AD2 for ; Wed, 12 Jul 2017 03:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 OcmDgdUFxolR for ; Wed, 12 Jul 2017 03:39:41 -0700 (PDT) Received: from dragon.pibit.ch (dragon.pibit.ch [94.231.81.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069E11270A7 for ; Wed, 12 Jul 2017 03:39:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by dragon.pibit.ch (Postfix) with ESMTP id ED621171C05B; Wed, 12 Jul 2017 12:39:37 +0200 (CEST) Received: from dragon.pibit.ch ([127.0.0.1]) by localhost (dragon.pibit.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDCRGBHS8NA3; Wed, 12 Jul 2017 12:39:35 +0200 (CEST) Received: from [192.168.43.90] (149.233.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.233.149]) by dragon.pibit.ch (Postfix) with ESMTPSA id 1025F171C035; Wed, 12 Jul 2017 12:39:35 +0200 (CEST) To: Stephen Farrell , saag@ietf.org References: From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgZm91bmRhdGlvbik=?= Openpgp: id=31733E0C598D3A1CF70955D6CB5738652768F7E9 Message-ID: Date: Wed, 12 Jul 2017 12:39:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8wNWKM5trwxGotuceuWLLXAQ3KnKxtFqj" Archived-At: Subject: Re: [saag] Documenting the pretty Easy privacy (pEp) protocols X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 10:39:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8wNWKM5trwxGotuceuWLLXAQ3KnKxtFqj Content-Type: multipart/mixed; boundary="8thuq1IALu1CaKwTX2l86FO1EmqKVHUkq"; protected-headers="v1" From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgZm91bmRhdGlvbik=?= To: Stephen Farrell , saag@ietf.org Message-ID: Subject: Re: [saag] Documenting the pretty Easy privacy (pEp) protocols References: In-Reply-To: --8thuq1IALu1CaKwTX2l86FO1EmqKVHUkq Content-Type: multipart/mixed; boundary="------------C9ED1FA9E907D5326C26A345" This is a multi-part message in MIME format. --------------C9ED1FA9E907D5326C26A345 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10.07.2017 16:20, Stephen Farrell wrote: > Hiya, Heyo Stephen > First, I'd encourage you to keep on at this, it's > good that we keep striving for ways to improve e2e > interpersonal messaging security. Yay, doing so! :) > That said, I think it might be useful to try enumerate > the barriers to progress there and which of those > are being tackled in this work. We'll be present at IETF-99 in Prague, so we're very happy to have discussions with any interested folks and to present how we're addressing the different scenarios one can think of, already in practice or still TBD. > For example, both smime and pgp were designed at a > time when we mostly had one desktop MUA and don't > really support multiple MUAs and esp not web MUAs. > I guess you are trying to address that for folks > who buy into using plug-ins, but it's not clear to > me if that can really scale without support for > whatever solution one wants being available at the > major mail service providers and in widely-used > MUAs. (I wish it could scale, but fear it can't, > at least not without support from others who control > some of those MUAs and mail services.) We try to address this by providing adapters / bindings for all major programming languages and programming platforms, such that e.g.: - For Outlook there's a plug-in, which can also be deployed in mass. - For Android there's a p=E2=89=A1p MUA (as no plug-in concept there). - For iOS a new MUA is being created, which will also be the first with OpenPGP-capable MUA with source code availalbe (otherwise, there's just closed-source iPGMail, AFAICT). - For Enigmail we've a cooperative project, whereas Enigmail will be in Enigmail/p=E2=89=A1p mode by default as of 2.0 (if no prior OpenPGP setup= can be found), so that novice users get all steps automatized for e2ee. There are other projects interested in cooperation. However, we cannot (alone) work on everything at the same time. :) The concept is that for commercial platforms there are companies (cf. https://prettyeasyprivacy.com) creating solutions, which can integrate in the already existing environments. There's also awareness of typical barries, like virus scanning, leakage prevention systems and archving present in big organizations and for legal reaons (e.g., archiving regulations). For the community side, the p=E2=89=A1p foundation is happy to collaborat= e and provide any assistance necessary. Most recently, we're setting up the process for automatic e2ee in web MUAs, for which plug-ins (in spirit similar to https://www.mailvelope.com/en) are necessary, which are able to talk to a local p=E2=89=A1p implementaiton (e.g., interfacing to the p=E2=89=A1p = engine reference implementation the p=E2=89=A1p foundation provides) on one side= , and the web MUA API on the other side. Of course, best-case would to have native p=E2=89=A1p support in the brow= sers, supporting most of the popular web MUAs. But that's a political isuse. > Anyway, I think it'd be useful to have a discussion > about that, i.e., being explicit about the set of > barriers to e2e security and the extent to which > the pEp scheme addresses some of those problems, > which wasn't really that clear to me from your > current draft. ACK Concerning the Implementation Status, somewhat outlined in the Internet-Draft (and above), we can discuss (and show) what we already have in practice. There we could also explain and show how multiple MUA support (when a user has multiple MUAs; with p2p key synchronization) is handled. Volker Birk as the software architect of the current implementations will be present, too. Greets Hernani --=20 p=E2=89=A1p foundation council member (https://pep.foundation) --------------C9ED1FA9E907D5326C26A345 Content-Type: application/pgp-keys; name="0x2768F7E9.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x2768F7E9.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFWozlEBEADAIFgjylzzPH7JKRJPbiEGoSsrSaCrbWLdy4sNGD4fS7GsuZ9f o/E9iYzC7WwGhN8rB4jsLv/ZfGVbAsmpypvZdReVs/BPidR8Vo1WMOK3lww1L6j8 7UV7TwUzG72u0zMXCUWMtX3+7kWZVlohXPCzDe7xyLu5tdfPWIAxDrI3h/+a4qAR ySVo8RwzILDwjbLF8at0w52oTRIWcr9CAus8ktRKBhc3MiUsSXHGgZLujUsXKAYg Vmh53uEVsjigeHZh6XPrzQPTnQ/VDcqNSRl4n+fQ2e/sZV7CQttcqb9zfj8P6Lyk jG3pe1AUSm9A0o75bi8PUluPWyH0wdt4D29xabFFyBANyYqKiLyZvnBqGSkqswnW 00QoYtMaEBh7nyuoUCa0bTMCRn8NaXRCnuINx+E2llqJqeQ0sMJ5WSQe4RbkWRsF PJOdiouLyHEZUpyQlMFesu/mN565eZsw3a7u9hxnoFgX0tF0hoONMRSAU1y3aZeb a+DvwXDQcSaHmBARQ2v8qWdql16Zhvf7KFo5Cris9jNknInzs2L6pHVZN8AY2ESO 2UXQJ+Fyy5BEHXS4LzEnWRPLYkAE5eVi+ZDcRMQeO2L3ZenqhcRRcQUAaRObho0L WzE+EE8ZvQxlA5hn/4/lHQLk8ZiEgenl+y/mtL8TeXB1HO4DrqahXvlu2QARAQAB tDxIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBmb3VuZGF0aW9uKSA8aGVybmFuaUBw ZXAuZm91bmRhdGlvbj6JAjwEEwEIACYCGyMHCwkIBwMCAQYVCAIJCgsEFgIDAQIe AQIXgAUCVyc6XQIZAQAKCRDLVzhlJ2j36ZLSD/4kywpRTvMvijdNM+3B8W4rLQSo 5BZUvkOEczZl0F4FzGgfaTLyGwj+hZtdatdxhk9jC5uYKaCAR+dP3wl8VjxmnjEc ir796Tw20sJuye4Qz+R9sghnJZM7NDZ7YmV2zpi4RXWY7CIYthpzUq1L3ujDlDNf KdKYd39PiGtyotx2lESw+LBlCddooPLSyPNp7fjWsRCgmg+2+yrVdl7TEO0QFcGs fLaNpjwVs2UXl+JzJql/CzV4Z9QxZAkhgpeObpiu4t/RJuPjmKS8lst7zJirhlwO rlXp5VkGyrmsPkXq/jFDkzNrAAX5uX34jTBgTveCRBr4MElVApq6sgbGfOOqvhU5 SZ2qWPw+t2yHiDbl9tE2Mac2UiodFPbFSlOnHd5KHh+ghWDyxCAkAcwxWexk4PTC WwGxqcvz95JcHXx6PAHDOkCB+zCHX65JOVpYxdb89xb1nBpqKphkXax7fyQbA8Pe Kf3ehp/x1gF94Cb6xevgUw1GeqZoURV65O9fzO0M+xSNjcyL+V1ps2IcZEOfKJtW nQYcfz0GZghSXl5KdKSAUlmt77nGuizsLL4qUaDIV0pvVAmBZmLbJ8vO9XSBDFnw 2mIrFZgUikcNpmZwKP7IwEcY6qz1BACG8xiS93j58qo9D9Ji2DqohIvsMTBFM2KQ p/VmXK9SPyVkNQa4vokCOQQTAQgAIwUCVyc6NQIbIwcLCQgHAwIBBhUIAgkKCwQW AgMBAh4BAheAAAoJEMtXOGUnaPfpJJAQALsvRmAU1dkCxdTMMiPtlzIbjWNwhoWg HP5XIjP/vbOyvu1Hjr1ur1C6WcR2GvlnFr6xlq5P62S2Z6GlCmTABlFdviMdrBIx UbDOywp6FR76w32uuQgq8Vsowdwv9lSJoUo0vR1f+1u0D+VkbAxIaUT3HUFY8pcm uqIpSm+TbvyMXCQ5/H6bNVK64hwifajbkEzqfjDFCcOLNwRLZn2dfJjNIFqC9bS/ Yuw4Rq1iAIWhPG47fu48dcvc2WGKlHHl18jEqNfnOvYM7EpxLtI+Kj1wYnxnmAGN 8LcHKhl9BWatHSV8jFlW0VPNHybL584sOEvlT7dFVsYccePMlljTdrxFSlxawyv6 WyiBIfiHnPxCCTB+FPIEBQhx7AdTnXbx1Ebyb7B9NMedAUKmZ3RCXdt5FsCE397F DHlomrzWs8Pt26dC0oHuLKIOkeMtYnbZoGvvkaNJ8XTkavguAswWQBPOumeVfJG4 u1nRNNRFbD6nGKYsm79KafkIpQKUlrIY6CnxrpuY2XGfqWLpJlWjK79L1EJRZMHP Z2y/6IOOT8truBwvHCu2R/bAXG9q5prHkGNegSc4CwPXbAXdKevrKYBGHrmtn4L8 dqJGlRehQUhZSHSBGckdr4Q7FerbAoEm6Xm2hOU4SKor3e9XAouU+COIRjk0cRTv OkTuySRdioqEtERIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBmb3VuZGF0aW9uKSA8 aGVybmFuaS5tYXJxdWVzQHBlcC5mb3VuZGF0aW9uPokCOQQTAQgAIwUCVyc6TgIb IwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEMtXOGUnaPfpn3gP/1V3n9Xt 8ha1juDe11jq0y0g1jQr1JMhZOoBOp6ttSpYCe9HCoJwVyvO1iGLex6XHSe8zrWv P38aihFoK7jQBc8xwYht1DcpTM7HFyXJ5/Pch8BNS4dsc8eozvm96pBPPmFDcm+i gG6dkO81/9oLqP8+Bagz8G58BktcFhvnjmLrkJftJAJQ4LyP5KlXgmUIxu9l//Wa 8AMkty+feHTIIbrQGDTM44a9N+uHwJ4OQjHNvvOprg4UZAhehLAzCk+gi68uHfhH 0AtKwZ/v/lag7OYle0KZelxFsHnVE+Dhe8HlyKqtCCOCvkWGtz5CBJDO/V/xUQXB SJxJd4Q4w9Gyf0mJ+Ljr8iu1fyaEor68u1ZGkaWbzQSF8Ycx7o6MWV1fAyFpUNUs 3M3vpmJpwrWQdNeCpQaczexnNcrzrYdFDLx8z7MMHEy86QSmjmaDSA+VgAHzV3oo 4R3Wu3wZKDwm4eFDBj8N5IBxMMfjfinnJb01WkAeRtAqK9KdXeWGs6eO6OBm8OSp ao2V/lw3IZIiCdowPaEFzw96DwmES/zTAis74mENrhnbvDrzFVFkNOUdf2Sn9x81 FJ7X13TEjENUhJJI87W+Ttk9eKUarkjtKdHfVpEMnO3Lg6NJiAvwpcYfarzfmorr wp1pscLZBEFGiAuHVgNzY1YwXMirPVnY7MnztDpIZXJuw6JuaSBNYXJxdWVzIChw 4omhcCBwcm9qZWN0KSA8aGVybmFuaUBwZXAtcHJvamVjdC5vcmc+iQI5BBMBCAAj BQJXJzp2AhsjBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQy1c4ZSdo9+kE ng//VY+l7xtGPe9q/FwmZ4ZyAPJn/hnwDjGhPeuEgsT4IgX220NB3UEXFAx8tCSu GY85862dC/AGQeGnzoM5u7rlTRFGuv92EtE2n/2Lfbte6yb5MRmzTgdR7cP1aNpv jCN+kEp4FfmHl1XPBFyX6WLEQG+ZnUDFIyHt2I7dehdN8UogJHdIfZ9y3IEhwPqA Yq4CRkf7P8Zkk2km2Jh8XjjgL5dsjCQKuNAnyktDpxUM3N/ifsOfrNulEIKlDA2y W3kcGL3CPj2ugwXgkSykeXaBzVoqbqRcPOO8/J7mVEOoLVjPwYq8f5NGWq2U0rbJ nRTHX4benaxw7rCi+6nbAEHTj0zbpx6FH8fezuzx86dWlFngqzQDOkiZWzc7ql/e b7pzHXuQ3QC1D+zzNn9TSTSDAjRFpgIuPWkAb/7/WyRfwqd0XzqinisA78I+E+0M OhjpQab/i9hoQRB2LfGaI+gBtaRX3aRotXNT1E5R1fq67r890Sjt3XTzADK9B6Rq pMa6T0LDe4zS2CYnDbUBjljsYGR5WZ7K03Qx2p9qfCFBTt2wvy2J0b526b0yCRIN c6TWDs/SlRqSs/ATaPSbOKfVUhXI8k0k2SV6FSBEPwIY0cUSRPSoANfv+IXjiW3R BbjNkvpbVtu98CDSbMBefAc3X8oVtrZ+rigZzd41QAhaOp20Qkhlcm7Dom5pIE1h cnF1ZXMgKHDiiaFwIHByb2plY3QpIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLXByb2pl Y3Qub3JnPokCOQQTAQgAIwUCVyc6hgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4B AheAAAoJEMtXOGUnaPfprZcQAL4wyuQHrMUb56gfvipTZNAV0YQopEeUtJlNPT3M DYTyD4AiTDmsDZwYaPI7O5m2bNSeLOmhAdqkUXhUOvEIWI0ABqkWVHL93nSEzFiI 5HYIbmh0UqpYf0myXQdWE1qjN6n1xnqk1mmZ7RSuIJ/9zwliiX5Qyr/RVfxOVU3i Bskn5iwGNs0N2anU6oA6EoD3VsuV650aIJN1c1e7bOd0QT4Z+FuYHPqsuZ/gnbD7 AKJIrpO/DoWMG/Ayzw3M746Ff6GKlQFaCmMja6pkfX8NqylbPY+lDlznu9LYXK3z /7gcNSZL3y53d1G5DvbK33sDXpHEpQOVbl6cAR6cgN0jyjh5Pg4VXKWTntAMlK9E /f+3HmH7EILxF6x9kl/TJet94igOvAU3v6Ktd3CPhc2XLvp6oik7NbE4hOFmkgJY q1pW9hffzh9NGzF5l10r9Z4j0bvxbbqXZCsn2/WvK4FhidZhyHgceM/kbH6jZdOE ZPw+Kxxlfsy4CeNDexas2OO1coz68lBiO6uD9+QgoV207hy4D5txTRF3YnR3TDdP bxiXnA8T/xNKOfMvWzfT4pmsuQdK9+DLmDPHDCZli3/5fLh2B2tb/r/SxLRNEaJj LEzbgPxxH53G5FOvjGR4isUbsZz0n2K2KZSxzVAEpkG1qmMhtGM4KZB2l+KTHBpx zElRtC9IZXJuYW5pIE1hcnF1ZXMgKHBFcCkgPGhlcm5hbmlAcGVwLXByb2plY3Qu b3JnPohGBBMRAgAGBQJV7/dAAAoJEHuDbkH3q5zl2OgAn12XbKVf0usg/exDv8tO xOzPTr8eAJ9b4QFCS/Bayw5zE3Fy650owknfJIkCHAQQAQIABgUCVfCW0wAKCRA9 g02NGPgJNGo+D/0ew5kut7hDw8dADIPpHaaSHfCu+7TskdQxUsbrg/4wvmiQ5lZv FBDtbqvtBHXVQ1Oj2xtPRRdlL5wuiBqf6hpnR8dQclggnALakVi8D+c38AKQFFBp APTraa6bCRawSS74+nOyrSpR/hUsYXmDyOvQCBxKpwS7Qi/Ob/JpfVZpLwD+297Z +ILNFixbYlYuA7V8z+ErQdkhSpkgtBoeB20gbw/FmqyQKvtM0ul43mINJpNzYP4y vU4YsDCNClGOYWLLPFLcnvVowmhRmMO7rM0eF6FfhLOGhbb31H8akl2Op2C7EiMv 2D8DGiZtV5QtVt9r/PCdl9LLEnw1kjULA50yCD0F4eXFLPLU1S6APqKFtSv9esSI NLjo0q1b4S5ekmUEqhBMRHvREPwGmsWjodp7pe1QPNPqb7prNAOwBxyKveXWIbL0 TaYbPhBQ4az7cUsWmlW9Bgn08zu9Jl9t9SdoEp6BV8qk7y6VmimMLYe2pST5dZjw eb7+u4Sfnfttxlt6kwu+hyz/c1RX9VdvgkzaJ+8i+pWvHyijmiStQTiHtJEcKbzh gHcEDfOkvFMGmNpHlVuB8skUnb9HeGheb6QZ2mRmCwZlKQQIMDYHE6xOIw8RJBHi IhvXOr73mXcORAsBvEAkGKQRldjtuQpb2dWEaL8oz3p4TA6vI/8y4qj7mYkCHAQQ AQgABgUCVe/3TgAKCRBLSiQj0EHGPcmQD/9ngwa9R8nsM0CTCMioJEbWJ4INnaDN D8uvnPzRT+vyUkTJzM+RCvVOoGgrmCFeqOeCQhdf20ExsANsqtv9XQEyDDI7PvnA nprJLSYozfpYscPe7N2MSwTBiPz70t03L5j6YfJhooCok921U0+xCNUl3LXzfIkX TxMC0z77VxSqEiHiPgQH4owqnDuEhRPte/ZtzvMgCRIk8L8+9UZazl8hF4r9XPP+ h8EFVJW0MB2ANICvmHcspiVd6QJdPTYHZIwZ2LMrb5Dt1QwyNkTDKvoImgR6qiaR 06GDyMhis6l8seu6GuAtOZGh2RGsGGPDPozcTi1kdytFmGC0W2J+bMoYeEMiAH4I p4o4KvLwvEIhU1RTMWg3Qo172w1Y2FLQSQLar5kVvjHfAdpgAeZMliPl7+ydziDF +EYP2p4d6kw6aPZNoB7uD1mhdgxts0lBuU3iRQwhOQTcrrJj/2DtUPdoFGoR5OTV Drmb1lodw5WWzI8FtTZ7C6ZyGPjj+V7COTSHGP4R7YLXKrPFK+5AjxzozK+cIgvY SZol8ZfAusxzz5mHXeTZqpHkQNdfCCHWCJ7og2W5baprUgkQn2O9AqEMSLQW9hpM GbzKIVh6ZFl6n2is/dZubS5aCH9+bNJqEi8Vd/pMsW9MMEeteGKc1WoGtDFFDM0Y ocgvF1CsSfGfMIkCOQQTAQgAIwUCVajOUQIbIwcLCQgHAwIBBhUIAgkKCwQWAgMB Ah4BAheAAAoJEMtXOGUnaPfpw2sP/3YEftsFv83sPLBclsA5HFNRr4FsXzbRv9F7 grDsqnvecgD8ItwUJ0G/Z/0uqXCPKecnq6mNhRZiX+AtNkGiMle6xcWI2kacAi/L 61GPyXWohsy7d42ej+FK2/lyKScTg979XBAXGJCCfyGoaVU0Rt9zlHyOOB3091YC 4gSYkMJ2i7jsdp7lqqvTwM6oPnEQkS75XliTDKesvYdrK87MTcF5tlBNVq0ycGmp GDOY5+d5HvkaJyhfUeJcknvMPIcObsH674vyhTejXabQg2uUhiWyOFEz4T2Xw72X dvtXhB8eIGNJOrGP8HqG0fhejoyXV7m2n0X9taYB+VqFrRnT9WeoStaMHzLhEAvO gLIXGe5bDPVkE0fV6SASvClAATtgsrunsYIuhQ5qHmcAxofCr0D4CA4YDhnRQbdb RaEKrHPFKkdtw9W8D2HO8X0xq6FmykYNuKI9k7w5oPgzuGnftBX/8VpKEaSAOaIX 4q4MrelsbyaJ8Ujx4fUFaGHQW2s1rmmJf8BnEEntyDSi3Tq7JABSeA0O5/JUJS9a 4rSMvvssdtYSSAtBD0N8yZTtdjdhaFffPbpv0PKmuNbjX1Fs0NOJDPWKwrSohXDW qr36ott5ap3/3wf/5upgKNR8AKoqjCF0hmPS2L3S+LNnqlZY8eomhf9YA1gSN49y R+2hAje7iQI8BBMBCAAmAhsjBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AFAlZf iokCGQEACgkQy1c4ZSdo9+lrTg/9FOyKWzceXttk0a3cnUpop7AQkQC9FfE9QQzF OW4VHk1ZKTlH7V1QrOrzU5fadd8C71oHbf75fVTlmNtcl9OE0fnx0T6G+FKvTyJV +W9LIRbsNe8+q7eRRtf/HsjQdblEIqkdUlAhVRgCjBI6K/reMYVoz5FxSGoIMjfx ds1K3kQICxS+uu+zRm6ff8VuWHMSESC34IxlIvfBf3vbPYnUPhu4Cn0UTxH3pmHm k+teJ1uFWiX98HAxDpv0ZobKNa9imcSCKhYTqdm89XBXND01bUd44w3RCmSqgzEQ oRi0Jj+ieg4XSn98lOItIBPE2pi92NskdSJr7C5++0fO9xrzURZjqGiEPmiegW+O MvnI6X9O2SBzXYU7GBiqpprWsa/y0WKRJ8O+kEVzGUI1BngeqvZ52QHGN9v5Wnho 0gvAWgiAmDVn6n3yfcnI+SBJHmvy+Im6TI8aNSX4G9xQjVukM/iWyjsNzAyxjtdk buOBiKAOADDqTC39HwsGoHXuKIzEZMGTFx7vA1yutogtg8MfUsqX18Ilt8p6v+dt JJY14MzF9fyVIfVr83Fc0IPuv3f59+7VQPY4AO9rUN+bcjggdKY9peLGizcT1msW ew4byIIjU39EfCx1ojfYkDFmV6fQOMOLWT62RgIiyORRKI0Ma2LnrHUqPDU6kWM7 8skVH+e0Pkhlcm5hbmkgTWFycXVlcyAocEVwIENvdW5jaWwpIDxoZXJuYW5pLm1h cnF1ZXNAcGVwLmZvdW5kYXRpb24+iQI5BBMBCAAjBQJWX4p+AhsjBwsJCAcDAgEG FQgCCQoLBBYCAwECHgECF4AACgkQy1c4ZSdo9+lsdw/9Ea0y2n0Indyhw8RaC7u/ Lu+OV5a03ATiWuV16vyYFXiJaVTCildscXCRpSRHrT84zk4eYf6ysRuzlXZUcg00 9nF6lajuzDm6E66ZJXkoInGpwEcGMx5odUeSKxcaZ5IQveEWyJahLbHf4FgQts2r 8BsChkoSEvhxojBhHQT5FYxdYNcKnrNj63UZw+xwTbg/79PWOjB141OEwNOT4rgg XSZ67w8O1JtMtMGYAgI2KiHIxUPruEudiJI8DvXUakX9LJRTpJnqSacgkC/ahL8m 5//7ePriUO2FR6ZeDkGp5z6g59+liruJhOcmbjpr7wAo6hVzdkpLT8qu4uuoaWM/ kRayEKfhlUj0SCcG751ucTE+yH9HMRBDUV/8fhVuoLsEHnq49/J/cVx7qr1y4EfD DaN8zW8ILe4vcZwGgbD0lI5r6tey2YyvwVEKDEe1vIiarbRsHa+6haX885SAyooI fdqKDcn6NGM12AVAPOIe2+2Q7GZV6AACD+j7GWX/jiNaV4HwJ2/SsNBFPw2/lDow sHnhFdvwEROynRlGG3FbHMGJ5HrNhQJWWZDPF40hDpuJpQRUuc5uzOzQUptag9m5 gfxCQNQXCtlIpIJ3CdlJJjPzndIHktV6/eo2xiAn24b2yBeiBnKjET6OE5iswAd4 DO3BjAKTBYYmqD2OMC+QCzS5Ag0EVajOUQEQALy+1UBEbXWX5iE1YezJ1qHy2DtT +0JUHiEMbY2iGO/cV4qXOwC5+w6ASp2Udoy52iHznW6AcktoQF/bf8JCxXGGISJM I0tS+1b61NuKW+vkXDiSgYn5X5V+mjqS4fFmTMoqo5ig4jqIunmEuwLlJxkP30s8 tUeGMRzcWSF5MvSKqQu0yXqg7N4MhEzMt4M4dV+I59HyoORJ805VBOFhr8jCtlg4 ug0HrySlLqRp20hhKL8lBUA5opyQkMNSbA+I0S5gFq9sZz31lLVC7sYm6ckap6FB ziAwcfnTfnFL4YFfTH4CIdkDFElCZ9318/cSnqbbhilRzvXh8aZfZl5wGntS6cIM JYbbKKGwdsPTkA5IR5yEVH1RbvD/m1d4cu5jqGfTeeRNMIngVirIa7W1Z49x/tTK ykUM6/mheqnzEqbbJsXLrnKN6Y+eu6mJLQgQhj/HNfk09j/wtgo1aRQgL/UVZDVT cuP0MuG9tTeZ39nt6dFaI3+IsTa4QhnDcO1dJ+eYsuCJmVY3CtuZ5Sh3GcNGk6sX +eeEMkfZ0jN9uwIWqhva5dqvetoO0VMfQyZiAauNxB0cjo2Cpl+xv+vQHEqPfFcY dY3QCay5Alsn3ttd6Ht+S2IB/BukcO9N+EmYT1HgJkS1c4UR6x512b0NTGRC6yMF AGSshsx3z9DInGvRABEBAAGJAh8EGAEIAAkFAlWozlECGwwACgkQy1c4ZSdo9+kp hw//Sw7Ji9eTyfJHdzRXNa1cA335dY1QYKq9/6eGhSjcyRGz4bHyHUDt5G5dmKwm aYrPGS3Hr2H1+Z3w9BD5X/V1ZVgsKYYVM18N0CsnarJdcugdwC1difyMzo2NJGz6 btuFey6ZiMZo6EQKgsH/0sLChHSLM5sjBgdmWswkWh7L8oNrFv/p091FVj6rFeda /e7g3xK2NjPSk3+oX5aLgcCrUSeWJCZflyEL6NEf3EOAahzzoqUfN9D6aTjZWPSm TVTO21t8s86XeSPuYBVGGODyIkCXWJxkm2WXY5AoPLYJWmmm9TwOJE0FgM/nTj04 cBNW91q8tCCaCx//2dGfW+EdAMew/G8aa2cJgbF7iJs5IWpMRUxujMM7rWJdxXjA h6Y3FiVc5UtYO87HmthC953QiJntDTa/72Oi7HrGw/wUtSRm2S9G/jdpXZ7WBaPD 0R4/QcXS9590nMfFahWfQs6cdAOtLBJzCL6JMX4sHqaycwxErzd0jvtohCGJW0Ks c8GjTxWtmgBpCVzkTidkWgXICzd7EKE36z5Ir6jvN7NLe4qbPQF+uDWmxQqAK92/ Iwt/NBALQ2oWAiHN5j8v2/ObJDuZH5Q4DGzzVmXYAeKjVMyH9Upsutnu8iYrvghK yC1RKKPPjqzJvcZkDO24NIw8RM1VxPH/3UxXFg+hWD+7KMw=3D =3DaXrV -----END PGP PUBLIC KEY BLOCK----- --------------C9ED1FA9E907D5326C26A345-- --8thuq1IALu1CaKwTX2l86FO1EmqKVHUkq-- --8wNWKM5trwxGotuceuWLLXAQ3KnKxtFqj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEMXM+DFmNOhz3CVXWy1c4ZSdo9+kFAlll/GYACgkQy1c4ZSdo 9+me2g//Ro9yhWhuoHRSDm/QS74TV3XGyhh9FIv8T98jPS+XGYa2v0hQL36NhELs 3ms+zEmH7eUM9cLW44/kRMfbpn/qWAJawiiEoVqg5gNmIgyX0D+vG2T1eoGotbID Tx3SXxd4gdmqIeeHcHMWu2qjMLMmo/JGuDlPcMfzMSBcXMp9V+rTqRGhZkHj3NHS E0Hts4bQiZSwrLXMkkceeQN/NQMzehwXYA3r45kh/+r4GFU5BlUKfgiCYrYFKP3Y Dg9J8627tqrkYGYpMNh6i17if0oi2gUjx7aO923l8sPmo+eY+JQqauxt6eDDIW3W Dlbv+nPhjpHaS4wkfxk58B+PRi71nofX6hHF3uYXuwDjMdcutcCCU7MkDYtNiqEw ta7qySHv2KmJaQhMcJDRqrWoPXWBr5cAkP/SUKrn12U06/ofRXqFs8Qa/WIs+V8T b9MZ15ZDcBb55kquBHwbP6nrxupxTdPE+7QgQffgcpPdEFpvqX0SuxPiKfLnQ1ii CHnV+fi4m38gnOjvasUE7e9YWaQ62XVG1FGq+kTThtI4JvanHW3wACbUafKZdTk6 R08dkj3RrUPEwRhbC1KXwpMrVYSf8GCUgNacDir1Xb/5GelEd4nahKVZRAu7yjWH HjnH5tq3IQjN8my1PsHKcJFXaKAAmZ6A0JSdX7+dMauEkKz4nek= =48sr -----END PGP SIGNATURE----- --8wNWKM5trwxGotuceuWLLXAQ3KnKxtFqj-- From nobody Sun Jul 16 02:32:58 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A9B1317CC for ; Sun, 16 Jul 2017 02:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CBQJEbDFb0Z for ; Sun, 16 Jul 2017 02:32:55 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 C8E6E127136 for ; Sun, 16 Jul 2017 02:32:55 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id e199so2639919pfh.2 for ; Sun, 16 Jul 2017 02:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=qdUB2vsjSJPcCKo6qj47ZuDwL8oHSdQTvsZHeQGyXak=; b=UnaA80GubBvU4UW1mAk2Gvpw8Q7DYyXVnVJVZ2TUPgONHIIPtwojYm+m4hljBiJKzH F/6szqjXGLiarJCxuaUMOdU81dNfBqfYhWfbOwaVIG6Bwp8y1sYH1Um07n6Jpny1YJo2 rojhNZZ4aoFm8uKmFKAPbZTV+jxgvthpxAqYRjZLOa8k8FuWnu038kFU8QEuE0LmxMeV BXE+tU2c+KIX4wXwELZSyqY7eCyNTcL3y0ncfTi4bGrOLGXSUeLjSdh1UNTPKEFE+jPr +pEUzsoERuTwzIlXmWiDwK+YrHWQAaJM6WxTBKo3TU7uBzHMOUSuUPhg9G2wvGvTKnhp O8MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qdUB2vsjSJPcCKo6qj47ZuDwL8oHSdQTvsZHeQGyXak=; b=jm919eWzkV4ryHqkX3Q02044+I4C+Y8SxCMd5Wl/dEZrfE4GbzYZGKLgT2tKESrJmM WNblZqvXRAMKuyKwY+AyEIUwsN138/1tRueBAsZC5UUbIuYSim0ZAtxl+S40xCKGqfLP g9cQrSq4w2RRDyz/fZRZ0wxL1tZ9oNE8EyTrkLQheYVk9U6Ne03aLu/yG3s7kbKeO1CM X7gld/8cBeB7tNJ4TG61brSPm6vZVv4EoyI2UCtqBrBYuJFnX1MB8KWDSfb85NVaNOou 8HyCEvmN9bvGpIHQXHOBVyO4d3DvEEazixxw8puvxOS0TsthOAiJF7VCp5Sn7K9ctgHd 8IQg== X-Gm-Message-State: AIVw113RXpibMPQwuAHikWc+wigvs9TaLEflG83qXPaYAKSka4/bFWYL 8RwXMnncqUPY94XmjJxKHFaPCXSllBBw X-Received: by 10.98.217.23 with SMTP id s23mr13704526pfg.204.1500197575086; Sun, 16 Jul 2017 02:32:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.193 with HTTP; Sun, 16 Jul 2017 02:32:14 -0700 (PDT) From: Kathleen Moriarty Date: Sun, 16 Jul 2017 05:32:14 -0400 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] TEEP tutorial X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 09:32:57 -0000 Hello, For those not aware, there will be a Trusted Execution Environments (TEE) and the Open Trust Protocol (OTrP) tutorial today at 13:45-14:45 in Karlin I/II. This was added to the agenda late, so I wanted to advertise it here for those interested. Abstract Chips used on smart phones, tablets, and many consumer appliances today have built-in support for a so-called Trusted Execution Environment (TEE). The Tis a security concept that separates normal operating systems, like Linux, from code that requires higher security protection, like security-related code. The underlying idea of this sandboxing approach is to have a smaller codebase that is better reviewed and test and to provide it with more rights. They run on the so-called Secure World (in comparison to the Linux operating system that would run in the Normal World). TEEs have been on the market for a while and have been successfully used for a number of applications, such as payment. However, the technology hasn't reached its full potential the market is quite fragmented with vendors offering a larger number of real-time operating systems running in a TEE. With the Open Trust Protocol we have been trying to develop an application layer security protocol that allows the management (install, update, delete) of trusted applications running on the TEE. In this talk we will explain the concept of TrustZone (as one example of a widely deployed technology offering sandboxing) and the Open Trust Protocol. -- Best regards, Kathleen From nobody Mon Jul 17 00:30:37 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1932E131A69 for ; Mon, 17 Jul 2017 00:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rr_THG-ScZji for ; Mon, 17 Jul 2017 00:30:34 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 0E5D8131A62 for ; Mon, 17 Jul 2017 00:30:34 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id v60so25703601wrc.3 for ; Mon, 17 Jul 2017 00:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=myddrDxxt1FB/nYOPwJLAA43izXgL96XtoJblnTodSA=; b=DlP/kO/peEdGhPfVC0A+3Zcjn6qoatRIAwDTcFkwuf7iOnzIa/GcVLJ61y76qegfVy 2Kgx+2H4jtCMC94+lYU8jwG849y1xeZ6GpI++yzCscEJexlHM9dOou0wcYbo6RerSF4r sXoUIWrUraJPtPrs72XLAqU36Dcg/xJ5gGNd0Hrn3jp559pFr7Ky3FNyA7JnU/Nhe8sA FqWhMkMDaqTRPWAEzjP+oXdrPx7bFCEeXeMGZCPXLODL8j8NU1qX3sq4reOB+7VBI2Je JGkn1nt1szJMTy3EDrD8rMOCIomVNqmjQAN6gSJKFvioqGDQVLW+rvD6R4oVrTzf2wv+ eTOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=myddrDxxt1FB/nYOPwJLAA43izXgL96XtoJblnTodSA=; b=o/1pGPJW+mnYchNjlJ4afyTaE+DlfvdzXH4lIFdH5avdSyCWk2BJCUdDl95239zhqQ vDryPi+e9VJaZiaDlpmJ97pgcjfdAWMWpkCirPrJOZCdizu0kXn8EJ8lwBdyFZzbCmYX UDCx4BLTexz9rsE72anat4FeMVqydnbIPvMv0inJc8FjeL45kJnsiOBfb4T/FpEPdyGZ hQXXEmDfCbkF6k6BI8pkvs+kAXFOxhzv6pOWuaCleZ/5IIHoPjVmSahsSkimaLuo/U+k s3cFhorAuQsm7fLgfbxSjpWlEMhFmJ0BAL2dBNlZbpCmJa5QtJqgYIRbisaZJ7JZoF43 0D0w== X-Gm-Message-State: AIVw111le5Cej/HZesWPBejra58maR53roL5ANGcx4VlSkq8hMjKCqKk jqIb5o7unHZpDKwvsYI= X-Received: by 10.223.134.226 with SMTP id 31mr10582768wry.63.1500276631955; Mon, 17 Jul 2017 00:30:31 -0700 (PDT) Received: from dhcp-80d4.meeting.ietf.org ([2001:67c:370:128:c896:7e50:63b9:5087]) by smtp.gmail.com with ESMTPSA id j76sm490920wmg.14.2017.07.17.00.30.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 00:30:30 -0700 (PDT) To: saag@ietf.org From: Melinda Shore Message-ID: <1232bcfd-f2d5-690d-ceae-6ddf930a31d3@gmail.com> Date: Mon, 17 Jul 2017 09:30:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ud0HO6q0jqa2xVeiJw8uMil8eOhJ2r0sr" Archived-At: Subject: [saag] IRTF side meeting on distributed internet infrastructure X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 07:30:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ud0HO6q0jqa2xVeiJw8uMil8eOhJ2r0sr Content-Type: multipart/mixed; boundary="r4B6BFDQW4aF3sXU1DWUGHcNicncOfnKf"; protected-headers="v1" From: Melinda Shore To: saag@ietf.org Message-ID: <1232bcfd-f2d5-690d-ceae-6ddf930a31d3@gmail.com> Subject: IRTF side meeting on distributed internet infrastructure --r4B6BFDQW4aF3sXU1DWUGHcNicncOfnKf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, all: It seems likely that some of you may be interested in an IRTF side meeting on distributed or decentralized internet infrastructure. Note that this is a potential activity in the IRTF, not the IETF. We had some good discussions with interested folks in and outside the IRTF in the past months and thought that it might be a good time now to try to start a more structured activity in the IRTF. The scope would be =E2=80=9CDistributed Internet Infrastructure=E2=80=9D,= I.e., applying distributed ledger technologies (such as blockchain, but not limited to it) to Internet technologies, for example to decentralized name registries, identity management, decentralized web etc. We have some people looking at the topic from different angles, i.e., IoT, decentralized web, Internet architecture and think that there is an interesting and potentially very productive scope we could work in the IR= TF. The meeting to discuss this will be a side meeting on Monday, July 17, 18:50 to 20:50 in the Karlin III room of the Hilton hotel (meeting hotel). Note that it will be streamed live on Meetecho, for those who are unable to be physically present. The agenda (as of current planning): 1) Background and Purpose 2) Selected Use Cases and Related Efforts - Decentralized OAuth - IoT - COALA.global 3) Ledger Technology 4) Next steps, RG Formation We=E2=80=99ll post agenda details, updated etc. on https://trac.ietf.org/trac/irtf/wiki/blockchain-federation Thanks, Dirk and Melinda --r4B6BFDQW4aF3sXU1DWUGHcNicncOfnKf-- --ud0HO6q0jqa2xVeiJw8uMil8eOhJ2r0sr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZbGeYAAoJELiGRpM6HoEuSOsP/j2mXmOJnAWaXqEhJnFgwUA+ CBVcErqKQ8Lhf3bosW7qJTHIWo4J0IgE5cPUXy62FcLNc9Oi3Tdxi9tKKlYm30w9 mbkY617EoVS9aP0D41NDgtQmUUfdccDVMdxr0CazSMPkHe3rjXGNU7FJKdwRTTLe D4QlCWDaYv8QBhFMNZARtwddHxto08Au/oZPfloMkjhzzUiDdjNu2ME8dXqnvpWT XM5amu16zHdADUoSZmwrn6ePjab67ZCR7UltMwft40PoscnqFGnsLtvFpFSDTS4e 3QQ1wCa6PT8pJK9FIhqt3S9unXnmheKGqY7XVC6LaUR2r+kgzX9KQmubgZDmZqTQ 6FGuCWl9EF9x2eayOUpRJYmoIdGoiL0w9NENZtpTwGrFZDZYZUGSoABi9qCz0Fqj lcYpuSQN/RI38RpufP5x0X+QddxdIhXhhd3VMZFfjwYmGJ2uSKqdbvebvoWnyBqE S78c3ld/c6nCWjCaZgqdue3skPCMesOAi4MM34PKYUJ8+0/YNaacfj6VM0XuSFpu TtbnPCwiyItCl0/+iJYvHAXHX15Jdj08t6lnFv28/Q7RoNcEdumn4YCIFd/1fhGT atFlJZFhiXcX0jLAAx3AcTlZSi+49eVU4hIsdncQ9dC6WiDaNAZrztu9YEtr+VSV O3PsnuIGo5vyo+wBs6KE =8yB+ -----END PGP SIGNATURE----- --ud0HO6q0jqa2xVeiJw8uMil8eOhJ2r0sr-- From nobody Mon Jul 17 03:41:42 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6720E131AA6; Mon, 17 Jul 2017 03:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 eTTStg2Ftkoa; Mon, 17 Jul 2017 03:41:26 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51CE1319B4; Mon, 17 Jul 2017 03:41:25 -0700 (PDT) Received: from [31.133.153.152] ([31.133.153.152]) by mrelayeu.kundenserver.de (mreue004 [212.227.15.167]) with ESMTPSA (Nemesis) id 0LkkrY-1e50ly1yRI-00aUsV; Mon, 17 Jul 2017 12:41:22 +0200 From: "Dirk Kutscher" To: irtf-announce@irtf.org, din@irtf.org, saag@ietf.org Cc: "Melinda Shore" , "Allison Mankin" Date: Mon, 17 Jul 2017 12:41:20 +0200 Message-ID: <510B54EE-85D2-4BCA-8098-2CF359A0DCA8@dkutscher.net> In-Reply-To: References: <5A57D1EF-FAB2-4F89-823F-F543E28631AF@dkutscher.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) X-Provags-ID: V03:K0:pfCWUOm8hU0wwmk+a5uLIMryu1XCHRDFzKMNsXXru7QqxQXRf0+ sdALy+mVip2+YZZ5H2SG5E6r6qH+L5c3YPya5q18bFZ6BIUmJW/xeJL+Ox1pJLOTeZGpGX7 sRowHrVy4RzPGmDl62Ba4kKic5m8ZcQwmE5RkcskwP7Sg2MHLD203u5jlM05KtT6wnk/IqA Ff66aNoOBoaWxR78vjFfw== X-UI-Out-Filterresults: notjunk:1;V01:K0:awD/uirxe8I=:po0FevbH2SCwD8R+V7wagp 82X0/QMepEfEIO1EcN+r0e77hdleb4yn65i24n3JucXBNrZWixo+4HCMm5xCBZNv4Zp68kJo6 5CQal3fKDBuIos5++Dgc+kz8uGy7IcNIClSgIzHloGW2FHi6KjN7scnSGhZ+UOqgE3bOsDPNL T3Wd2U2iIBERkWon2hq4FIy2bzr7aW3Nwd0J18aUOKJqQ3KGlIDG5WjMmxUpBseuYojW+h+RO vZu2aJSWbMb0lDoN8SpG0TzFPIJOrC8mnjxkSDEkQz61YHhdgc78s8VbR/GABhMlCsI+x5vsn qyJIaCSUiplC/13OSqWChnjRCee57x6jN9J5Tn2+HPqnZ2li2eZZlTzF3BQv7MQg9dS3JL13Q g+LfkHbQRPJo9hawPioelI4biMwh1u4zQlAc7XwUufPE3QjpdczA4y4RzmGORQ69VT04RJmLP POGDO66HgSN5+b6M3zZ/Sect4wgi89GpANHLVoXMaQQzjqXNSTVMd7oQYEKDK9QK+CVk2Bmf5 /jYFgeZ+9c3O8HWOpJ5kxZmguroakJ5UiGiiQCK4cL27RO051Yy+SBv86J1LJV3H4S/IvayeL tQCbEv38NiU3JucLQbAyoCvyA2ZpxLYvhm2WZXg9r9JD4xyKzuTrhWo3xufOC8yFkpbNuaGmD rlDuTywixr1kQRzh9gq7aFJbY910e6IUooW9Wm7hbbTplWyqlSwy01FEwUNTmxQflOcNiXBkz tuQxNvNRquXBbXVCZH119rRUNZ+zJKXB04j42OSZfFxsHEvd0QKbPQIRIFI= Archived-At: Subject: Re: [saag] Side meeting on Distributed Internet Infrastructure at IETF-99 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 10:41:28 -0000 OK, updated meeting logistics and agenda: Coordinates Date & Time: Monday, July 17, 18:50 -- 20:30 Room: Karlin III, Hilton (Meeting hotel) remote participation: ​http://www.meetecho.com/ietf99/irtf17 Draft Agenda 1) Background and Purpose (Dirk & Melinda) 2) Selected Use Cases and Related Efforts - An analysis of the applicability of blockchain to secure IP addresses allocation, delegation and bindings (Jordi Paillissé Vilanova) https://datatracker.ietf.org/doc/draft-paillisse-sidrops-blockchain/ - Lightest Project Overview (Benno Overeinder) http://lightest.eu/ - Cloudless IoT (Lixia Zhang) 3) Discussion of Next steps —- Dirk and Melinda On 16 Jul 2017, at 23:14, Dirk Kutscher wrote: > Hi, > > Just a reminder that this is happening tomorrow. We might move to > another room for MeetEcho coverage — we’ll update the webpage (see > below) and send a notification if that happens. > > Best regards, > Dirk > > On 26 Jun 2017, at 23:27, Dirk Kutscher wrote: > >> Hi all, >> >> we are holding another side meeting on Distributed Internet >> Infrastructure at IETF-99. We had some good discussions with >> interested folks in and outside the IRTF in the past months and >> thought that it might be a good time now to try to start a more >> structured activity in the IRTF. >> >> The scope would be “Distributed Internet Infrastructure”, I.e., >> applying distributed ledger technologies (such as blockchain, but not >> limited to it) to Internet technologies, for example to decentralized >> name registries, identity management, decentralized web etc. >> >> We have some people looking at the topic from different angles, i.e., >> IoT, decentralized web, Internet architecture and think that there is >> an interesting and potentially very productive scope we could work in >> the IRTF. >> >> The meeting to discuss this will be a side meeting on Monday, July >> 17, 18:50 to 20:50 in the Tyrolka room of the Hilton hotel (meeting >> hotel). >> >> The agenda (as of current planning): >> >> 1) Background and Purpose >> 2) Selected Use Cases and Related Efforts >> - Decentralized OAuth >> - IoT >> - COALA.global >> 3) Ledger Technology >> 4) Next steps, RG Formation >> >> We’ll post agenda details, updated etc. on >> https://trac.ietf.org/trac/irtf/wiki/blockchain-federation >> >> Let us know in case you have any question or are interested to get >> involved! >> >> Best regards, >> Dirk (on behalf of co-organizers) From vb@pep.foundation Mon Jul 17 07:10:07 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C546D131BDC for ; Mon, 17 Jul 2017 07:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 uSxKg33pxB8F for ; Mon, 17 Jul 2017 07:10:05 -0700 (PDT) Received: from dragon.pibit.ch (dragon.pibit.ch [94.231.81.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BFE131BDD for ; Mon, 17 Jul 2017 07:10:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by dragon.pibit.ch (Postfix) with ESMTP id 377B2171C06A for ; Mon, 17 Jul 2017 16:10:03 +0200 (CEST) Received: from dragon.pibit.ch ([127.0.0.1]) by localhost (dragon.pibit.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59BK33yzj2uk for ; Mon, 17 Jul 2017 16:10:00 +0200 (CEST) Received: from localhost (dhcp-9332.meeting.ietf.org [31.133.147.50]) by dragon.pibit.ch (Postfix) with ESMTPSA id A13E0171C055 for ; Mon, 17 Jul 2017 16:10:00 +0200 (CEST) Date: Mon, 17 Jul 2017 16:10:00 +0200 From: Volker Birk To: saag Message-ID: <20170717141000.335aase56ug7m76q@pep-project.org> Mail-Followup-To: saag MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ipkw57vmcrjwsqkl" Content-Disposition: inline X-PGP-Key: http://fdik.org/vb.key Archived-At: Subject: [saag] =?utf-8?q?BarBoF=3A_opportunistic_encryption_with_p?= =?utf-8?q?=E2=89=A1p_on_Thu_2017-07-20_19=3A30_CEST_starting_room_Tyrolka?= =?utf-8?q?=2C_ending_in_a_bar_=3B-=29?= X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 14:11:12 -0000 --ipkw57vmcrjwsqkl Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, following the intro being delivered in the SAAG Open Meeting starting 13:30: https://www.ietf.org/proceedings/99/agenda/agenda-99-saag-02.txt for people being interested in oportunistic encryption of email and instant messaging p=E2=89=A1p is offering a short workshop in room Tyrolka = on Mezzanine level on Thursday, 20th of July 2017 19:30 CEST for all pre-beer questions. Post-beer questions (and beer) will be served in a bar nearby subsequently ;-) We're happy to receive all people being interested in this topic and all surrounding technical fields. However, personally I would be most happy to have people delivering strong opinions and frank critics ;-) Yours, VB. --=20 Volker Birk, p=E2=89=A1p project mailto:vb@pep.foundation https://pep-project.org --ipkw57vmcrjwsqkl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZbMU3AAoJEOvpDUQUb2L0jSQP/13AJO9NnFMYoLHlSgVWvLDN iPlqZS8sYE5kNvZDBcFp2n6ZcEdVCbko8652rymylfr/Q8hbFAQABPSTVi7hY89b 7jtF4sb4PI7kih0NF0+anyyRr7oEbMjTaydzdOsSlRNypySvprqB5w8y4P8V0ynm 2iFPT6qofomE3zdC/wO5KIxZ83ko2O8L9di1JGVmp+nTMlYzQvKq1wBs1aYCc0NV NQ0yAnSOogMsE+PzyasJb2X8yEHHy1wIxRk9bff2Q++oUqnve4fmW9Gm7ogEBUC0 vLyqr+8mBcpfr/mBgR/FKFaFvdyhHbxrzZdFGW+kMQKTu4vysSH3iZgnMXDktGs6 qdGOhasw7AGbMjCjdpwfsA98KY62N+GRm478yzgAL7REl6kpsv64QI6+IpkY7IWd 3CC4EnU0+ftst3O0fsOtukn63qPSSmFXDae5+RfIJ0njDNVmJ+GoOgroKZOgF0Ly JuwH72j3l3dmA/bz5OrronBy3gkGzbcmp6cSzw38cQHcpRTtdzUgxLJPUFxJ7zsR Zv5Mkh1a92kp9Drkk6fax1NDJc2t73cKjoFlwofaYhgTSEpakH3U+cFGBtV8cQxs FjEzk809QFaAEqOx01UP250hOS8kT9Km2bMnBELoPpqivfdnZobzBaIUyc5u8j2Z DmM2djPMJJY7qx5kS/YA =AT7D -----END PGP SIGNATURE----- --ipkw57vmcrjwsqkl-- From nobody Mon Jul 17 09:40:31 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111D7131A88 for ; Mon, 17 Jul 2017 09:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 ohzITfFd7hpx for ; Mon, 17 Jul 2017 09:40:28 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1268B131B4E for ; Mon, 17 Jul 2017 09:40:27 -0700 (PDT) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id v6HGeQ3h058982; Tue, 18 Jul 2017 01:40:26 +0900 (JST) Received: from LAPTOP9DLCDU5S (ssh1.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id v6HGeKwY055683; Tue, 18 Jul 2017 01:40:21 +0900 (JST) From: "Takeshi Takahashi" To: Date: Tue, 18 Jul 2017 01:40:21 +0900 Message-ID: <000001d2ff1b$650964c0$2f1c2e40$@nict.go.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D2FF66.D4F2E180" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdL/GxM5pj9JTaKbS2uUh3Cowluu9w== Content-Language: ja X-Virus-Scanned: clamav-milter 0.98.7 at zenith2 X-Virus-Status: Clean Archived-At: Subject: [saag] MILE WG report for IETF99 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:40:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D2FF66.D4F2E180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MILE met at IETF99 at 15:50 on Monday. There were about 30 attendees in the room and Jabber. [Status of WG drafts] - Draft-ietf-mile-rolie-07: this draft is soon to be sent to the IESG. - Draft-banghart-mile-rolie-csirt-01: more reviews were requested prior to adopting the draft as a WG draft. - Draft-ietf-mile-xmpp-grid-03: the WG will re-initiate the WGLC. - Draft-ietf-mile-iodef-guidance-10: it is soon to be sent to the IESG after the shepherd writeup is completed. [Other issues discussed at the session] - The interests in the interoperatibility between ROLIE and TAXII were discussed, and the WG asked the experts of TAXII to present their work before the next meeting. - IODEFv2 schema revision was proposed and discussed. - The WG showed interests in working on the JSON representation of IODEF. - Three hackathon works related to MILE were introduced. - Discussion on the TLSv3 from the standpoint of CSIRT operations is requested to the WG participants. ------=_NextPart_000_0001_01D2FF66.D4F2E180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MILE met = at IETF99 at 15:50 on Monday.

There = were about 30 attendees in the room and Jabber.

 

[Status = of WG drafts]

- Draft-ietf-mile-rolie-07: this = draft is soon to be sent to the IESG.

- = Draft-banghart-mile-rolie-csirt-01: more reviews were requested prior to = adopting the draft as a WG draft.

- = Draft-ietf-mile-xmpp-grid-03: the WG will re-initiate the = WGLC.

- Draft-ietf-mile-iodef-guidance-10: it is = soon to be sent to the IESG after the shepherd writeup is = completed.

 

[Other = issues discussed at the session]

- The = interests in the interoperatibility between ROLIE and TAXII were = discussed, and the WG asked the experts of TAXII to present their work = before the next meeting.

- IODEFv2 schema revision was = proposed and discussed.

- The WG showed interests in = working on the JSON representation of IODEF.

- Three = hackathon works related to MILE were introduced.

- = Discussion on the TLSv3 from the standpoint of CSIRT operations is = requested to the WG participants.

 

------=_NextPart_000_0001_01D2FF66.D4F2E180-- From nobody Mon Jul 17 13:26:59 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FF0129B2A for ; Mon, 17 Jul 2017 13:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 siqCGJMcNVf0 for ; Mon, 17 Jul 2017 13:26:57 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2606B126CD6 for ; Mon, 17 Jul 2017 13:26:57 -0700 (PDT) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id v6HKQuMe063624 for ; Tue, 18 Jul 2017 05:26:56 +0900 (JST) Received: from LAPTOP9DLCDU5S (ssh1.nict.go.jp [133.243.3.49]) by gw2.nict.go.jp with ESMTP id v6HKQs4B063614 for ; Tue, 18 Jul 2017 05:26:55 +0900 (JST) From: "Takeshi Takahashi" To: References: In-Reply-To: Date: Tue, 18 Jul 2017 05:26:56 +0900 Message-ID: <005701d2ff3b$09e14fc0$1da3ef40$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdL/GxM5pj9JTaKbS2uUh3Cowluu9wAH76mA Content-Language: ja X-Virus-Scanned: clamav-milter 0.98.7 at zenith2 X-Virus-Status: Clean Archived-At: Subject: Re: [saag] MILE WG report for IETF99 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 20:26:59 -0000 We found some typo, so let us resend the report. ----------------------------- MILE met at IETF99 at 15:50 on Monday. There were about 30 attendees in the room and Jabber. [Status of WG drafts] - Draft-ietf-mile-rolie-07: this draft is soon to be sent to the IESG. - Draft-banghart-mile-rolie-csirt-01: more reviews were requested prior to adopting the draft as a WG draft. - Draft-ietf-mile-xmpp-grid-03: the WG will re-initiate the WGLC. - Draft-ietf-mile-iodef-guidance-10: it is soon to be sent to the IESG after the shepherd writeup is completed. [Other issues discussed at the session] - The interests in the interoperatibility between ROLIE and TAXII were discussed, and the WG asked the experts of TAXII to present their work before the next meeting. - IODEFv2 schema revision was proposed and discussed. - The WG showed interests in working on the JSON representation of IODEF. - Three hackathon works related to MILE were introduced. - Discussion on the TLSv1.3 from the standpoint of CSIRT operations is requested to the WG participants. From nobody Tue Jul 18 02:51:48 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA25131DE6 for ; Tue, 18 Jul 2017 02:51:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=nistgov.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 MJiw6F3OGF3B for ; Tue, 18 Jul 2017 02:51:43 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0104.outbound.protection.outlook.com [23.103.200.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877751286B2 for ; Tue, 18 Jul 2017 02:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cyGy8AFqDAPf53yu3P6lZ0RSZfwEr7kK5IA6N+xut94=; b=OQ8uAIfWLsBxd1LYm7PBJ2LZHo0bWbb7gOi6fANJ2EOeP6OlmIvh/Ben2XdqeYErN7t4Bbw0eptP45Zx4ItJODSW1sDNzJRSl7HrQv6WNe/LzH32vHKIkRJg78k68Fw0dyy5bJMydIXt575sBzO82pNaaEdGfyIX8vL/UPKz33Y= Received: from DM2PR09MB0778.namprd09.prod.outlook.com (10.161.145.150) by BN6PR09MB1425.namprd09.prod.outlook.com (10.173.202.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Tue, 18 Jul 2017 09:51:35 +0000 Received: from DM2PR09MB0778.namprd09.prod.outlook.com ([fe80::29fb:f7d4:8b2f:ea68]) by DM2PR09MB0778.namprd09.prod.outlook.com ([fe80::29fb:f7d4:8b2f:ea68%18]) with mapi id 15.01.1261.022; Tue, 18 Jul 2017 09:51:34 +0000 From: "Polk, Tim (Fed)" To: "saag@ietf.org" Thread-Topic: Side meeting on USG efforts to combat botnets, Wednesday at 3:15 Thread-Index: AQHS/6twJJ5lxUIqtEi61cnIynWjcQ== Date: Tue, 18 Jul 2017 09:51:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ntia.doc.gov; dkim=none (message not signed) header.d=none;ntia.doc.gov; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.220.87] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR09MB1425; 7:ik4vbz5hSfMINe72k+qTGed/EJlKQDEOdNllPfX5ZPY23/TItE95fdiYLP3qQLqaBPBgKRhgNmZPmO9ZPoP//Cs2nbd4qLrmNywErJiHp4D0PqLAvuM0xquPXBwkEdVMd2GUOeqh8SqB4JHeXstOMlpqNDfSRnEiUScylDlpLQQ6zRGQ0KQqth1/8kFYa1PUA7TYbf3uK2XkTxuzKQ3araxwhtjSVLbWybI0t+J9gqtl/Tt30V4HyKbu7pXZ37FO7pPirRxZTtol+WaK80ahhKuAxz1PJj/sI1OjKWNFIZPkmUr1yPxSJw1/lxT88qgqmpVYXSMEfv9VvzLYVUJkbIXvLDDX8EWjB9AfkADevavOyrTgOZxhUyx/LT/gzDSr9RmSJYwwHXE7F0Qswfpuw8UgUq2yP0oq5lJRP+nBvQRNXpYE4Dbg99ptZnTbCO3LoPE13hfKljEp90Td7G0nhR0gfdSt0K8t+rXJuYDZv85OvNqLo/7ThMmYuwQiVgU8rzy9SR4x9AV/nYLv/aUebvdKHfGC/6PWGAnVg3GLNUl9+nYzZHTh+lSes3VqCViBCxSpNPUn7DmEYgMmAKniaaxmpZtMcMQew4M/IQHsq845bYZ9SYSD4AYdnJ1jxjI7igTkP2YTyAjHsIV2Fxn42R2u6fsE1szBRBW8VV4Y1QJPRQhZu1y+YKp7bbru3vBSjnXb37663idyBi6BmyNMZDsHZQYVOc8E2PKqvKuChNRxpxqY6hzNAX0YS4P5zmp8V/9l/PFUtHgcu/wtFRDK6gVYtAeC2miYQfaAHuxJKFc= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39840400002)(39410400002)(39860400002)(39850400002)(39400400002)(39450400003)(3660700001)(5250100002)(66066001)(236005)(99286003)(55016002)(6116002)(102836003)(2501003)(606006)(54896002)(9686003)(6306002)(3846002)(7696004)(14454004)(19627405001)(8936002)(53336002)(33656002)(86362001)(25786009)(3280700002)(6506006)(6436002)(81166006)(2351001)(5640700003)(2900100001)(74316002)(50986999)(7736002)(110136004)(2906002)(38730400002)(5660300001)(6606003)(966005)(8676002)(1730700003)(53936002)(478600001)(189998001)(54356999)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR09MB1425; H:DM2PR09MB0778.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 1e6c51ba-982f-47d1-539b-08d4cdc2934a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR09MB1425; x-ms-traffictypediagnostic: BN6PR09MB1425: x-exchange-antispam-report-test: UriScan:(278178393323532)(65766998875637)(236129657087228)(192374486261705)(281040445377566)(148574349560750)(247924648384137)(2006787148836)(231250463719595); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR09MB1425; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR09MB1425; x-forefront-prvs: 037291602B spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0778F6B4E4111775B158EBB5E7A10DM2PR09MB0778namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2017 09:51:34.1881 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR09MB1425 Archived-At: Subject: [saag] Side meeting on USG efforts to combat botnets, Wednesday at 3:15 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 09:51:46 -0000 --_000_DM2PR09MB0778F6B4E4111775B158EBB5E7A10DM2PR09MB0778namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Folks, I have reserved the side meeting room (Tyrolka, Mezzanine Level) on Wednesd= ay from 3:15 =96 4:30 for an informal discussion of an ongoing US Governmen= t effort to combat botnets and other =93automated, distributed threats=94 t= o the Internet. This effort will produce a document that identifies and pr= omotes =93action by appropriate stakeholders=94 by May of 2018. Given that= the USG does not own or operate the Internet, such an effort is always at = risk of creating shelfware, and I am too old to waste my time that way. To= ensure that actions identified in the report are pragmatic and effective, = I would like to encourage participation by members of this community. If you have an interest, please join me in Tyrolka tomorrow afternoon or ca= tch me in the hallway between meetings. For those with an interest, here is some additional background information,= including an immediate opportunity to participate: Executive Order 13800, Strengthening the Cybersecurity of Federal Networks = and Critical Infrastructure, which was issued May 11, 2017, requires the Se= cretaries of Commerce and Homeland Security to =93jointly lead an open and = transparent process to identify and promote action by appropriate stakehold= ers to improve the resilience of the internet and communications ecosystem = and to encourage collaboration with the goal of dramatically reducing threa= ts perpetrated by automated and distributed attacks (e.g., botnets).=94 The executive order requires Commerce and DHS to issue a draft report in 24= 0 days (January 5, 2018) and submit a final report to the President one yea= r after issuance (May 11, 2018). Given this aggressive timeline, there are= several different (but hopefully complementary) workstreams underway at Co= mmerce and DHS that may be of interest. In particular: (1) The National Telecommunications and Information Administration (NTIA) p= ublished a =93Request for Comments on Promoting Stakeholder Action Against = Botnets and Other Automated Threats=94 on June 8. In the request, =93NTIA = seeks broad input from all interested stakeholders=97including private indu= stry, academia, civil society, and other security experts=97on ways to impr= ove industry=92s ability to reduce threats perpetuated by automated distrib= uted attacks, such as botnets, and what role, if any, the U.S. Government s= hould play in this area.=94 NTIA would definitely appreciate comments from= members of this community! Additional details may be in the full text of the request for comments, fou= nd in https://www.gpo.gov/fdsys/pkg/FR-2017-06-13/pdf/2017-12192.pdf Note that the official comment period was extended to July 28 in https://www.gpo.gov/fdsys/pkg/FR-2017-06-22/pdf/2017-13034.pdf (2) Last week, NIST hosted a public workshop on =93Enhancing Resilience of = the Internet and Communications Ecosystem=94. 150 participants from a rang= e of industry sectors, civil society, and government participated in a day = and half workshop. The workshop explored a range of current and emerging = solutions to enhance the resiliency of the Internet against automated, dist= ributed threats. The workshop agenda is available at https://www.nist.gov/sites/default/files/documents/2017/07/10/final-draft-a= genda-resilience-workshop-070517.pdf NIST plans to summarize results in a workshop report for publication in Sep= tember 2017. Regards, Tim Polk --_000_DM2PR09MB0778F6B4E4111775B158EBB5E7A10DM2PR09MB0778namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Folks,

 

I have r= eserved the side meeting room (Ty= rolka, Mezzanine Level) on Wednesday from 3:15 =96 4:30 for an informal discussion of an ongoing US Government effor= t to combat botnets and other =93automated, distributed threats=94 to the I= nternet.  This effort will produce a document that identifies and promotes =93= action by appropriate stakeholders=94 by May of 2018.  Given that the USG does not own or operate the Internet, such an eff= ort is always at risk of creating shelfware, and I am too old to waste my t= ime that way.  To ensure that actions identi= fied in the report are pragmatic and effective, I would like to encourage p= articipation by members of this community.

 

If you h= ave an interest, please join me in Tyrolka tomorrow afternoon or catch me i= n the hallway between meetings.

 

For thos= e with an interest, here is some additional background information, includi= ng an immediate opportunity to participate:

 

Executiv= e Order 13800, Strengthening the Cybersecurity of Federal Networks and= Critical Infrastructure, which was issued May 11, 2017, requires the Secretaries of Co= mmerce and Homeland Security to =93jointly lead an open and transparent pro= cess to identify and promote action by appropriate stakeholders to improve = the resilience of the internet and communications ecosystem and to encourage collaboration with the goal of d= ramatically reducing threats perpetrated by automated and distributed attac= ks (e.g., botnets).=94 

 

The exec= utive order requires Commerce and DHS to issue a draft report in 240 days (= January 5, 2018) and submit a final report to the President one year after issuance (May 11, 2018).  Given this aggressive timeline, there are several different (but hop= efully complementary) workstreams underway at Commerce and DHS that may be = of interest.  In particular:

 

(1) The = National Telecommunications and Information Administration (NTIA) published= a =93Request for Comments on Promoting Stakeholder Action Against Botnets and Other Automated Threats=94 on June 8.  In = the request, =93NTIA seeks broad input from all interested stakeholders=97i= ncluding private industry, academia, civil society, and other security expe= rts=97on ways to improve industry=92s ability to reduce threats perpetuated by automated distributed attacks, such as botne= ts, and what role, if any, the U.S. Government should play in this area.=94=   NTIA would definitely appreciate comments from members of this commu= nity!

 

Addition= al details may be in the full text of the request for comments, found in

https://www.gpo.gov/fdsys/pkg/FR-2017-06-13/pdf/2017-1219= 2.pdf

 

Note tha= t the official comment period was extended to July 28 in

https://www.gpo.gov/fdsys/pkg/FR-2017-06-22/pdf/2017-1303= 4.pdf

 

(2) Last= week, NIST hosted a public workshop on =93Enhancing Resilience of the Inte= rnet and Communications Ecosystem=94.  150 participants from a range of industry sectors, civil society, and government participat= ed in a day and half workshop.   The workshop explored = a range of current and emerging solutions to enhance the resiliency of the = Internet against automated, distributed threats. The workshop agenda is ava= ilable at

https://www.nist.gov/sites/default/files/documents/2017/07/10/fin= al-draft-agenda-resilience-workshop-070517.pdf

 

NIST pla= ns to summarize results in a workshop report for publication in September 2= 017.

 

 Re= gards,

 

Tim Polk=

 


--_000_DM2PR09MB0778F6B4E4111775B158EBB5E7A10DM2PR09MB0778namp_-- From nobody Tue Jul 18 23:30:27 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC61F127369 for ; Tue, 18 Jul 2017 23:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGJ7Ac7fq6at for ; Tue, 18 Jul 2017 23:30:25 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F8612EC0B for ; Tue, 18 Jul 2017 23:30:24 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id 125so2256256pgi.3 for ; Tue, 18 Jul 2017 23:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=j0/KMlU+H6zY4phjk2KFq3Ag5U0Wprm4GdegZmXDHj8=; b=fGCQtJWVC5mmxik73ZTmbT7jTNkbp2s3NX6HDs5QxT/Q5K6UVp38Yqvwfm0C5qINHa zJr6bqljaOSL/QBEhLx3I43PECB0p0CENInoOryKkAQl/Hlh9DtaxakQTyQJSvTgeqXF s/C9WdOwb/5PeM7q8jkWWzxbYClK6lss2OABX9SV0WuTDr7coMVF8qNC3gGVjlWkAztC gT6HHFPewl/XItZgYyCMresG1FAxxrTwIDbJ0QZQZi21xc5Fb7pbMzGfIrxxjJzRqWZI ZYFjtalOjDKO42CC8K7NB8IB98EGD7gTu4cw97pQbKUuFFo/Cfw+i4WWoIaYSSKIw3OK ZwAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=j0/KMlU+H6zY4phjk2KFq3Ag5U0Wprm4GdegZmXDHj8=; b=J2qnXU6yR2mk4uKRyW6oJSGD1k4xCxGVjhbv8CrEPq619GpgTUZpK8xJ+kUi2kwiui brwDWZD6rN7SNApCOPayXIs1gh8zn3etjquJj76SGf6sxfnqOUjNK6FN8d3P66zfV8fS rIFnRTBA3AyEoDC02zRmBpeVQdiaNkwkS5PK3UwY3DKXKbB2rwC05sGfeb5YSsNDAsEu 5hgZkfmFgyPCSWIWAqJCUfji3cDTFwh7aCRiO+6U3dSlNDmwwdmwy0Yf3PQqkjbHJV6I zAcSwjRcSGbtVUn5T67QlxPzB5bCpSiFpuaeNrZpWHF+dSrHYwshhX2LO6Q+2+C79nNJ xvnw== X-Gm-Message-State: AIVw11087SdkeLwL3ZT64CSYbUQ6kOujNKhGh3SHiNJbuxhpp64HwMqR rKucrzNTbNCXkVvvtVWyf790fjP0IA== X-Received: by 10.101.73.72 with SMTP id q8mr1398543pgs.219.1500445823877; Tue, 18 Jul 2017 23:30:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.193 with HTTP; Tue, 18 Jul 2017 23:29:43 -0700 (PDT) From: Kathleen Moriarty Date: Wed, 19 Jul 2017 02:29:43 -0400 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] minutes and jabber volunteers X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 06:30:26 -0000 Hello, Could 2 people volunteer to assist with minutes during SAAG tomorrow and one for jabber scribe? Thank you. -- Best regards, Kathleen From nobody Wed Jul 19 07:05:18 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC4A126CD8 for ; Wed, 19 Jul 2017 07:05:16 -0700 (PDT) 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, 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=cdt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PRoM9N2o0dR for ; Wed, 19 Jul 2017 07:05:14 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA06131473 for ; Wed, 19 Jul 2017 07:05:14 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id f68so743960vkg.2 for ; Wed, 19 Jul 2017 07:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H5QytZoNIxtbHts/9+G5M13dWnbejGokuSY8p1n1ZAY=; b=DzNbif/cXDD9WqWjAlGbQ/vWUEttyRKaMGSHnOUJvsIldiFDLAB2HRw9GT1zbcOXyj phnd+C4HlCzsJdpeoOxKSuGgHJiTJapaQW2uIkEU3aAIE69wXMXvmgIqP6mZP1wREtHW ZvjDWyWAOYKlhY2QHjXKoez3iNOkGCioXhkW0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H5QytZoNIxtbHts/9+G5M13dWnbejGokuSY8p1n1ZAY=; b=dtTrn31iuigjVuiD3Tm8TXOIXA3QSs+HsAgcmH/mbsBAxP8/gqe5JYXqemNGlThmsH L/VUzn1uTzMYHK/97ndPlBni4ifiwFZcUMQDaI8LsQtvOA1JBwO4dfUasgsdI2N6+MW8 csUjDbpjtcDaqqotbFhyeEyX1m2oTpe9TCw3QpIAk0OGBusB7ji/SQBOo4ewv6IPIB8F lJVmiozFmqxtELaXPV09YhH4v/gkk5wdig3yCOhzaKAZ2GHEVVrBH0JoZ2WjZ3HRNGe8 +Qq3tJW8qi6WteF865QTxyWwViN+zkBGeCqlZF3oWqsQBcsgg6oV25yaTk/C3r/FH7Wy 4GfQ== X-Gm-Message-State: AIVw110oiTChf/qpgpjSCrkz+k/1HyKI6hwU7lwHEtzQvXyO/xSo8Uzq RUPGqEpYB07HHeS2JrmD3BZMWfBQ2x4m X-Received: by 10.31.115.206 with SMTP id o197mr98657vkc.27.1500473113477; Wed, 19 Jul 2017 07:05:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.137 with HTTP; Wed, 19 Jul 2017 07:04:52 -0700 (PDT) In-Reply-To: References: From: Joseph Lorenzo Hall Date: Wed, 19 Jul 2017 16:04:52 +0200 Message-ID: To: "Polk, Tim (Fed)" Cc: "saag@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c14990eec919e0554ac1ea4" Archived-At: Subject: Re: [saag] Side meeting on USG efforts to combat botnets, Wednesday at 3:15 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 14:05:17 -0000 --94eb2c14990eec919e0554ac1ea4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Richard Barnes pointed to this I-D that looks pretty damn good here in terms of a floor for IoT technical requirements: https://tools.ietf.org/html/draft-moore-iot-security-bcp-01 On Tue, Jul 18, 2017 at 11:51 AM, Polk, Tim (Fed) wrote: > Folks, > > > > I have reserved the side meeting room (Tyrolka, Mezzanine Level) on > Wednesday from 3:15 =E2=80=93 4:30 for an informal discussion of an ongoi= ng US > Government effort to combat botnets and other =E2=80=9Cautomated, distrib= uted > threats=E2=80=9D to the Internet. This effort will produce a document th= at > identifies and promotes =E2=80=9Caction by appropriate stakeholders=E2=80= =9D by May of 2018. > Given that the USG does not own or operate the Internet, such an effort i= s > always at risk of creating shelfware, and I am too old to waste my time > that way. To ensure that actions identified in the report are pragmatic > and effective, I would like to encourage participation by members of this > community. > > > > If you have an interest, please join me in Tyrolka tomorrow afternoon or > catch me in the hallway between meetings. > > > > For those with an interest, here is some additional background > information, including an immediate opportunity to participate: > > > > Executive Order 13800, Strengthening the Cybersecurity of Federal Network= s > and Critical Infrastructure, which was issued May 11, 2017, requires the > Secretaries of Commerce and Homeland Security to =E2=80=9Cjointly lead an= open and > transparent process to identify and promote action by appropriate > stakeholders to improve the resilience of the internet and communications > ecosystem and to encourage collaboration with the goal of dramatically > reducing threats perpetrated by automated and distributed attacks (e.g., > botnets).=E2=80=9D > > > > The executive order requires Commerce and DHS to issue a draft report in > 240 days (January 5, 2018) and submit a final report to the President one > year after issuance (May 11, 2018). Given this aggressive timeline, > there are several different (but hopefully complementary) workstreams > underway at Commerce and DHS that may be of interest. In particular: > > > > (1) The National Telecommunications and Information Administration (NTIA) > published a =E2=80=9CRequest for Comments on Promoting Stakeholder Action= Against > Botnets and Other Automated Threats=E2=80=9D on June 8. In the request, = =E2=80=9CNTIA > seeks broad input from all interested stakeholders=E2=80=94including priv= ate > industry, academia, civil society, and other security experts=E2=80=94on = ways to > improve industry=E2=80=99s ability to reduce threats perpetuated by autom= ated > distributed attacks, such as botnets, and what role, if any, the U.S. > Government should play in this area.=E2=80=9D NTIA would definitely appr= eciate > comments from members of this community! > > > > Additional details may be in the full text of the request for comments, > found in > > https://www.gpo.gov/fdsys/pkg/FR-2017-06-13/pdf/2017-12192.pdf > > > > Note that the official comment period was extended to July 28 in > > https://www.gpo.gov/fdsys/pkg/FR-2017-06-22/pdf/2017-13034.pdf > > > > (2) Last week, NIST hosted a public workshop on =E2=80=9CEnhancing Resili= ence of > the Internet and Communications Ecosystem=E2=80=9D. 150 participants fro= m a range > of industry sectors, civil society, and government participated in a day > and half workshop. The workshop explored a range of current and > emerging solutions to enhance the resiliency of the Internet against > automated, distributed threats. The workshop agenda is available at > > https://www.nist.gov/sites/default/files/documents/2017/ > 07/10/final-draft-agenda-resilience-workshop-070517.pdf > > > > NIST plans to summarize results in a workshop report for publication in > September 2017. > > > > Regards, > > > > Tim Polk > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --=20 Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --94eb2c14990eec919e0554ac1ea4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Richard Barnes pointed to this I-D that looks pretty damn = good here in terms of a floor for IoT technical requirements:

https://t= ools.ietf.org/html/draft-moore-iot-security-bcp-01

On Tue, Jul 18, 2017 at 11:= 51 AM, Polk, Tim (Fed) <william.polk@nist.gov> wrote:

Folks,

=C2=A0

I have reserved the side = meeting room (Tyrolka, Mezzanine Level) on Wednesday from 3:15 =E2=80=93 4:30 for an informal discussion of an ongoing US Government= effort to combat botnets and other =E2=80=9Cautomated, distributed threats= =E2=80=9D to the Internet.=C2=A0 This effort will produce a document that identifies and promotes =E2= =80=9Caction by appropriate stakeholders=E2=80=9D by May of 2018.=C2= =A0 Given that the USG does not own or operate the Internet, such an eff= ort is always at risk of creating shelfware, and I am too old to waste my t= ime that way. =C2=A0To ensure that actions identified in the report are prag= matic and effective, I would like to encourage participation by members of = this community.

=C2=A0

If you have an interest, = please join me in Tyrolka tomorrow afternoon or catch me in the hallway bet= ween meetings.

=C2=A0

For those with an interes= t, here is some additional background information, including an immediate o= pportunity to participate:

=C2=A0

Executive Order 13800,=C2= =A0Strengthening the Cybersecurity of Federal Networks and Critical Infrast= ructure, which was issued May 11, 2017, requires the Secretaries of Co= mmerce and Homeland Security to =E2=80=9Cjointly lead an open and transpare= nt process to identify and promote action by appropriate stakeholders to im= prove the resilience of the internet and communications ecosystem and to encourage collaboration with the goal of d= ramatically reducing threats perpetrated by automated and distributed attac= ks (e.g., botnets).=E2=80=9D=C2=A0

=C2=A0

The executive order requi= res Commerce and DHS to issue a draft report in 240 days (January 5, 2018) = and submit a final report to the President one year after issuance (May 11, 2018).=C2=A0 Given this aggressive timeline, there are several different (but hop= efully complementary) workstreams underway at Commerce and DHS that may be = of interest.=C2=A0 In particular:

=C2=A0

(1) The National Telecomm= unications and Information Administration (NTIA) published a =E2=80=9CReque= st for Comments on Promoting Stakeholder Action Against Botnets and Other Automated Threats=E2=80=9D on June 8.=C2= =A0 In the request, =E2=80=9CNTIA seeks broad input from all interested sta= keholders=E2=80=94including private industry, academia, civil society, and = other security experts=E2=80=94on ways to improve industry=E2=80=99s abilit= y to reduce threats perpetuated by automated distributed attacks, such as botne= ts, and what role, if any, the U.S. Government should play in this area.=E2= =80=9D=C2=A0 NTIA would definitely appreciate comments from members of this commu= nity!

=C2=A0

Additional details may be= in the full text of the request for comments, found in

https:/= /www.gpo.gov/fdsys/pkg/FR-2017-06-13/pdf/2017-12192.pdf

=C2=A0

Note that the official co= mment period was extended to July 28 in

https:/= /www.gpo.gov/fdsys/pkg/FR-2017-06-22/pdf/2017-13034.pdf

=C2=A0

(2) Last week, NIST hoste= d a public workshop on =E2=80=9CEnhancing Resilience of the Internet and Co= mmunications Ecosystem=E2=80=9D.=C2=A0 150 participants from a range of industry sectors, civil society, and government participat= ed in a day and half workshop.=C2=A0 =C2=A0The workshop explored a range of current and emer= ging solutions to enhance the resiliency of the Internet against automated,= distributed threats. The workshop agenda is available at

https://www.nist.gov= /sites/default/files/documents/2017/07/10/final-draft-agenda-resilience-workshop-070517.pdf

=C2=A0

NIST plans to summarize r= esults in a workshop report for publication in September 2017.

=C2=A0

=C2=A0Regards,

=

=C2=A0

Tim Polk

=C2=A0



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




--
Joseph Lorenzo Hall
Chief= Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 2= 00, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fin= gerprint: 3CA2 8D7B 9F6D DBD3 4B10 =C2=A01607 5F86 6987 40A9 A871
--94eb2c14990eec919e0554ac1ea4-- From nobody Wed Jul 19 13:16:06 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38DB12EC01 for ; Wed, 19 Jul 2017 13:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwW5rRBep851 for ; Wed, 19 Jul 2017 13:16:02 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 4116B128AB0 for ; Wed, 19 Jul 2017 13:16:02 -0700 (PDT) X-AuditID: c618062d-9edff70000002716-4b-596fd3db202d Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id EF.23.10006.BD3DF695; Wed, 19 Jul 2017 23:49:15 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 16:16:00 -0400 From: Daniel Migault To: "saag@ietf.org" , "curlde@ietf.org" Thread-Topic: Curdle IETF99 report Thread-Index: AdMAxXxxh3dTQSoUTCe4cScfZ/7dpA== Date: Wed, 19 Jul 2017 20:15:59 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118CC82CF@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CC82CFeusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyuXRPiO7ty/mRBl2HzS2a96xntZjS38nk wOSxZMlPpgDGKC6blNSczLLUIn27BK6MKRs2Mxe0b2KsuL7xIlMD4765jF2MnBwSAiYSa9a9 Ze5i5OIQEjjKKLH98WF2CGc5o8TRn7/ZQKrYBIwk2g71s4PYIgIeEq+2/GPpYuTgEBaQlVjz pggirCTRvvofVImexK3r38FaWQRUJW50LwCL8wr4Sqx6OZcFxGYUEJP4fmoNE4jNLCAucevJ fCaIgwQkluw5zwxhi0q8fPyPFcJWkpjz+hozRH2+RPOE26wQMwUlTs58wjKBUXAWklGzkJTN QlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzFylBYX5OSmGxlsYgSG+zEJNt0djPen ex5iFOBgVOLhLQbGgRBrYllxZe4hRgkOZiUR3qpdQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8 E85fiBASSE8sSc1OTS1ILYLJMnFwSjUwVv6cwXE48uwFdocNb5iLqi5e3ZS9TDnRiVN1vptx 6GuL45ULX4lNSrs576V5fHnMm2RXqQ+BVvOz7R1VWqTjvBkkxeT72zPnOXg//811ZUG+yd7o 5G0yD8JeiH7PnnZZ/PnBCd4WpaYz/isULONw/BQiLsrPtLDYtnBV1Lomzfr2mLIdZlZKLMUZ iYZazEXFiQCwMF/1cwIAAA== Archived-At: Subject: [saag] Curdle IETF99 report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 20:16:05 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CC82CFeusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Curdle WG met on Monday July 17 from 11:30 - 12:00 The following drafts have been sent to the IESG: * draft-ietf-curdle-cms-ecdh-new-curves-09 * draft-ietf-curdle-cms-eddsa-signatures-06 * draft-ietf-curdle-des-des-des-die-die-die-03 * draft-ietf-curdle-pkix-05 * draft-ietf-curdle-rsa-sha2-09 * draft-ietf-curdle-ssh-curves-05 * draft-ietf-curdle-ssh-dh-group-exchange-04 hC * draft-ietf-curdle-ssh-ext-info-10 * draft-ietf-curdle-ssh-modp-dh-sha2-07 The following drafts are in WGLC: * draft-ietf-curdle-ssh-kex-sha2-08 * draft-schaad-curdle-oid-registry-01 * draft-ietf-curdle-gss-keyex-sha2-02 The following draft will be called for adoption: * draft-ietf-curdle-rc4-die-die-die-00 The following draft will be revived: * draft-ietf-curdle-ssh-ed25519-00 The scope of curdle was limited to ECDHE, EdDSA with Curve25519 and Curve44= 8, Chacha20Poly1305, AES-CCM, AES-GCM. * Introduction of the new curves is done or ongoing for SSH / DNSSEC / = PKIX / CMS / Kerberos * For SSH, the WG needs to evaluate if AES-CCM and Chacha20Poly1305 wil= l be done. Signature and DH key exchange have been updated / deprecated. * For Kerberos, recommendations on DH is ongoing. the WG needs to evalu= ate if AES-CCM/GCM and Chacha20Poly1305 will be done. * The WG is looking at providing some cryptographic recommendation poli= cies. * Protocols XML, JSON have not yet been considered. --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CC82CFeusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Curdle WG met on Monday July 17 from 11:30 ̵= 1; 12:00

 

The following drafts have been sent to the IESG:

  • draft-ietf-curdle-cms-ecdh-new-curves-09
  • draft-ietf-curdle-cms-eddsa-signatures-06
  • draft-ietf-curdle-des-des-des-die-die-die-03
  • draft-ietf-curdle-pkix-05
  • draft-ietf-curdle-rsa-sha2-09
  • draft-ietf-curdle-ssh-curves-05
  • draft-ietf-curdle-ssh-dh-group-exchange-04 hC
  • draft-ietf-curdle-ssh-ext-info-10
  • draft-ietf-curdle-ssh-modp-dh-sha2-07

 

The following drafts are in WGLC:

  • draft-ietf-curdle-ssh-kex-sha2-08
  • draft-schaad-curdle-oid-registry-01
  • draft-ietf-curdle-gss-keyex-sha2-02

 

The following draft will be called for adoption:

  • draft-ietf-curdle-rc4-die-die-die-00

 

The following draft will be revived:

  • draft-ietf-curdle-ssh-ed25519-00

 

The scope of curdle was limited to ECDHE, EdDSA with= Curve25519 and Curve448, Chacha20Poly1305, AES-CCM, AES-GCM.

  • Introduction of the new curves is done or ongoing for SSH / DNSSEC / PKIX /= CMS / Kerberos
  • For SSH, the WG needs to evaluate if AES-CCM and Chacha20Poly1305 will be d= one. Signature and DH key exchange have been updated / deprecated.
  • For Kerberos, recommendations on DH is ongoing. the WG needs to evaluate if= AES-CCM/GCM and Chacha20Poly1305 will be done.
  • The WG is looking at providing some cryptographic recommendation policies.<= o:p>
  • Protocols XML, JSON have not yet been considered.

 

  

--_000_2DD56D786E600F45AC6BDE7DA4E8A8C118CC82CFeusaamb107erics_-- From nobody Wed Jul 19 13:37:10 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A92131722 for ; Wed, 19 Jul 2017 13:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 sYz2-oCCZ17c for ; Wed, 19 Jul 2017 13:37:07 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111CB131456 for ; Wed, 19 Jul 2017 13:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7790; q=dns/txt; s=iport; t=1500496626; x=1501706226; h=from:to:subject:date:message-id:mime-version; bh=ptP2Wqtq8fSqhsc4nzlN70Ajwjw/yDdjNn2xzr0xbW8=; b=KOkXw6ZXsjt17I8BXhbsPANyr9EK/2k76mZ2uIh8sguoLx5KyqE4UMy5 oOwmsgklBrkeLhUsxpxsIvERPLjKzgtfBPULpC7xsk68+91Ufrpm/OfaW UebQIKkD5zSzzzyiOjMCVAq2wH0j4e1+YSX8JSsA/OlyFKXYEi5ifUXZl g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAgAEwm9Z/5NdJa1cHAEBBAEBCgEBg?= =?us-ascii?q?m9rZIEbjgSRRZB6hSyCEYVjg0k/GAECAQEBAQEBAWsdC4VCaAFKAgQwJwSJXmS?= =?us-ascii?q?yI4ImJ4p7AQEBAQEBBAEBAQEBAQEBAR+DKIUuKwuEEIZbMIIxBZ85ApQXkjCVW?= =?us-ascii?q?wEfOIEKdRVbAYcDiQmBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,381,1496102400"; d="scan'208,217";a="270244519" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2017 20:37:06 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v6JKb5pq030244 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 19 Jul 2017 20:37:05 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Jul 2017 16:37:05 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 19 Jul 2017 16:37:04 -0400 From: "Nancy Cam-Winget (ncamwing)" To: "saag@ietf.org" Thread-Topic: ANIMA IETF99 report Thread-Index: AQHTAM7I6yPF4uE5FUaqBiIhEnTp+Q== Date: Wed, 19 Jul 2017 20:37:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.247.74] Content-Type: multipart/alternative; boundary="_000_BFDD46A5B1D74775ACD59FF76C004788ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [saag] ANIMA IETF99 report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 20:37:09 -0000 --_000_BFDD46A5B1D74775ACD59FF76C004788ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QU5JTUEgbWV0IHRvZGF5LCBXZWQgTW9ybmluZyBTZXNzaW9uIDENCg0KZHJhZnQtaWV0Zi1hbmlt YS1nZG4tcHJvdG9jb2wgaGFzIHBhc3NlZCBJRVNHIGV2YWx1YXRpb24NCg0KVGhlIGZvbGxvd2lu ZyBkcmFmdHMgcGFzc2VkIFdHTEM6DQpkcmFmdC1pZXRmLWFuaW1hLXByZWZpeC1tYW5hZ2VtZW50 DQpkcmFmdC1pZXRmLWFuaW1hLXN0YWJsZS1jb25uZWN0aXZpdHkNCmRyYWZ0LWlldGYtYW5pbWEt dm91Y2hlciBoYXMgcGFzc2VkIGJ1dCBpcyBhd2FpdGluZyBjb25maXJtYXRpb24gZnJvbSBORVRD T05GICYgNlRpc2NoOg0KDQpUaGUgZm9sbG93aW5nIGRyYWZ0cyBhcmUgc3RpbGwgaW4gV0c6DQpk cmFmdC1pZXRmLWJvb3RzdHJhcHBpbmcta2V5aW5mcmENCmRyYWZ0LWlldGYtYW5pbWEtcmVmZXJl bmNlLW1vZGVsDQpkcmFmdC1pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lDQoNClVw ZGF0ZXMgdG8gZHJhZnRzIGluIFdHTEMgYW5kIFdHIHN0YXR1cyB3ZXJlIHByb3ZpZGVkLg0KDQpU aGUgc2NvcGUgb2YgQU5JTUEgaXMgZm9jdXNlZCBvbiDigJxtYW5hZ2Vk4oCdIG5ldHdvcmtzLCB0 aGVyZSB3YXMgZGlzY3Vzc2lvbiBhbmQgYnJpZWYgcHJlc2VudGF0aW9uIG9uIGhvdyB0aGlzIG1h eSBhcHBseSB0byBhbiBJb1Qg4oCcbWFuYWdlZOKAnSBuZXR3b3JrLg0KVGhlIGNoYWlycyBhbHNv IGRpc2N1c3NlZCBjdXJyZW50IHByaW9yaXRpemF0aW9uIHdvcmsgYmFzZWQgb24gdGhlIGNoYXJ0 ZXIsIHRoZSBjdXJyZW50IGFnZW5kYSBhbGxvY2F0aW9uIHRvIGZvY3VzIG9uIGN1cnJlbnQgV0cg aXRlbXMgYnV0IGFsc28gYWxsb3dpbmcgcG90ZW50aWFsIG5ldyB3b3JrIHRvIGJlIGRpc2N1c3Nl ZCB3aGljaCBjb3VsZCBhbHNvIGhlbHAgZGVmaW5lIEFOSU1BIGZ1dHVyZSBhbmQgcmVjaGFydGVy aW5nLg0KDQpSZWdhcmRzLCBOYW5jeQ0K --_000_BFDD46A5B1D74775ACD59FF76C004788ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <13C46FDD3EE89D458670A2E45DD4461F@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b05vU3BhY2luZywgbGkuTXNvTm9TcGFjaW5nLCBkaXYuTXNvTm9TcGFjaW5nDQoJe21zby1zdHls ZS1wcmlvcml0eToxOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpzcGFuLkVtYWlsU3R5bGUx Nw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OkNhbGli cmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BTklNQSBtZXQgdG9kYXksIFdl ZCBNb3JuaW5nIFNlc3Npb24gMQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPmRyYWZ0LWlldGYtYW5pbWEtZ2RuLXByb3Rv Y29sIGhhcyBwYXNzZWQgSUVTRyBldmFsdWF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+VGhlIGZvbGxvd2luZyBkcmFmdHMgcGFzc2VkIFdHTEM6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ZHJhZnQtaWV0Zi1hbmltYS1wcmVmaXgtbWFuYWdlbWVu dA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ZHJhZnQtaWV0Zi1h bmltYS1zdGFibGUtY29ubmVjdGl2aXR5DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij5kcmFmdC1pZXRmLWFuaW1hLXZvdWNoZXIgaGFzIHBhc3NlZCBidXQgaXMgYXdh aXRpbmcgY29uZmlybWF0aW9uIGZyb20gTkVUQ09ORiAmYW1wOyA2VGlzY2g6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+VGhlIGZvbGxvd2luZyBkcmFmdHMgYXJlIHN0aWxsIGluIFdH OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPmRyYWZ0LWlldGYtYm9v dHN0cmFwcGluZy1rZXlpbmZyYQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+ZHJhZnQtaWV0Zi1hbmltYS1yZWZlcmVuY2UtbW9kZWwNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPmRyYWZ0LWlldGYtYW5pbWEtYXV0b25vbWljLWNvbnRy b2wtcGxhbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+VXBkYXRlcyB0byBkcmFmdHMgaW4gV0dMQyBhbmQgV0cgc3RhdHVz IHdlcmUgcHJvdmlkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+VGhlIHNjb3Bl IG9mIEFOSU1BIGlzIGZvY3VzZWQgb24g4oCcbWFuYWdlZOKAnSBuZXR3b3JrcywgdGhlcmUgd2Fz IGRpc2N1c3Npb24gYW5kIGJyaWVmIHByZXNlbnRhdGlvbiBvbiBob3cgdGhpcyBtYXkgYXBwbHkg dG8gYW4gSW9UIOKAnG1hbmFnZWTigJ0gbmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij5UaGUgY2hhaXJzIGFsc28gZGlzY3Vzc2VkIGN1cnJlbnQgcHJpb3Jp dGl6YXRpb24gd29yayBiYXNlZCBvbiB0aGUgY2hhcnRlciwgdGhlIGN1cnJlbnQgYWdlbmRhIGFs bG9jYXRpb24gdG8gZm9jdXMgb24gY3VycmVudCBXRyBpdGVtcyBidXQgYWxzbyBhbGxvd2luZyBw b3RlbnRpYWwgbmV3IHdvcmsgdG8gYmUgZGlzY3Vzc2VkIHdoaWNoDQogY291bGQgYWxzbyBoZWxw IGRlZmluZSBBTklNQSBmdXR1cmUgYW5kIHJlY2hhcnRlcmluZy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJlZ2FyZHMsIE5hbmN5PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BFDD46A5B1D74775ACD59FF76C004788ciscocom_-- From nobody Wed Jul 19 17:54:31 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5C01270A3 for ; Wed, 19 Jul 2017 17:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 MO0q390Ed9kF for ; Wed, 19 Jul 2017 17:54:28 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.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 980C2126E64 for ; Wed, 19 Jul 2017 17:54:28 -0700 (PDT) X-AuditID: 1209190c-f0bff70000003df7-cd-596fff42ecef Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id E8.6D.15863.24FFF695; Wed, 19 Jul 2017 20:54:26 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v6K0sPMi013353 for ; Wed, 19 Jul 2017 20:54:25 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v6K0sM0c021925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 19 Jul 2017 20:54:24 -0400 Date: Wed, 19 Jul 2017 19:54:22 -0500 From: Benjamin Kaduk To: saag@ietf.org Message-ID: <20170720005422.GR75962@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixCmqrOv0Pz/S4PE8PYsp/Z1MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKeHDlBGPBY9aK9uW7GRsYH7F0MXJySAiYSKz70MDWxcjFISSw mEni7oUpUM5RRolJl54wQjgvmSS+rl0I1sIioCqxffUUJhCbTUBFoqH7MjOILSIgKPGgbxJY jbCAksTLjousIDYv0Ire9tnsELagxMmZT8BqmAW0JG78ewk0hwPIlpZY/o8DJCwqoCwxb98q tgmMvLOQdMxC0jELoWMBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXUO93MwSvdSU0k2M4FCS 5NnBeOaN1yFGAQ5GJR7eB6n5kUKsiWXFlbmHGCU5mJREeefwAoX4kvJTKjMSizPii0pzUosP MUpwMCuJ8O76CZTjTUmsrEotyodJSXOwKInzSmg0RggJpCeWpGanphakFsFkZTg4lCR4E/8C NQoWpaanVqRl5pQgpJk4OEGG8wANnwZSw1tckJhbnJkOkT/FqMvR9GHLFyYhlrz8vFQpcV6m f0BFAiBFGaV5cHNAKUAie3/NK0ZxoLeEeSVAqniA6QNu0iugJUxAS4R9c0CWlCQipKQaGO9G PFU61PFrQePi6NK9P7ovCSxRkz+eY9nyqm/V7dImOcfa5abX3B45/7ZaqbPlcPwm66SMpJUb 5hiuSVvVskBvknL/prO+9Ubsay+/4312br1KeOuc/cqnbUL4LS8HZcxY+POhVtn2i9bSsW87 dBs6mD9cO8l2vvna/oju7cveWS978VfoNIcSS3FGoqEWc1FxIgDVVCEe3AIAAA== Archived-At: Subject: [saag] kitten report for IETF 99 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 00:54:30 -0000 kitten is not meeting in Prague. We have not published any new RFCs since Chicago, but sent draft-ietf-kitten-rfc5653bis to the IESG. A related document sent to curdle to avoid conflict-of-interest due to dual author/chair role (draft-ietf-curdle-des-des-des-die-die-die) is in IETF LC. A newly adopted document (draft-ietf-kitten-krb-spake-preauth) and an older one (draft-ietf-kitten-channel-bound-flag) are seeing implementation experience and nearly done. We should also try to finish up work moving some Kerberos and GSS-API registries to IANA, as well as our other adopted WG items. We are also in the middle of a search for a new co-chair to replace Matthew Miller -- thanks for your long service, Matt! -Ben From nobody Thu Jul 20 00:37:01 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B0D126557 for ; Thu, 20 Jul 2017 00:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oF-cxeVoOhkl for ; Thu, 20 Jul 2017 00:36:57 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 8A6A0126CD6 for ; Thu, 20 Jul 2017 00:36:57 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id f21so10583626wrf.5 for ; Thu, 20 Jul 2017 00:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=sKB+bkaaiLrE3xTgn+kLjKN4QpggevnZP9pyOwasa78=; b=VwkjDdmQLwPPdi6i3NKDS1e8k8Nt1L+W+EexriL3l07G0+CoBJNIaXBC71nXwVXvGu EdDq0Xx9JAInqvrWDwH8SMuVXwktlX5zYAKf/kwy1DyGFnlVdWBpKwD0twUFQgLhC7zL LWEnVaiQ1krq/Uc4XjS14qvndPNhvRpLewVzbIXWHCH17PjDmt2JqkLIKodXN7zCQmNh l9dnMv3zjD9IxovZDecYZWLptoWNEiwBOc65Mx1X5K6ls8G4J2JpnvS9d1AfvTq5StPR o69LjsJn+TBYSZBfm3zFPYxE5Es8jVj0+jjc+UMc/z5ZcP7S6tlJVXFcCTnaRZ21pI+Q YX0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=sKB+bkaaiLrE3xTgn+kLjKN4QpggevnZP9pyOwasa78=; b=ulyKDuhEdb4kStyJJYYwQxt5ZEkVqOVx5eOtxakkfbtmL7uucePfTFLUcxw+JKcxEc xdawPTFxaDp7ZSWAYfnGZDY5gfT1q2n36az/1nFZHpodDxFuRZn8TEfhVfnsEzUJQaZg KrhRM3/YsGtGLHOsEqy4cFFm76yDivAQOSwdpNU7MSLfc7NKZovdCjh2MaIz1tfu2y2t zj6lHYFWZAMvLcTBohUN6P4iDCbRWTIAFAWieBg7lJ5D1iSutGUcTG1LjronQDXSAXXT DQzqNg9vSHiN2i1JopEAxeYqPu8UGky9KcV2KiO4YK1siqV10oGffj7h4EzLMqQyMG9r o8rg== X-Gm-Message-State: AIVw111GcxV6PaCD9wzb2WV1DBY0qvTSJx5gA0UwpuY3VXxR3lPZA9wN NYXD739YHU7/TsUdcBQ= X-Received: by 10.223.165.13 with SMTP id i13mr5795464wrb.35.1500536215908; Thu, 20 Jul 2017 00:36:55 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:65d2:bbb4:f4:d0dd? ([2001:67c:370:128:65d2:bbb4:f4:d0dd]) by smtp.gmail.com with ESMTPSA id l8sm1821600wmd.15.2017.07.20.00.36.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 00:36:55 -0700 (PDT) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_AB2246F4-AD57-4481-9A1E-083B1A70F109"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <15172DBF-3B87-4A65-B02A-E14A80D105F8@gmail.com> Date: Thu, 20 Jul 2017 09:36:53 +0200 To: Security Area Advisory Group X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [saag] ACME report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 07:36:59 -0000 --Apple-Mail=_AB2246F4-AD57-4481-9A1E-083B1A70F109 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The ACME working group will meet on Friday morning. As a wise man once said, it=E2=80=99s tough to make predictions, = especially about the future, but we predict that the main ACME document = and the CAA document are done, and we=E2=80=99ll confirm this on the = list, and hopefully send them to Kathleen real soon. The working group has recently adopted a bunch of new, smaller = documents. They were discussed as potential WG items at the virtual = interim meeting that we had on June 2nd, and are now WG drafts. We = predict that most os the meeting time will be spent on them. =E2=80=94 The ACME chairs --Apple-Mail=_AB2246F4-AD57-4481-9A1E-083B1A70F109 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZcF2WAAoJELhJCxUKWMyZlrwIAJKMfsI47CYHfr84IuAURUAF aBTe9N7BuFIkNw77f7iXwjpds5GLjhwMpiFsw7lX9mOqU00hq87BKT2zj8biHldl nPcLFBbwpUBudZGnCqdrkxrNwOFtYXxYIx0Io1FniK9/wcn4CICwP+Q1Hxw+b5Gi STgx2eT0HyeEZDNcz2hbJcqARHVmxCNp5oq6jS5W7e1cduBm78KCbcgU04UjEAer 9FvUiVdcspE0ojUFAJ31YWemkdgUytgCyd3NtKtHrGMFwjSzG8MSpaPeutm0RDFz R2UYvPYUMDNZg++j1++jCC/OamunxJkA8xT2IL7jTvCaYnPqYOyBgZT0W4oP2rk= =DuUa -----END PGP SIGNATURE----- --Apple-Mail=_AB2246F4-AD57-4481-9A1E-083B1A70F109-- From nobody Thu Jul 20 01:01:10 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2969512ECCB for ; Thu, 20 Jul 2017 01:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjZdtZPLfWgf for ; Thu, 20 Jul 2017 01:01:07 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 CDAA9126557 for ; Thu, 20 Jul 2017 01:01:06 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v6K8112c019110 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 20 Jul 2017 11:01:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v6K8110C029905; Thu, 20 Jul 2017 11:01:01 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22896.25405.439751.149939@fireball.acr.fi> Date: Thu, 20 Jul 2017 11:01:01 +0300 From: Tero Kivinen To: saag@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 12 min X-Total-Time: 13 min Archived-At: Subject: [saag] IPsecME report for IETF 99 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:01:09 -0000 IPsecME has not yet met in Prague, but we will be meeting on last slot on Friday. We have 3 documents in the RFC editor queue: Mandatory implement algorithms in IKEv2 (RFC4307bis), Mandatory to implement algorithms in IPsec (RFC7321bis), and tcp encapsulation. Then we have one new document submitted for publication: EdDSA for IKEv2. Split DNS and implicit IV drafts are getting ready for the WGLC, and we should be able to start WGLC quite soon after the IETF. That leaves us with one accepted charter item to work with, i.e., the quantum resistant methods for IKEv2. We have quite finished draft about how to use PSKs to make IKEv2 quantum resistant, so that work is progressing. In addition there has been new work starting on the non-PSK based methods too. In addition to the chartered items, we have several new work items, for which we need to decide whether there is enough interest to work on those (diet ESP, Responder intiated mobike update). We are going to be do rechartering before the end of the year (our charter is expiring by the end of year), so we will need to decide which of those items are going to be included in new charter. -- kivinen@iki.fi From nobody Thu Jul 20 01:19:34 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C3A127869 for ; Thu, 20 Jul 2017 01:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnLVz6uXcZIO for ; Thu, 20 Jul 2017 01:19:32 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 BBE61126557 for ; Thu, 20 Jul 2017 01:19:31 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v6K8JTlg002613 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 20 Jul 2017 11:19:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v6K8JT8F017518; Thu, 20 Jul 2017 11:19:29 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22896.26513.537791.830674@fireball.acr.fi> Date: Thu, 20 Jul 2017 11:19:29 +0300 From: Tero Kivinen To: saag@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 18 min Archived-At: Subject: [saag] TEEP report for IETF 99 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:19:33 -0000 A Protocol for Dynamic Trusted Execution Environment Enablement (TEEP) had BoF in Chicago IETF 98, and we decided not to have second BoF here, but instead aim to have 2nd BoF in Singapore (we were not ready by the time the BoF requests needed to be in). After that we have had several webinars explaining the TEEP, and we had TEEP tutorial on Sunday [3]. We had sidemeeting here in Prague, to work on the charter. There were about 20 people present in the sidemeeting, plus few participating remotly, and we bashed the charter to something that in the end was acceptable for to the people present. Using high bandwidth face-to-face time for this kind of work seemed very efficient, compared trying to work it through the email list. The proposed charter [2] is now posted to the TEEP mailing list [1], so I encourage interested people to go there and review and comment on it. Depending on how the discussions go on with the charter, we are either having 2nd BoF in Singapore or we might even form the WG before that and have first WG meeting in Singapore. [1] https://www.ietf.org/mailman/listinfo/teep [2] https://mailarchive.ietf.org/arch/msg/teep/Xy5ftFayb4gX6XM9ewQSZFVx2Kc [3] https://www.ietf.org/proceedings/99/slides/slides-99-edu-sessi-trusted-execution-environments-tee-and-the-open-trust-protocol-otrp-01.pdf To summarize what TEEP is here is cut & paste of the tutorial abstract: ---------------------------------------------------------------------- Chips used on smart phones, tablets, and many consumer appliances today have built-in support for a so-called Trusted Execution Environment (TEE). It is a security concept that separates normal operating systems, like Linux, from code that requires higher security protection, like security-related code. The underlying idea of this sandboxing approach is to have a smaller codebase that is better reviewed and test and to provide it with more rights. They run on the so-called Secure World (in comparison to the Linux operating system that would run in the Normal World). TEEs have been on the market for a while and have been successfully used for a number of applications, such as payment. However, the technology hasn't reached its full potential the market is quite fragmented with vendors offering a larger number of real-time operating systems running in a TEE. With the Open Trust Protocol we have been trying to develop an application layer security protocol that allows the management (install, update, delete) of trusted applications running on the TEE. In this talk we will explain the concept of TrustZone (as one example of a widely deployed technology offering sandboxing) and the Open Trust Protocol. -- kivinen@iki.fi From nobody Thu Jul 20 01:25:53 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37C713157A for ; Thu, 20 Jul 2017 01:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrTI28YDBny7 for ; Thu, 20 Jul 2017 01:25:42 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 352F3129B3A for ; Thu, 20 Jul 2017 01:25:39 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id t2so10920394qkc.1 for ; Thu, 20 Jul 2017 01:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=0oDBAvphmoCtK9ToMsvvN+jRHiuH9lAx28ENERlrMzQ=; b=Q4nc8+YAIPj2XeZd1S67bhkjDwYgw3ddfVi09/fTegrX2iVi7g81xQ46Co9RCzhlzt 9UDpVt9MhnguFJLOg45BLpYOiXmVdQ0CfD4xwl+0aWuIq2MoQ++MK45dFi/rKuIKO/oj XaGA0zJtlPCsHejA9S+1eh3bFwi6G0sk9l6C0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0oDBAvphmoCtK9ToMsvvN+jRHiuH9lAx28ENERlrMzQ=; b=B7OGP5W+xFN1trKg+MMQXZXgCqXAOdP2Ebr8WJBJJ/+bATwh47skqIkY24VglX2YR5 V8RFtQIMCVaAMlITPwVFHxYIe9xjqseu1QHTCPIndZox/dRL+Vy5E73g6s++cBk4dp4h wf9Xjz/kyfXBYvg2F+uwGPyLnKySWa3mXbINUJPwt2G0hbA1ztFOOKY86f9TTygqD19+ qjLKeTz4NWhdF/cCttasA0NutktrHzGeFGqklncfLzD35YRbPd0P4SU0fgEqbWwC+Qeu rR8ebf+cccXTWx5krIMBW3/MNr4k2a2oD23y8Z9O9UbUEO+Tb9qUDzJryCamKMP+2OSJ o6Qg== X-Gm-Message-State: AIVw113/HKU9kSCTsWHAfAgeoMeGeW2fAcqtdWZyMbqy5a2vEol9cEtw yKrQf5XyFOfPcYxdsSZK+9mSMTGHQQz+0ng= X-Received: by 10.55.76.193 with SMTP id z184mr3888268qka.146.1500539137869; Thu, 20 Jul 2017 01:25:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.128.194 with HTTP; Thu, 20 Jul 2017 01:25:37 -0700 (PDT) X-Originating-IP: [2001:67c:370:128:9408:fae9:f3a2:51ce] From: Kyle Rose Date: Thu, 20 Jul 2017 10:25:37 +0200 Message-ID: To: saag@ietf.org Content-Type: multipart/alternative; boundary="001a114a896c48ddb40554bb7e60" Archived-At: Subject: [saag] TCPINC report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:25:48 -0000 --001a114a896c48ddb40554bb7e60 Content-Type: text/plain; charset="UTF-8" TCPINC did not meet at IETF 99. The chairs submitted publication requests for the two main drafts (TCP-ENO and tcpcrypt) in early June. The remaining milestone is to complete and request publication of an informational abstract API draft. Kyle --001a114a896c48ddb40554bb7e60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
TCPINC did not meet at IETF 99.

The= chairs submitted publication requests for the two main drafts (TCP-ENO and= tcpcrypt) in early June. The remaining milestone is to complete and reques= t publication of an informational abstract API draft.

Kyle
=
--001a114a896c48ddb40554bb7e60-- From nobody Thu Jul 20 01:54:42 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69797129562 for ; Thu, 20 Jul 2017 01:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyBrmo4c04KD for ; Thu, 20 Jul 2017 01:54:39 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3118B127735 for ; Thu, 20 Jul 2017 01:54:39 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id q85so10005610pfq.1 for ; Thu, 20 Jul 2017 01:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=rQJrflPVnBJUYz0YVW5rCvX1SP9PLbbwemlpHokPsL8=; b=lnM+AIdlyt8IpwI/ineotM4Nv6+e6lWNOFLyqKsNrug9R91mswcCXp1C24fezfxrQr mjilzGdyC/mUlvbyyxOM04jBq2ezEsezlClTOIznrHP12dZ5RRNnj8k0A9lLFzXyEHv0 lgtV9Jr8usNudQ76xk9f9KyPAEmzxjQNc9gT8iVNBgAVt2AY8MVRPHZLb9B692ziHgz5 1hKPluAbncbpFrkvBa6BHzdmFjuVmAuogIyO27t5ZRS+nv+BwDihG9aTLMz3TWDzx6qb gpWHr+V604x+TlcEwDxS064LHK/lwP+IQbzGP8v7+zIwpnja6lSGNBNgH+2xk8ylQ49j HiZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=rQJrflPVnBJUYz0YVW5rCvX1SP9PLbbwemlpHokPsL8=; b=GYsSdKkr335/qGWTpzt8ELqNA8I4ihx7U7zJ6gl6boB7bYY5NFQgOy2bV3HJp/xM4z qaKe7izrgXeoQ/LIUNhQIwAIJ5iz/kp6tHeE0X1GYhCSkHylEYigQhshysGBctt/mwD2 Wa6ssGLfZRnUQWXZUcb0x6lFa7pP7JZMrTHqpFNyggkhzpMaL9S+zNIPy4SegnLO1+gu DTjBDtcBiEdkdc8M38Ldug0nhQ14/U5amllG5ybrJ3QmzD0Vn1Rv4Kzv4gm4s1JnHjV8 pi7d5fprASbbnfGXPcVM422yOPAZ8qbEqTqgIry+l1IIdoBFBwUTLaWyv7UD6AAV9q1N uCug== X-Gm-Message-State: AIVw111DlAF+1/whEeI/RFhmh3OZ1WYct3fkg3TsNVTACHBauUUqTVG8 Ph7unZCZt81B+BMujDV2p6kDAI2RNzvfVaQ= X-Received: by 10.84.231.15 with SMTP id f15mr3420816plk.253.1500540878580; Thu, 20 Jul 2017 01:54:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.137.2 with HTTP; Thu, 20 Jul 2017 01:54:18 -0700 (PDT) From: Joseph Salowey Date: Thu, 20 Jul 2017 10:54:18 +0200 Message-ID: To: "saag@ietf.org" Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403043607d809ff140554bbe6af" Archived-At: Subject: [saag] SAAG TLS working group report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:54:40 -0000 --f403043607d809ff140554bbe6af Content-Type: text/plain; charset="UTF-8" TLS met on Monday afternoon and Wednesday morning. For TLS 1.3, the document has completed second working group last call. There are ongoing measurements to resolve the last open issue which we believe should complete in 1-2 months. Work on DTLS is going well and we expect it to go to the IESG later this year. DNSSEC chain validation and exported authenticators work is nearing completion. The group examined various options for SNI encryption and decided to take it on as a working group item. We had presentations on the pros and cons of a proposed mechanism to decrypt TLS messages within the data center. A hum indicated that there was roughly equal support on both sides. Therefore, well will continue the discussion and it is unlikely that the draft will proceed in its current form. --f403043607d809ff140554bbe6af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

TLS met on Monday afternoon = and Wednesday morning.=C2=A0 For TLS 1.3, the document has completed second= working group last call.=C2=A0 There are ongoing measurements to resolve t= he last open issue which we believe should complete in 1-2 months.=C2=A0 Wo= rk on DTLS is going well and we expect it to go to the IESG later this year= .=C2=A0 DNSSEC chain validation and exported authenticators work is nearing= completion.=C2=A0 =C2=A0The group examined various options for SNI encrypt= ion and decided to take it on as a working group item.=C2=A0 =C2=A0We had p= resentations on the pros and cons of a =C2=A0proposed mechanism to decrypt = TLS messages within the data center.=C2=A0 =C2=A0A hum indicated that there= was roughly equal support on both sides.=C2=A0 Therefore, well will contin= ue the discussion and it is unlikely that the draft will proceed in its cur= rent form.

=C2=A0

--f403043607d809ff140554bbe6af-- From nobody Thu Jul 20 02:43:42 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B91131667 for ; Thu, 20 Jul 2017 02:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6dzayKsa6HN for ; Thu, 20 Jul 2017 02:43:39 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E68131AD7 for ; Thu, 20 Jul 2017 02:43:37 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v6K9hZYR007338 for ; Thu, 20 Jul 2017 05:43:36 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu v6K9hZYR007338 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1500543816; bh=/xg5jlyBR64WeIgrL9itUZvbE2PkE3FYN1N/0Fywxmo=; h=From:To:Subject:Date:From; b=qnsXfbo2yg2yWPy/yaWz2lphhg1psfVFubbHn2M3dNQz+FW55XVqU4/MKH3uKmz88 u0yzRu/r3H9tUk7+OedVhnl+4TIDE2+s715YduMiktGYffsFGtHKoAQX8WB+4WOpqX Jy1nK8srHrmFTwzdTxDsP4auPGdKr7Sho6TwJ3RM= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v6K9hZhY017477 for ; Thu, 20 Jul 2017 05:43:35 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0351.000; Thu, 20 Jul 2017 05:43:34 -0400 From: Roman Danyliw To: "saag@ietf.org" Thread-Topic: DOTS IETF99 report Thread-Index: AdMBNqoFbvpaCdmuSNirB8kotUnuwA== Date: Thu, 20 Jul 2017 09:43:34 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104FA0B57@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] DOTS IETF99 report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:43:40 -0000 DOTS will meet during the Afternoon II session, today (Thursday, July 20th)= . Since Chicago, DOTS adopted two protocol drafts (draft-ietf-dots-data-chann= el, draft-ietf-dots-signal-channel), and had participants in the Hackathon = implementing them. The background use case (draft-ietf-dots-use-cases), architecture (draft-ie= tf-dots-architecture), and requirements (draft-ietf-dots-requirements) draf= ts are approaching WGLC. Regards, Roman and Tobias From nobody Thu Jul 20 02:45:21 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F0A131A81 for ; Thu, 20 Jul 2017 02:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 SAR-S9IFB_PQ for ; Thu, 20 Jul 2017 02:45:19 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13885131667 for ; Thu, 20 Jul 2017 02:45:19 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id l7so9820909iof.1 for ; Thu, 20 Jul 2017 02:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OB2WNI0qzgicp2JLnBWbCRbqdSyrHe3bGDo6fwo7syc=; b=Up5SpBfTm9lSdM3TAOI/yBe7kQBPudrt+UYzWi8gMFzMRzXste6IXLF0mUaXJ/5CmW j1dcClYwBQSVuH24tSh8wAjcmcabfmTX5ZOfMmBSROjNIrcYg2lKhkp28yCYp/0K3JLw K3qmDBbGN1hlebcrG2CUy/dFx+fr863MCBYzh4S6mYMa41ydMDjVwacotcu2i8PehgFM PJPMYUceLPGqDm6F3mVZgUyJSJ3nHHmrac+T6xGJxlK7Vf7HRTp1pHsMrFjdeKQeZvSt q8pKRud25Cc7waq1fuszXBBV7jYEDh6+BiCMPOws4/ZAUtsZf+lztwwbhaQ96WxQLDp2 3RgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OB2WNI0qzgicp2JLnBWbCRbqdSyrHe3bGDo6fwo7syc=; b=RQzNeg50WgQrHIO+pa/ReJNx07H71/wuMywLoEPBDZxmJbHy7BQF3kyozgAHHT4v9+ 8f3wKCeQprG6VomAwYyJI5dUi6ElCWeGv8Lx8OyGbqwo+3lE5k4gNKm4DkHCV1AhLWEY /1RVM+4U1RNHMIrDJe1MBFeoHmBZgJ8JBAP2PkiT1m9gxajfBIbyLfUHMPUhh2sKY6Ix GYMyDF6s0c1MVS0tIETpKSwBzhvr2zFDk8WYT4IdI7LeEZ/6gnZXNlWt3Rgl4ynpq0P8 kjB/nxSx6+NUsJ78sYf8o9TIgYLrtAw7uzOUu18CvfZYBSbyXyQmtpQSMWUlHumYMlJE LEoA== X-Gm-Message-State: AIVw1102GtMQT5cIzDORKPbB49TjpMNiV0Bp5/c0WDuBtVR88JYmdbz2 afVT5YXrl7v8Ry3dCudPRWCGFEGDdq+3 X-Received: by 10.107.19.148 with SMTP id 20mr3244483iot.0.1500543917947; Thu, 20 Jul 2017 02:45:17 -0700 (PDT) MIME-Version: 1.0 From: Adam Montville Date: Thu, 20 Jul 2017 09:45:06 +0000 Message-ID: To: saag Content-Type: multipart/alternative; boundary="001a113f8dc0330a000554bc9b62" Archived-At: Subject: [saag] SACM WG Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:45:20 -0000 --001a113f8dc0330a000554bc9b62 Content-Type: text/plain; charset="UTF-8" SACM met today to review the result of our successful hackathon efforts and to discuss the working group's renfined focus and scope, which directly affects the disposition of existing work items. We have distilled our focus areas down to three: 1) Collection, 2) Evaluation, 3) Orchestration/Messaging. This will help us determine a method of posture assessment over varying mechanisms. Our way forward includes using these three categories to focus work items and milestones. They will also be used to guide integrating the two SACM-related hackathon efforts into a more robust showing for the IETF 100 hackathon. --001a113f8dc0330a000554bc9b62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
SACM met today to review the result of our successful hack= athon efforts and to discuss the working group's renfined focus and sco= pe, which directly affects the disposition of existing work items. We have = distilled our focus areas down to three: 1) Collection, 2) Evaluation, 3) O= rchestration/Messaging. This will help us determine a method of posture ass= essment over varying mechanisms. Our way forward includes using these three= categories to focus work items and milestones. They will also be used to g= uide integrating the two SACM-related hackathon efforts into a more robust = showing for the IETF 100 hackathon.
--001a113f8dc0330a000554bc9b62-- From nobody Thu Jul 20 02:55:35 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0CA131A4C for ; Thu, 20 Jul 2017 02:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWcpULZC_2mg for ; Thu, 20 Jul 2017 02:55:32 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 4E105127735 for ; Thu, 20 Jul 2017 02:55:32 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id y43so68516875wrd.3 for ; Thu, 20 Jul 2017 02:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=99++jAl1cKBZLiBw8WxNBakKf8+mfmx3tLMSNYG4sGU=; b=JgVvgCS2/e/M5SFZHdgRJNbn0WAEKcR410H7B7iMr8lNk4+s3pdP9Yv4uoF+OyNEuI UxsrigQFJ5te3rYwZd5cUY/vR4A+VcumNgD4tDgvu84Zsjk+9vXaXjOEqa693RLw9O5z CrzSUQeyG221aobzai/D0OeHGvQi7ldb3WAX6+1yRNQr/tkPZlrTUi8xGVFcgwZPUTmW sdmW4V1K8JrT7mmZc8Z6JPPQISbnxdy3OWD966Yw1a4TxBSt7IsLing6YQ9YIrFnuRUp q2tCyOjPGuhxqC37GnxlcQBKhBzdIcpunPBtaJYiTK8BOrsdqyjN/twjmk0AJlburx3x 89Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=99++jAl1cKBZLiBw8WxNBakKf8+mfmx3tLMSNYG4sGU=; b=D+VbnB7pd2MjhHJWDorjHNtN+/7Q8lG9Jai5rMx2sH04FUtS1VyzII/VoEm6DH6wSU hB0dPd2v9ev1PvxAUYWCzCklSD+4d3dEIv2eNOEnqZQygJ7AJgAvIptVrEuuB2ydOXUS FS+IBRSWYT6TtR4unSr6CPfSztyy3z3kJPUoLz0U7eEwEk6tJS6Z/iuZ3ggU/PYMBrB9 BYKvACegGjb/KV4UpfqQ6FKAhkkpJYONIyT7UncuZ2DF3ESMFaAN1N+acaEiCsbXmVEV bOe1ydVbxybD7wJjEyJRn2Ai3GuIud4DOobeQ3eLDcLvWzWvS3dAjK7D/Aegsjkir26g H1xg== X-Gm-Message-State: AIVw1137XrBVhSc50f3W4CyT+u4xsY/lPWlzT8Gz6x9akhnFg65rJEYn 2U7efch9GTYt6UIy2qo= X-Received: by 10.223.136.108 with SMTP id e41mr2588964wre.218.1500544530563; Thu, 20 Jul 2017 02:55:30 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:831:3f5f:7444:1c30? ([2001:67c:1232:144:831:3f5f:7444:1c30]) by smtp.gmail.com with ESMTPSA id h1sm5195044wrb.25.2017.07.20.02.55.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 02:55:30 -0700 (PDT) To: saag@ietf.org From: Yaron Sheffer Message-ID: Date: Thu, 20 Jul 2017 11:55:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [saag] SecEvent WG report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:55:34 -0000 The group met Tuesday morning. We made very good progress since Chicago, improving the SET document (specifically around security: preventing confusion with other JWTs) and untangled the higher level of the protocol. Thanks to a bunch of authors who worked hard on these drafts! In the session we heard about the latest rev of the SET document and hummed to move it to WGLC, adopted a draft on HTTP delivery of events, discussed a management API and two use case documents. Dick and Yaron From nobody Thu Jul 20 02:57:17 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EF1131BF7 for ; Thu, 20 Jul 2017 02:57:15 -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] 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 jdlg6DJFeJtS for ; Thu, 20 Jul 2017 02:57:13 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE426127735 for ; Thu, 20 Jul 2017 02:57:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1EDFA30050A for ; Thu, 20 Jul 2017 05:57:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZE2lYDwC_BHP for ; Thu, 20 Jul 2017 05:57:12 -0400 (EDT) Received: from [5.5.33.144] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id EC44F300278 for ; Thu, 20 Jul 2017 05:57:11 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <73164840-2D16-4C54-AEAB-8D8959FAF994@vigilsec.com> Date: Thu, 20 Jul 2017 05:57:12 -0400 To: IETF SAAG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [saag] LAMPS WG Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:57:15 -0000 All current work items have been sent to the IESG: a) draft-ietf-lamps-rfc5280-i18n-update b) draft-ietf-lamps-eai-addresses c) draft-ietf-lamps-rfc5750-bis d) draft-ietf-lamps-rfc5751-bis We considered potential items for a re-charter: a) rfc6844bis -- a lot of interest in moving forward. b) Adding SHAKE to PKIX and S/MIME -- quite a bit of interest in = moving forward. c) Define a first-issued certificate extension -- very little = interest. From nobody Thu Jul 20 03:20:09 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B973D131C04 for ; Thu, 20 Jul 2017 03:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 QQ4C1ubPuQcg for ; Thu, 20 Jul 2017 03:20:05 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0061.outbound.protection.outlook.com [104.47.2.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01628131BFA for ; Thu, 20 Jul 2017 03:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SFuwu/H/XaZ/Kkoowjhbtof1vUvJ0xbmcaiwhb3xlMA=; b=Ne3k1J6BkJQcDWK9hu6QUxFHOhesbPexPCETU+kwTIlEbgKi1e4P0Ruj4LA94cokkDR/4JbctXONNQQeWdpoh5CvdkgNPaosctwJW76jHccbobeEh6wzLEryeUfw99VafnR5qSDBG1E6j3A6M50Nxn6M7RD1Ond/qpHMjL9RW40= Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com (10.168.2.156) by AM4PR0301MB1907.eurprd03.prod.outlook.com (10.168.3.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Thu, 20 Jul 2017 10:20:01 +0000 Received: from AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a]) by AM4PR0301MB1906.eurprd03.prod.outlook.com ([fe80::482:61a:3f1b:be7a%14]) with mapi id 15.01.1261.024; Thu, 20 Jul 2017 10:20:01 +0000 From: "Paterson, Kenny" To: saag CC: "cfrg@irtf.org" Thread-Topic: CFRG report from IETF99 Thread-Index: AQHTAUG/nrwJR++nlEmj0kW0KhMR2g== Date: Thu, 20 Jul 2017 10:20:01 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=rhul.ac.uk; x-originating-ip: [31.133.147.39] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1907; 7:2ocQfHZ10UrIl13sEZXPPGgHPN856fT47U+qUzMQBQNKq2RNlzWKQN+zRiI539u5LzC9rx7Y16EK7I3AEdgKGwmigXQ0wgDXMa1H7/Aa0oJG9wsRh4Y5pvkRozbwyXA7Li4FVeVTCpSAq3REIrlmPem0uYeZehcsU/m7j7Sh0RmzGPNVOzXhlADM2fD2A49LGQV/eF977vW+8Iou/11q8+UwLYH6Pcf57+AxtQ/ViSMv+2lgfYm+kY5gpDi9uu5GSDBqGcqFaj4Jg2ViczF2eX+7KaxdfEseLTB6GDp2zhSikEAFBq1Wy37+Eb9cg5pYdMiHGIuLkLdvd1zVuIL4Sz3eAkemqD1rJXKNBbGZjxlfqZJ5Iz//WS9JRflTkioAq97xKqn+aEAm7UgUO4sNtlbEfiGAcH+CiWp8eN3Y83S61nWg1kTnGgCL8LK91fIUfGzirWolSVM4izgfnIagrmEEfStvD61+sAHz/FsKVNDZB27sO979NbhxyYwQLbACDq7xcnswa8ijqoFdxs3phCVGW0Z69tBJcf9ioqQ2DV7aXnfKdIeO+MCpzpZ6owNSfuf8ICCnQVV31vEcmVV6rGZc/r4bNXCpA4yCOSTMhOLQP0gWZ8vzCzC3X3njv9l5goVPuoLgFLsdcx1fRcxsqvVqV5rMKS/twaFmW7VlMRwu9CPuL0DJmc847Q/IGjko+aRzh3SPODvPTIYdGbUtIgYPtj6PhMBHlXR2Lu8ECnaviK2zXZNPYfJ7rCxh+xuecd7G5pamjq2ljDuXQdxO53smQhKKtl0shywAutzrxVo= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(979002)(6009001)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(6436002)(7736002)(305945005)(25786009)(4001350100001)(14454004)(110136004)(38730400002)(6512007)(99286003)(8936002)(8676002)(81166006)(102836003)(6116002)(4326008)(36756003)(74482002)(3280700002)(5660300001)(2900100001)(2906002)(3660700001)(114624004)(83506001)(478600001)(6506006)(86362001)(6916009)(50986999)(3846002)(189998001)(6486002)(54356999)(53936002)(5250100002)(66066001)(72206003)(42882006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1907; H:AM4PR0301MB1906.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 3d7b4287-e68f-4c56-8cfa-08d4cf58e1e3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR0301MB1907; x-ms-traffictypediagnostic: AM4PR0301MB1907: x-exchange-antispam-report-test: UriScan:(278178393323532)(133145235818549)(236129657087228)(148574349560750)(167848164394848); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(2017060910075)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR0301MB1907; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR0301MB1907; x-forefront-prvs: 0374433C81 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7D356937BBD20C4EAFDAE108E38FCAD6@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 10:20:01.9159 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1907 Archived-At: Subject: [saag] CFRG report from IETF99 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 10:20:08 -0000 Q0ZSRyBtZXQgb24gVHVlc2RheSBhZnRlcm5vb24uDQoNCkNoYWlycyBnYXZlIGFuIHVwZGF0ZS4g U2luY2Ugb3VyIGxhc3QgbWVldGluZyBpbiBTZW91bCwgd2UgaGF2ZSB0d28gbmV3DQpSRkNzIGZy b20gdGhlIGdyb3VwOg0KKiBSRkMgODAzMjogRWR3YXJkcy1jdXJ2ZSBEaWdpdGFsIFNpZ25hdHVy ZSBBbGdvcml0aG0gKEVkRFNBKQ0KKiBSRkMgODEyNTogUmVxdWlyZW1lbnRzIG9uIFBBS0Ugc2No ZW1lcw0KDQpUd28gZG9jdW1lbnRzIGFyZSBpbiBJUlNHIHJldmlldw0KKiBkcmFmdC1pcnRmLWNm cmcteG1zcy1oYXNoLWJhc2VkLXNpZ25hdHVyZXMtMDkgKHVwZGF0ZWQpOiBYTVNTOiBFeHRlbmRl ZA0KSGFzaC1CYXNlZCBTaWduYXR1cmVzDQoqIGRyYWZ0LW5pci1jZnJnLXJmYzc1MzliaXMtMDEg KHVwZGF0ZWQpOiBDaGFDaGEyMCBhbmQgUG9seTEzMDUgZm9yIElFVEYNClByb3RvY29scw0KDQpU aGUgd29yayBvbiBBcmdvbjIgYW5kIEFFUy1HQ00tU0lWIGlzIHByb2dyZXNzaW5nIHNtb290aGx5 IGFuZCB3ZSBzaG91bGQNCm1vdmUgdG8gbGFzdCBjYWxsIHNvb24uDQoNClRoZSBDRlJHIHJldmll dyBwYW5lbCBpcyB3b3JraW5nIHdlbGwsIHByb2R1Y2luZyB0aW1lbHkgYW5kIGRldGFpbGVkDQpy ZXZpZXdzIHRvIGhlbHAgaW1wcm92ZSBDRlJHIGRyYWZ0cy4NCg0KV2UgaGFkIGEgdmFyaWV0eSBv ZiBwcmVzZW50YXRpb25zIG9mIG5ldyBhbmQgb24tZ29pbmcgd29yayBvZiBpbnRlcmVzdCB0bw0K dGhlIGdyb3VwLiANCg0KKiBUaGUgd29yayBvbiAiUmUta2V5aW5nIE1lY2hhbmlzbXMgZm9yIFN5 bW1ldHJpYyBLZXlzIg0KKGRyYWZ0LWlydGYtY2ZyZy1yZS1rZXlpbmcpIGlzIHByb2dyZXNzaW5n IHdlbGw7IFN0YW5pc2xhdiBTbXlzaGx5YWV2DQpwcm92aWRlZCBhbiB1cGRhdGUgb24gcHJvZ3Jl c3MgYW5kIHBsYW5zLg0KDQoqIFNoYXJvbiBHb2xkYmVyZyBwcmVzZW50ZWQgb24gVlJGcyAoZHJh ZnQtZ29sZGJlLXZyZi0wMSkuIFRoZXJlIHdhcw0Kc3Ryb25nIHN1cHBvcnQgaW4gdGhlIHJvb20g Zm9yIGFkb3B0aW9uIG9mIHRoZSBkb2N1bWVudCBhcyBhIENGUkcgZHJhZnQuDQpDaGFpcnMgd2ls bCB0YWtlIHRoaXMgdG8gdGhlIGxpc3QuDQoNCiogRGF2aWQgTWNHcmV3IHByZXNlbnRlZCBvbiAi SGFzaC1CYXNlZCBTaWduYXR1cmVzIg0KKGRyYTEtbWNncmV3LWhhc2gtc2lncy0wNyksIG5vdGlu ZyB0aGF0IGlzIGFscmVhZHkgYSBDRlJHIGRyYWZ0IGFuZA0KcmVxdWVzdGluZyB0aGF0IGl0IGdv IHRvIGxhc3QgY2FsbC4gQ2hhaXJzIHdpbGwgZG8gc28gYW5kIGluIHBhcmFsbGVsDQpjb21taXNz aW9uIHJldmlld3MgYnkgdGhlIENGUkcgcmV2aWV3IHBhbmVsIGFuZC9vciBvdGhlcnMuDQoNCkFk ZGl0aW9uYWwgcHJlc2VudGF0aW9ucyBpbmNsdWRlZDoNCg0KKiBCcnlhbiBGb3JkOiAiQ29sbGVj dGl2ZSBFZHdhcmRzLUN1cnZlIERpZ2l0YWwgU2lnbmF0dXJlIEFsZ29yaXRobSINCihkcmFmdC1m b3JkLWNmcmctY29zaS0wMCksDQoqIEtlbm55IFBhdGVyc29uIGZvciBQYXVsIEhvZmZtYW4sICJU aGUgVHJhbnNpdGlvbiBmcm9tIENsYXNzaWNhbCB0bw0KUG9zdC1RdWFudHVtIENyeXB0b2dyYXBo eSIgKGRyYWZ0LWhvZmZtYW4tYzJwcSkNCiogUXV5bmggRGFuZyBmb3IgQmVub2l0IFZpZ3VpZXIs ICJLYW5nYXJvb1R3ZWx2ZSINCihkcmFmdC12aWd1aWVyLWthbmdhcm9vdHdlbHZlLTAwKQ0KKiBE YW4gQnJvd24sICJFQ0MgbW9kIDheOTErNSIgYW5kICJEaWZmaWUtSGVsbG1hbiBtb2QgNjMwKDQy NyErMSkrMSINCg0KDQoNCg0K From nobody Thu Jul 20 04:30:47 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5761912EC30 for ; Thu, 20 Jul 2017 04:30:46 -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 Bq7WnxsaOKlc for ; Thu, 20 Jul 2017 04:30:45 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 A0A4D131A86 for ; Thu, 20 Jul 2017 04:30:44 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id l81so6593972wmg.1 for ; Thu, 20 Jul 2017 04:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=iPDW4GXPnXDwtot7A+aPufCJHf2R3gx5y+KcVaN7Qws=; b=SZ9ZmONuN0nDrwDkJwgU1MI0TMeIDgN6yRSLQvBY+OD2qXDwiltEC7HFDZTtr1tN8r wvHs8fy+8zGvxbv5udXrp4HsjvZ/BZOMEXmSXSX12ZuOJlUxKLz8OCCazjIH7EK6Mjmm s6b/NmDcdMPJOLVIrLgdUfAurXkWgGhPrchMUpK9KSeaCg2sbQWZ3j4GOLwSe6Dd9A4p EtcAkviemnAaKtx506MWfd4hbslHV8/Z/jkQ9gN5AA8e3l0CN38Wd9H9wHXdt2e1B+iS iUIUv58zemdcrJBh2y887LEzakF07J85dYip5pOF2y7hJ9OZ1YGXj+N/g3+AULj753R/ MumA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=iPDW4GXPnXDwtot7A+aPufCJHf2R3gx5y+KcVaN7Qws=; b=aGrjPKtWrZvpIcKMRJ855h/Z9S4Y6HbChqPBEgJriJdtLSPCL8MkIz6k7kbeIWzn+u BLyqX3JVhyLSGRMPrAucnJH5CWyF2IVrLl8yxCKingduNu7Ro0TYLZg09rFBCcOBqDVG u8WdoTh7qA3XGP0CE35nDvE1/G9ncm4ucwlq5lhUNqsyE2np2fotXoPQ8bTd2SebZMyb 8gel4q9PpKPu+G8v1BC9b25LBoVHYDD6V2xDvAywKukXBKi+KCdIDgi/lksjC5XXsJYf 9sSiCFJBPuk12l96DqpIWa8PaTD9WLIYVWfaqZF8pg80LKeU7Y5DBkSe6WN5C79a+WiL Jr0g== X-Gm-Message-State: AIVw112VSpLLOa7x8rk4RbDmFZ2JMx594XsIb9ycGg2ak8Shkeuz7nQc dgFbqT9Z28+bpZKbfXY= X-Received: by 10.28.16.148 with SMTP id 142mr2145250wmq.6.1500550242598; Thu, 20 Jul 2017 04:30:42 -0700 (PDT) Received: from dhcp-80d4.meeting.ietf.org ([2001:67c:370:128:f7:3ec1:636a:28cd]) by smtp.gmail.com with ESMTPSA id 125sm2072755wmp.37.2017.07.20.04.30.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 04:30:41 -0700 (PDT) To: saag@ietf.org From: Melinda Shore Message-ID: <446f99ec-1ff2-1fb3-cea4-2b8744e9eecd@gmail.com> Date: Thu, 20 Jul 2017 13:30:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pAkej2trc4wfSqtNk4lDDCqq5Hq5QXcUM" Archived-At: Subject: [saag] trans wg summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:30:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pAkej2trc4wfSqtNk4lDDCqq5Hq5QXcUM Content-Type: multipart/mixed; boundary="JViTJBFCMBDPb6MVc2nx8eeeHU4VdiFNw"; protected-headers="v1" From: Melinda Shore To: saag@ietf.org Message-ID: <446f99ec-1ff2-1fb3-cea4-2b8744e9eecd@gmail.com> Subject: trans wg summary --JViTJBFCMBDPb6MVc2nx8eeeHU4VdiFNw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The trans working group met briefly on Wednesday. The major deliverable for the group, 6962-bis, has completed working group last call with no major problems identified. The threat document needs minor revisions before being put back into wglc. A major piece of outstanding work is a client behavior document, but we don't have a candidate draft and otherwise we are getting close to being able to close up shop. Melinda --JViTJBFCMBDPb6MVc2nx8eeeHU4VdiFNw-- --pAkej2trc4wfSqtNk4lDDCqq5Hq5QXcUM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZcJRgAAoJELiGRpM6HoEupU8QAJbi+b4AGYizvo/gTStx7kSa btk5ncmK8/aS8hrwGTpOw02YyrvxJXwNdRE2tTGrPoS2SrUyVP4etBtL64kFVF+R pqstV2geR70zcDknmax1mzpaISU8jTJ0iS0fMpG0vabN5uyGFCrWsK87rtSqdxOE r6joTEQOLqhB/SDW3Q4vmvfRDgkp54UAkhqzn9vn1UXCIjxXsb1vvWKFW3uqljE1 i7niNaKA2Ow9AacLIONjNsq7Edrt73wJZuNtTln0NP1IdT0NI2f2YhSH7c9J+wG2 twOTu4W7JZJIV/BoEysdbaPIVq7dJOrBICg/Cm3O2cV7vXBM5J8sLNt69GRIIRe+ StFgMGsQ+anKFKFIv3cq/sYGosEw6fHvdhEq6BqLgf5JkCJKI0RSKHNUfMcI1+MG iy5uQuzN/5O035Iij07oEZWHRuMbcc0kbCEKt4V1Nvya9QaxhDLtOis9JO2W3ywL HeQPEEhV4O1agvMt09eovV0SMRHd9/6Eca6jLhYbOXIpGY4eEmqdlHYNjhM0mB7t 9v6XrxOS7IgD5E4G/ddNf5t5NYbBn3mNNxZn2YC8XthEL4X/QIwVA+oXhlXiqRdZ N9tWocYoSADPA48zVKVYJYZfNADD/Ipdzb6RMIOCjn9W73y9dCRqGySzV1DWzazY AQ7NQnYuc8ImLrg1laHM =g0Jz -----END PGP SIGNATURE----- --pAkej2trc4wfSqtNk4lDDCqq5Hq5QXcUM-- From nobody Thu Jul 20 04:35:24 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA0D131C1A for ; Thu, 20 Jul 2017 04:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 b3-L5Uya81ew for ; Thu, 20 Jul 2017 04:35:13 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id BE11012969E for ; Thu, 20 Jul 2017 04:35:12 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id DAC013740FB2 for ; Thu, 20 Jul 2017 07:35:11 -0400 (EDT) From: "Dr. Pala" To: "saag@ietf.org" Organization: OpenCA Labs Message-ID: <8c734c87-2e57-c43d-e1bd-92f3c4ddeae3@openca.org> Date: Thu, 20 Jul 2017 13:35:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F988A8FDD1CFC82BD678BB27" Content-Language: en-US Archived-At: Subject: [saag] Considerations about the need to resume PKIX work X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:35:22 -0000 This is a multi-part message in MIME format. --------------F988A8FDD1CFC82BD678BB27 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, I would like to draw the Sec Area attention on an issue that I think is becoming more relevant every day. It seems quite clear that today there is a lot of work around authentication and encryption that make use of PKIX certificates. However, there is no place in IETF, today, where problems related to PKIX can be effectively tackled. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussion around the feasibility of resuming the work in two particular areas: revocation and discoverability. *The Problem *What I noticed in recent proposals in many working groups (when it comes to certificate management) is that more and more people turn towards the use of short-lived certificates to avoid checking revocation information. Sometimes this choice is motivated by real technical considerations, but in many cases the choice is "forced" because nobody is currently working on fixing the two main issues related to trust infrastructures: efficient revocation and discoverability of services. *The Revocation Situation* Most of the times, when interacting with PKIs, we are still stuck with CRLs, OCSP if we are lucky (including stapling - available in TLS connections if really really lucky), and in most cases even these mechanisms are criticized widely by people as being inadequate today. This resulted in applications to use proprietary methods for checking revocation (e.g., CRLSet) or to skip checking all together (or mandate for short-lived certificates only as in the case, for example, of STIR). Many people today ignore the fact that, when coupled with small devices, the generation of new keys require (a) a lot of resources, and (b) a good source of randomness. Requiring apps / devices to generate new keys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of key management ? /Examples of possible work to address the issues are OCSP over DNS and some more efficient ways to verify the validity of a whole chain of certificates efficiently./ *The Discoverability Situation* As far as I know, there are no standardized mechanisms that would provide discoverability of services that would help users and applications to discover Public Key Services providers and associated services in a dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be discussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS). Isn't that curious that still today nobody is working on some sort of infrastructure that would facilitate interacting with PKIs ? After all, PKIs are the core Trust mechanism that enables reliable authentication and encryption over the Internet today. Such infrastructure could really improve the security of the Internet and make PKIs more usable from an application (and users) standpoint of view. /Examples of possible work to address the issue are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-configuration support for PK)./ *Deployment Trends in the Real World* Today I am witnessing the deployment of arguably not-well-designed PKIs (or, in other terms, what I call Weak PKIs) that do not provide support for revocation and that are expected to use CAs and EE certificates with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that it is a common assumption that the algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT going to pass the test of time, ignoring the revocation could really affect the privacy of millions of people - and we are currently not doing anything at the IETF to prevent this issue. /There is the need for simple revocation services, but arguably we do not have what's needed today (requires improvements)./ *IETF Specific Situation and Issues* Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in PKI discussions) that these might be some of the main reasons: * *There are NO venues where to discuss possible solutions to existing problems.* The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above) * *The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow scoped Charters and only few items**(mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular).* Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons. * *The constant**nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. *It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them. Moreover, things are happening in environments outside IETF (WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these problems is really scary to me. The world moves forward, fast, and the IETF is standing still on this topic./*I really do not understand why.*/ *Final Considerations* In this message I try to summarize the reasons why I think there is the need to provide a venue where these problems are discussed and the need for key people to not actively block the possibility for people that are willing to work on this to have a venue where the work can be carried out. I think that this work is of the utter importance and I would like to understand what the position of the whole security area is around these points and the proposed work. /I hope that the discussion around this message can spark some interest and that work in the PKIX area can finally resume at the IETF - which was, in the past, thought of as the lighthouse where these issues could be addressed./ A small request, please, try to read this e-mail carefully and consider the implications of NOT taking on these tasks when replying and/or discussing the topic. Also, since I know this (PKIX) is a minefield for "political" reasons (which should not be a drive here), please keep the discussion on the positive / constructive side (thanks). /If you feel like a private response is better than on the mailing list, please just reply privately./ Looking forward to hear your opinions on this hoping that this e-mail can be the beginning of the end of PKIX still-standing issues :D Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------F988A8FDD1CFC82BD678BB27 Content-Type: multipart/related; boundary="------------E2F8C0FF3A6C78EB2A336174" --------------E2F8C0FF3A6C78EB2A336174 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi all,

I would like to draw the Sec Area attention on an issue that I think is becoming more relevant every day.

It seems quite clear that today there is a lot of work around authentication and encryption that make use of PKIX certificates. However, there is no place in IETF, today, where problems related to PKIX can be effectively tackled. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussion around the feasibility of resuming the work in two particular areas: revocation and discoverability.

The Problem

What I noticed in recent proposals in many working groups (when it comes to certificate management) is that more and more people turn towards the use of short-lived certificates to avoid checking revocation information. Sometimes this choice is motivated by real technical considerations, but in many cases the choice is "forced" because nobody is currently working on fixing the two main issues related to trust infrastructures: efficient revocation and discoverability of services.

The Revocation Situation

Most of the times, when interacting with PKIs, we are still stuck with CRLs, OCSP if we are lucky (including stapling - available in TLS connections if really really lucky), and in most cases even these mechanisms are criticized widely by people as being inadequate today. This resulted in applications to use proprietary methods for checking revocation (e.g., CRLSet) or to skip checking all together (or mandate for short-lived certificates only as in the case, for example, of STIR).

Many people today ignore the fact that, when coupled with small devices, the generation of new keys require (a) a lot of resources, and (b) a good source of randomness. Requiring apps / devices to generate new keys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of key management ?

Examples of possible work to address the issues are OCSP over DNS and some more efficient ways to verify the validity of a whole chain of certificates efficiently.

The Discoverability Situation

As far as I know, there are no standardized mechanisms that would provide discoverability of services that would help users and applications to discover Public Key Services providers and associated services in a dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be discussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS).

Isn't that curious that still today nobody is working on some sort of infrastructure that would facilitate interacting with PKIs ? After all, PKIs are the core Trust mechanism that enables reliable authentication and encryption over the Internet today. Such infrastructure could really improve the security of the Internet and make PKIs more usable from an application (and users) standpoint of view.

Examples of possible work to address the issue are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-configuration support for PK).

Deployment Trends in the Real World

Today I am witnessing the deployment of arguably not-well-designed PKIs (or, in other terms, what I call Weak PKIs) that do not provide support for revocation and that are expected to use CAs and EE certificates with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that it is a common assumption that the algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT going to pass the test of time, ignoring the revocation could really affect the privacy of millions of people - and we are currently not doing anything at the IETF to prevent this issue.

There is the need for simple revocation services, but arguably we do not have what's needed today (requires improvements).

IETF Specific Situation and Issues

Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in PKI discussions) that these might be some of the main reasons:

  • There are NO venues where to discuss possible solutions to existing problems. The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above)

  • The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow scoped Charters and only few items (mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular). Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons.

  • The constant nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them.

Moreover, things are happening in environments outside IETF (WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these problems is really scary to me. The world moves forward, fast, and the IETF is standing still on this topic. I really do not understand why.

Final Considerations

In this message I try to summarize the reasons why I think there is the need to provide a venue where these problems are discussed and the need for key people to not actively block the possibility for people that are willing to work on this to have a venue where the work can be carried out.

I think that this work is of the utter importance and I would like to understand what the position of the whole security area is around these points and the proposed work.

I hope that the discussion around this message can spark some interest and that work in the PKIX area can finally resume at the IETF - which was, in the past, thought of as the lighthouse where these issues could be addressed.

A small request, please, try to read this e-mail carefully and consider the implications of NOT taking on these tasks when replying and/or discussing the topic. Also, since I know this (PKIX) is a minefield for "political" reasons (which should not be a drive here), please keep the discussion on the positive / constructive side (thanks).

If you feel like a private response is better than on the mailing list, please just reply privately.

Looking forward to hear your opinions on this hoping that this e-mail can be the beginning of the end of PKIX still-standing issues :D

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------E2F8C0FF3A6C78EB2A336174 Content-Type: image/png; name="efhklhncoknghhph.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="efhklhncoknghhph.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------E2F8C0FF3A6C78EB2A336174-- --------------F988A8FDD1CFC82BD678BB27-- From nobody Thu Jul 20 05:45:27 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BD11315FF for ; Thu, 20 Jul 2017 05:45:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=nistgov.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 QwdY4xdMYCWk for ; Thu, 20 Jul 2017 05:45:23 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0122.outbound.protection.outlook.com [23.103.201.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B779131892 for ; Thu, 20 Jul 2017 05:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MAYDV1WT6R9nOgceI92rzwyzgVg+yB8dl4WCwZ0Tm7A=; b=Kw7lXNP7AtTs7exdOq4SSLJ+wVDd9+0PTRrcb2oToqVeKXVDMIZdWGHC7kd/B1cwDyASDZi32FAbsIB8BnHsYluzOx1xBShW2myPJQ+M+wnXyP5AjwfWg4Gu1i047uaiJbSn17PV2T6orCMWMtJXRz6jY55e5ScCewF9YILva+8= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1461.namprd09.prod.outlook.com (10.173.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Thu, 20 Jul 2017 12:45:22 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.1261.024; Thu, 20 Jul 2017 12:45:21 +0000 From: "Dang, Quynh (Fed)" To: "saag@ietf.org" Thread-Topic: NIST's IPR statements requirement for PQC selection process. Thread-Index: AQHTAVYMoDoBPD4JUEuGGDsW3SgykA== Date: Thu, 20 Jul 2017 12:45:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2001:67c:370:128:f0d3:dc16:e459:83a7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:9Dce9o0WW8rf9jcPC5d8nHMnQ5fFSpPB4+IuxdYDuMc+stNBfs6yN9zOJqdHOsPeF4WbOO+tOrPJbNeBv4uTk6JW6VxDGYBjsg08zZVQFRb78tgELGdMSzrvjccfrMgaOebaCy51gtEqrsi+HiU7374Kw2tWE2vUOUqbj+rmroGT/dqEWbQR2yxnMnOT3OmWchYWMFP14Gj/uwqvoeh6J+I3UeXHqKl9XDLpTiVKTrHOtAPnJFy1lG4O6ar6KHjG8azxhvqJCNU7HTws+Q0S28J2f63SGVz273wklGDwrFdhY9tuHqSDEnleV66UMeypH4+WYqlhtXtoYEfLgySE5U1eGjyAHhfJNfgnYLcQlNnORgWiWV/4SDKH4WklE9wKmF9QbNroHV+FKi4GWfD9kx9zTw/IrQx2bUBCCHaJAmbt35TAHZ55tQVBJq66JxPtLK4Cx+7lynhYP4nmE+U5ZV5rejlYrDidAZeJ9De3Ry50W00ObxDIEz8dDW51X5OYg00THIAovGY5G23KkNY7b9YVSjNMknn1O0azERotrl/9yoX6yGDFcMv3eul5CYAYEBLA3jdxRLG4RAyiET0ngbv7c1uIGTQEQRpt/a9gxqRU6cTK0rqwUX2r0HiHdCu/5XepsAfvF4HbSGBvUF19ItjLIn0/Gj6xS1xLUBP8WaVqNQ2saJP8fks2h96D/8lu2kz+/CV5gwiBTdvBcmeNNxLh1Gt3LquYcqdmU9mZ7CJa7ptAID7/rAx8Bq57mV90Xm+LbJZ1a3IpegE5uwAR5nzqjJHFXTCbEIXwIR048Ek= x-ms-office365-filtering-correlation-id: 80e9d8ee-f038-4cf2-8eb2-08d4cf6d2f5c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR09MB1461; x-ms-traffictypediagnostic: CY4PR09MB1461: x-exchange-antispam-report-test: UriScan:(65766998875637)(236129657087228)(131022147185803)(50300203121483); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1461; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39840400002)(39450400003)(39850400002)(39400400002)(53754006)(19627405001)(6306002)(25786009)(966005)(55016002)(2501003)(54896002)(6436002)(8936002)(5640700003)(102836003)(236005)(53336002)(6116002)(110136004)(53936002)(38730400002)(99286003)(86362001)(9686003)(6506006)(2906002)(77096006)(5660300001)(6916009)(6606003)(478600001)(54356999)(189998001)(7736002)(3280700002)(606006)(33656002)(50986999)(2900100001)(74316002)(3660700001)(8676002)(4743002)(81166006)(14454004)(1730700003)(2351001)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR09MB1464437F2A06A98CA5805183F3A70CY4PR09MB1464namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 12:45:21.7343 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1461 Archived-At: Subject: [saag] NIST's IPR statements requirement for PQC selection process. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:45:26 -0000 --_000_CY4PR09MB1464437F2A06A98CA5805183F3A70CY4PR09MB1464namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Below is a link to the IPR statements requirement. Regards, Quynh. http://csrc.nist.gov/groups/ST/post-quantum-crypto/submission-requirements/= intellectual-property.html submission requirements - NIST.gov csrc.nist.gov pqc - submission requirements Intellectual Property Statements / Agreements= / Disclosures. Each submitted algorithm, together with each submitted refe= rence ... --_000_CY4PR09MB1464437F2A06A98CA5805183F3A70CY4PR09MB1464namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,


Below is a link to the IPR statements requirement.


Regards,

Quynh. 


http://csrc.nist.gov/groups/ST/post-quantum= -crypto/submission-requirements/intellectual-property.html

csrc.nist.gov
pqc - submission requirements Intellectual Property Statements / Agreements= / Disclosures. Each submitted algorithm, together with each submitted refe= rence ...


--_000_CY4PR09MB1464437F2A06A98CA5805183F3A70CY4PR09MB1464namp_-- From nobody Thu Jul 20 05:52:23 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB8012EBFA for ; Thu, 20 Jul 2017 05:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 p3j1qnUIXGoQ for ; Thu, 20 Jul 2017 05:52:20 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE176129B43 for ; Thu, 20 Jul 2017 05:52:20 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 20 Jul 2017 05:52:18 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 20 Jul 2017 05:52:18 -0700 From: Paul Hoffman To: "saag@ietf.org" Thread-Topic: Classical-to-post-quantum draft Thread-Index: AQHTAVcEGsePPS3A1U+WulYUKsvaZg== Date: Thu, 20 Jul 2017 12:52:16 +0000 Message-ID: <75FD8929-D0D6-497D-AF0D-D3112C91081E@icann.org> 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: [192.0.47.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] Classical-to-post-quantum draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:52:22 -0000 The draft that I spoke about in the SAAG meeting is: https://datatracker.ietf.org/doc/draft-hoffman-c2pq/ Important note: this draft doesn't, and won't, cover post-quantum algorithm= s, just the timing of when people need to start using them. There have already been some good comments, particularly on terminology, an= d additions since this version of the draft came out, but the next draft wi= ll still be full of holes. If you (or folks you know) are familiar with qua= ntum computing, please contribute! --Paul Hoffman= From nobody Thu Jul 20 06:06:17 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90A712EBFA for ; Thu, 20 Jul 2017 06:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 800zgEani8oD for ; Thu, 20 Jul 2017 06:06:11 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52172126E3A for ; Thu, 20 Jul 2017 06:06:11 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id w45so22414640uac.5 for ; Thu, 20 Jul 2017 06:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9nLOx+0jw6ghqTSw1TLJJlXhXsGiP5Fi8YcI+FmBUf4=; b=W75HV+ZikRWFdLEtD7BqrSuusTIlZ/TPl1DEWvg6txoErs35h2fnOuCuVByOKwRQkO pUhZBVpPLBOmsbiI3FWioyqCTn7gyuCsbNJh/+SCmntiE0U+iBgUJUD8+YiugAymetV+ HZLgwCSDjZ4x4ElaFLym+upjLjmtY6tZOI6/cFN3+vE7cxJLwyWR37CUBz+GLiBnZVei e4QgX+6sel/ObYUUgQwqQ7lqtVy4IBpsH8waG+6edA4rPJ9TB2J+W5ilPOyOtqhkxtfd nl+IsmIRW4UV7GxPq46k+anXbWAclJr1oNUgeQQNMAvLV2eXNNt5FYrQwhm02GO7Nm96 EX0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9nLOx+0jw6ghqTSw1TLJJlXhXsGiP5Fi8YcI+FmBUf4=; b=aVooddmdbvF99s/frUJAO61ay0J/0lpYS47Q/M/mAeoZTl/WgAqJ1ELR4u0C4cd3zw bY7vUl2b8JM69dZETExrriDr5IIPkWt3N7oYLgw1Pp2muAdHC1mthTFb1UEoIbVEUVGh DaISTe/tkx93tXAz1rrjsgJnzpvyy4EDig29to+IW3hVbsrYB+r1Mn1iqRSsHJnjDcJP +uJHa5oXgy0gMs0IiP5nNDIm0Q5fC/i9dJ/lLvTyUwsbarrG7tWVV9ZtbBIxOY/eUXuh HaSRId5YcYRlZ9UMYRC0Hb52pOdUxaEq5trjQrqofiYYltZasGd1t8XJ3ik44dRD3UZk cpCQ== X-Gm-Message-State: AIVw110PXHVPeKw44aeDoCEgtuvkkyD9T3TG9VNjAPSF+9TWf3O+lXWQ Kyc3nhDVrJEXStF0Aa1Yz6yHya6kh7Kv X-Received: by 10.31.194.210 with SMTP id s201mr1942519vkf.2.1500555970099; Thu, 20 Jul 2017 06:06:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.35.80 with HTTP; Thu, 20 Jul 2017 06:05:49 -0700 (PDT) In-Reply-To: <8c734c87-2e57-c43d-e1bd-92f3c4ddeae3@openca.org> References: <8c734c87-2e57-c43d-e1bd-92f3c4ddeae3@openca.org> From: Bernard Aboba Date: Thu, 20 Jul 2017 06:05:49 -0700 Message-ID: To: "Dr. Pala" Cc: "saag@ietf.org" Content-Type: multipart/related; boundary="001a11439adc90640e0554bf69fd" Archived-At: Subject: Re: [saag] Considerations about the need to resume PKIX work X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 13:06:15 -0000 --001a11439adc90640e0554bf69fd Content-Type: multipart/alternative; boundary="001a11439adc90640c0554bf69fc" --001a11439adc90640c0554bf69fc Content-Type: text/plain; charset="UTF-8" Thank you very much for your thoughtful note. I share a number of the concerns you have articulated, particularly about the increasing proliferation of poorly-thought-through certificate schemes, both within IETF and outside of it. While it is not clear to me that having an IETF forum for discussion of PKIX issues would necessarily reverse these trends (since dubious schemes began to proliferate while PKIX WG was active, particularly in the wireless arena), I believe your concerns are real and deserve thorough discussion. In general, the IETF likes WGs to operate with narrow charters for finite periods of time, whereas some other SDOs maintain standing groups with broad charters for long periods. This makes it possible for widely deployed protocols to not have an active IETF WG (although sometimes mailing lists may remain operational). When a WG is active, Chairs have a tendency to strongly encourage a focus on topics relating to the Charter so as to encourage forward progress. This can lead to IETF WGs being ineffective in reviewing related work in other IETF WGs, let alone in other SDOs. One potential solution to your concerns might be to create a WG to deal with "PKIX extensions". However, if the core need is to create a forum which can be used to strengthen PKI utilization both in the IETF and outside of it, this may not be sufficient. For example, provision may need to be made for review of specifications (e.g. "PKIX doctors"), or for suitable liaison arrangements so as to encourage cooperation between SDOs on PKI topics. With respect to the meme that "PKIs do not work", my observation is that the IETF seems to pay more attention to developments in the "big I" Internet, than to developments within "little i" internets, such as private deployments in enterprise. Part of the reason is that participation within IETF among users has been in decline for a very long time. Without that customer participation, it can be difficult for the IETF to assess protocol success. However, having been involved in some of the world's largest PKI deployments, I think it is safe to say that PKI can be considered "successful" if not "widely successful" by the criteria of RFC 5218. On Thu, Jul 20, 2017 at 4:35 AM, Dr. Pala wrote: > Hi all, > > I would like to draw the Sec Area attention on an issue that I think is > becoming more relevant every day. > It seems quite clear that today there is a lot of work around > authentication and encryption that make use of PKIX certificates. However, > there is no place in IETF, today, where problems related to PKIX can be > effectively tackled. In the following paragraphs I try to summarize the > issue and the proposed work and a call for discussion around the > feasibility of resuming the work in two particular areas: revocation and > discoverability. > > > > *The Problem *What I noticed in recent proposals in many working groups > (when it comes to certificate management) is that more and more people turn > towards the use of short-lived certificates to avoid checking revocation > information. Sometimes this choice is motivated by real technical > considerations, but in many cases the choice is "forced" because nobody is > currently working on fixing the two main issues related to trust > infrastructures: efficient revocation and discoverability of services. > > *The Revocation Situation* > > Most of the times, when interacting with PKIs, we are still stuck with > CRLs, OCSP if we are lucky (including stapling - available in TLS > connections if really really lucky), and in most cases even these > mechanisms are criticized widely by people as being inadequate today. This > resulted in applications to use proprietary methods for checking revocation > (e.g., CRLSet) or to skip checking all together (or mandate for short-lived > certificates only as in the case, for example, of STIR). > > Many people today ignore the fact that, when coupled with small devices, > the generation of new keys require (a) a lot of resources, and (b) a good > source of randomness. Requiring apps / devices to generate new keys might > seem a good idea at first, but is this better than checking revocation ? > What about the complexity of key management ? > > *Examples of possible work to address the issues are OCSP over DNS and > some more efficient ways to verify the validity of a whole chain of > certificates efficiently.* > > *The Discoverability Situation* > > As far as I know, there are no standardized mechanisms that would provide > discoverability of services that would help users and applications to > discover Public Key Services providers and associated services in a dynamic > fashion. When I brought it up during the BoFs of possible working groups > where the issue could be discussed.. well, the proposal was redirected to > /dev/null (e.g., ACME, SPASM, and LAMPS). > > Isn't that curious that still today nobody is working on some sort of > infrastructure that would facilitate interacting with PKIs ? After all, > PKIs are the core Trust mechanism that enables reliable authentication and > encryption over the Internet today. Such infrastructure could really > improve the security of the Internet and make PKIs more usable from an > application (and users) standpoint of view. > > *Examples of possible work to address the issue are a PKI Resource Query > Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms > for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - > 0-configuration support for PK).* > > *Deployment Trends in the Real World* > > Today I am witnessing the deployment of arguably not-well-designed PKIs > (or, in other terms, what I call Weak PKIs) that do not provide support for > revocation and that are expected to use CAs and EE certificates with > validity periods of 30, 35, or 50 years (yes, also EE - especially for > devices). Besides the fact that it is a common assumption that the > algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT > going to pass the test of time, ignoring the revocation could really affect > the privacy of millions of people - and we are currently not doing anything > at the IETF to prevent this issue. > > *There is the need for simple revocation services, but arguably we do not > have what's needed today (requires improvements).* > > *IETF Specific Situation and Issues* > > Why are we so unprepared to face these issues ? I would say (still > personal point of view - based on almost 20 yrs of participation in PKI > discussions) that these might be some of the main reasons: > > - *There are NO venues where to discuss possible solutions to existing > problems.* The PKIX working group has been closed down (very > arbitrarily, I might say, since there is still a lot of work needed to be > done around PKIX as highlighted above) > > - *The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very > narrow scoped Charters and only few items** (mostly quite marginal > issues, IMO) are actually accepted as working items (w/ reference to SPASM > and LAMPS in particular).* Solving revocation and discoverability > issues should be the 1st item and the most important on the list (at least > revocation) but they are not - actually when that was proposed to be > included as part of the charter(s), the requests were not even acknowledged > or rejected with no real technical reasons. > > - *The constant** nonsense of people saying that PKIs do not work as > an excuse not to improve them while they (PKIs) are the reason we can > deploy secure protocols and provide privacy. *It is evident that PKIs > are here to stay, this is a fact. Their usage has increased exponentially > in the past years and they have, so far, passed the test of time. IoT is > one use-case. ANIMA is another. ACME is another. Just to cite few of them. > > Moreover, things are happening in environments outside IETF (WIFI 2.0 > Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these > problems is really scary to me. The world moves forward, fast, and the IETF > is standing still on this topic.* I really do not understand why.* > > *Final Considerations* > > In this message I try to summarize the reasons why I think there is the > need to provide a venue where these problems are discussed and the need for > key people to not actively block the possibility for people that are > willing to work on this to have a venue where the work can be carried out. > I think that this work is of the utter importance and I would like to > understand what the position of the whole security area is around these > points and the proposed work. > > *I hope that the discussion around this message can spark some interest > and that work in the PKIX area can finally resume at the IETF - which was, > in the past, thought of as the lighthouse where these issues could be > addressed.* > > A small request, please, try to read this e-mail carefully and consider > the implications of NOT taking on these tasks when replying and/or > discussing the topic. Also, since I know this (PKIX) is a minefield for > "political" reasons (which should not be a drive here), please keep the > discussion on the positive / constructive side (thanks). > > *If you feel like a private response is better than on the mailing list, > please just reply privately.* > > Looking forward to hear your opinions on this hoping that this e-mail can > be the beginning of the end of PKIX still-standing issues :D > > Cheers, > Max > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > [image: OpenCA Logo] > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --001a11439adc90640c0554bf69fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you very much for your thoughtful note.=C2=A0
I share a number of the concerns you have articulated, particu= larly about the increasing proliferation of poorly-thought-through certific= ate schemes, both within IETF and outside of it.=C2=A0 While it is not clea= r to me that having an IETF forum for discussion of PKIX issues would neces= sarily reverse these trends (since dubious schemes began to proliferate whi= le PKIX WG was active, particularly in the wireless arena), I believe your = concerns are real and deserve thorough discussion.=C2=A0

=
In general, the IETF likes WGs to operate with narrow charters for fin= ite periods of time, whereas some other SDOs maintain standing groups with = broad charters for long periods.

This makes it pos= sible for widely deployed protocols to not have an active IETF WG (although= sometimes mailing lists may remain operational).=C2=A0 When a WG is active= , =C2=A0Chairs have a tendency to strongly encourage a focus on topics rela= ting to the Charter so as to encourage forward progress.=C2=A0 This can lea= d to IETF WGs being ineffective in reviewing related work in other IETF WGs= , let alone in other SDOs.=C2=A0

One potential sol= ution to your concerns might be to create a WG to deal with "PKIX exte= nsions".=C2=A0 However, if the core need is to create a forum which ca= n be used to strengthen PKI utilization both in the IETF and outside of it,= this may not be sufficient.=C2=A0 For example, provision may need to be ma= de for review of specifications (e.g. "PKIX doctors"), or for sui= table liaison arrangements so as to encourage cooperation between SDOs on P= KI topics.=C2=A0

With respect to the meme that &qu= ot;PKIs do not work", my observation is that the IETF seems to pay mor= e attention to developments in the "big I" Internet, than to deve= lopments within "little i" internets, such as private deployments= in enterprise.=C2=A0 Part of the reason is that participation within IETF = among users has been in decline for a very long time.=C2=A0 Without that cu= stomer participation, it can be difficult for the IETF to assess protocol s= uccess.=C2=A0 However, having been involved in some of the world's larg= est PKI deployments, I think it is safe to say that PKI can be considered &= quot;successful" if not "widely successful" by the criteria = of RFC 5218.=C2=A0



<= br>

On Thu, Jul 20, 2017 at 4:35 AM, Dr. Pala <director@openca.org&g= t; wrote:
=20 =20 =20

Hi all,

I would like to draw the Sec Area attention on an issue that I think is becoming more relevant every day.

It seems quite clear that today there is a lot of work around authentication and encryption that make use of PKIX certificates. However, there is no place in IETF, today, where problems related to PKIX can be effectively tackled. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussion around the feasibility of resuming the work in two particular areas: revocation and discoverability.

The Problem

What I noticed in recent proposals in many working groups (when it comes to certificate management) is that more and more people turn towards the use of short-lived certificates to avoid checking revocation information. Sometimes this choice is motivated by real technical considerations, but in many cases the choice is "forced&= quot; because nobody is currently working on fixing the two main issues related to trust infrastructures: efficient revocation and discoverability of services.

The Revocation Situation

Most of the times, when interacting with PKIs, we are still stuck with CRLs, OCSP if we are lucky (including stapling - available in TLS connections if really really lucky), and in most cases even these mechanisms are criticized widely by people as being inadequate today. This resulted in applications to use proprietary methods for checking revocation (e.g., CRLSet) or to skip checking all together (or mandate for short-lived certificates only as in the case, for example, of STIR).

Many people today ignore the fact that, when coupled with small devices, the generation of new keys require (a) a lot of resources, and (b) a good source of randomness. Requiring apps / devices to generate new keys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of key management ?

Examples of possible work to address the issues are OCSP over DNS and some more efficient ways to verify the validity of a whole chain of certificates efficiently.

The Discoverability Situation

As far as I know, there are no standardized mechanisms that would provide discoverability of services that would help users and applications to discover Public Key Services providers and associated services in a dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be discussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS).

Isn't that curious that still today nobody is working on some sort of infrastructure that would facilitate interacting with PKIs ? After all, PKIs are the core Trust mechanism that enables reliable authentication and encryption over the Internet today. Such infrastructure could really improve the security of the Internet and make PKIs more usable from an application (and users) standpoint of view.

Examples of possible work to address the issue are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-configuration support for PK).=

Deployment Trends in the Real World

Today I am witnessing the deployment of arguably not-well-designed PKIs (or, in other terms, what I call Weak PKIs) that do not provide support for revocation and that are expected to use CAs and EE certificates with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that it is a common assumption that the algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT going to pass the test of time, ignoring the revocation could really affect the privacy of millions of people - and we are currently not doing anything at the IETF to prevent this issue.

There is the need for simple revocation services, but arguably we do not have what's needed today (requires improvements).=

IETF Specific Situation and Issues

Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in PKI discussions) that these might be some of the main reasons:

  • There are NO venues where to discuss possible solutions to existing problems. The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above)

  • The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow scoped Charters and only few items (mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular). Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons.

  • The constant nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them.

Moreover, things are happening in environments outside IETF (WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these problems is really scary to me. The world moves forward, fast, and the IETF is standing still on this topic. I really do not understand why.

Final Considerations

In this message I try to summarize the reasons why I think there is the need to provide a venue where these problems are discussed and the need for key people to not actively block the possibility for people that are willing to work on this to have a venue where the work can be carried out.

I think that this work is of the utter importance and I would like to understand what the position of the whole security area is around these points and the proposed work.

I hope that the discussion around this message can spark some interest and that work in the PKIX area can finally resume at the IETF - which was, in the past, thought of as the lighthouse where these issues could be addressed.

A small request, please, try to read this e-mail carefully and consider the implications of NOT taking on these tasks when replying and/or discussing the topic. Also, since I know this (PKIX) is a minefield for "political" reasons (which should not be a driv= e here), please keep the discussion on the positive / constructive side (thanks).

If you feel like a private response is better than on the mailing list, please just reply privately.

Looking forward to hear your opinions on this hoping that this e-mail can be the beginning of the end of PKIX still-standing issues :D

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA

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


--001a11439adc90640c0554bf69fc-- --001a11439adc90640e0554bf69fd Content-Type: image/png; name="efhklhncoknghhph.png" Content-Disposition: inline; filename="efhklhncoknghhph.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ed9f042db1982b2f_0.0.1.1 iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/ MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp 7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91 aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6 yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV 2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7 QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7 qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6 vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP 7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90 1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K +f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA AAAASUVORK5CYII= --001a11439adc90640e0554bf69fd-- From nobody Thu Jul 20 06:11:27 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208AA12EBF7 for ; Thu, 20 Jul 2017 06:11:26 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 VjIGA1ns7KGa for ; Thu, 20 Jul 2017 06:11:24 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97973126E3A for ; Thu, 20 Jul 2017 06:11:24 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id p188so26420885oia.0 for ; Thu, 20 Jul 2017 06:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5JFEriOxziC/i3vtypooDQyfz33WolJ7x3kQqSqH1QA=; b=Fi0Dde7EAPqI4mwnvY80xUVrNk0LzEaXzmcIW87aJOakO6VBSKrJCWvs8HyI/ygfui QHOd9YpkwZB9l1Qc7kywalsgr426sj4Mcr87q7YTzkbL3pPlUhudZvaHeRxsVH+quiT5 ZUaWPX3YnWPWJ2JxXR7ST0VXmtxflWhHG9JREf+dR9JbHR8KyF17/m/kr4e5nnSC2QOT ACkCd1xa+71szBbD5iJ7AFEbbf1KOXmS7gB0F4JTME4GvPVaVZpT+1fCOxt2D8XqzXA5 koxBHqUFrCqwKFKub51plUG2rXl1KH0b8L7sFm7ugt5f01U9XCnA+a0ezW89yJ3pq+Dg Sy7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5JFEriOxziC/i3vtypooDQyfz33WolJ7x3kQqSqH1QA=; b=Titd2wxtHHVg2naHfRrtFOLVjx3WYzI7MoblsW+QXqdnIh7T0+mcRwdVsjdFI22TRS 5NIVoqEuhUMckHoFNKubnrwxVid50aMW+xGO2f7mQ17qsz2v7MKpkswSgLl6Mz4U85+L 89XT/a9nS7MZmfzkbCp8cvhCqLpwssNDPGEmmZbBracfLrlNkea2t0N4QSwA7i4xok14 xNMHJcHNnh2D5T9bm7GoLlwiVOeuNLDlKuBWKoZZe13cwPhzRJwGZ6nDJtdIgzE5Ij3l YMCRrgKztVWLEjm/nEY32dP+RVPqh//l5fAwemUlJgWeDVdiOgVdB7qsr6bpuVnYeZWD yiaw== X-Gm-Message-State: AIVw111ZB+ED9gU/r77qwd5+bRSJVMzQVFL2DG+0++WqgbdTuWzZXmTa Xu+q5G59/msQN/STj/lJSkvlOjb2ThqBPaQ= X-Received: by 10.202.196.130 with SMTP id u124mr3946559oif.79.1500556283658; Thu, 20 Jul 2017 06:11:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.237.18 with HTTP; Thu, 20 Jul 2017 06:11:23 -0700 (PDT) From: Dmitry Belyavsky Date: Thu, 20 Jul 2017 16:11:23 +0300 Message-ID: To: "saag@ietf.org" Content-Type: multipart/alternative; boundary="001a113523b240c8540554bf7c24" Archived-At: Subject: [saag] Certificate limitation policy draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 13:11:26 -0000 --001a113523b240c8540554bf7c24 Content-Type: text/plain; charset="UTF-8" Hello, Here is the link to the draft: https://tools.ietf.org/html/draft-belyavskiy-certificate-limitation-policy-02 I would be glad to discuss and continue work on the draft if there is enough interest in the community. Thank you very much! -- SY, Dmitry Belyavsky --001a113523b240c8540554bf7c24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Here is the link to the draft:

I would be glad to = discuss and continue work on the draft if there is enough interest in the c= ommunity.

Thank you very much!

--
SY, Dmitry Belyavsky
--001a113523b240c8540554bf7c24-- From nobody Thu Jul 20 06:12:35 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ECF1315FF for ; Thu, 20 Jul 2017 06:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyCKqJ12Bkpd for ; Thu, 20 Jul 2017 06:12:30 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 B2F48126E3A for ; Thu, 20 Jul 2017 06:12:29 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id 80so22634782uas.0 for ; Thu, 20 Jul 2017 06:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=Dyh3thmLYXgpFAs8Q/qAAOlghS4B6SBHcl1Se80ea0A=; b=kq59kwcigoMjPM53JGe0P3HLxvUAviWA3jv2upGGoOr6na6rphl/AR/SnPODR4ArwK /5zDYP6NU5gDjlpBH3RFtpyoHwPmJyU0uMVbRJcz2fpSWY6i4VkkS/RoTrN8QNySk6iN 4dpeUsOH1BBghiWqQyQQ5uksfYgvm6EzWeDYw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Dyh3thmLYXgpFAs8Q/qAAOlghS4B6SBHcl1Se80ea0A=; b=MjAucsWLqtAfDyLOCNJQ1zwVXijGXsiuuTpp6pAcWqrmx8xi+m5qgYxmJrfB0N4GG5 f0JKp0cTfPE/WnO0NtHnzZ0P46WiLdtT9fO4rOAeBWojFnkyqg57SYVf93OC/xZU7cFl m2M8elc/dfDMrWelkn6a8DmTz5iph7vwNxGtTv7ZNJ09MFHGwerDv96cDzPKJ2GinqSf dOWQQwqwvhRhx+vPNsBAu8uT8xiF6oitlj0Pe5Vc44dG9U0Q7pc/dJVCtLm/SR7/3lHI pdxip+COM9cXyPUrCSMMH2sMGtv4eYJzW3jbXBm2YLuXwaE6HxKhsobJJq7H93FYv8Ez ny0Q== X-Gm-Message-State: AIVw1103YYC0llZED9ph/Nu6UADb/PVrJvCAt26JeCXDESc4AZseqEqc PC8JZTQAsrJCfbNBDEP9Q88dmzWPoCEJ7v/mOQ== X-Received: by 10.176.82.212 with SMTP id w20mr2196424uaw.98.1500556348034; Thu, 20 Jul 2017 06:12:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.137 with HTTP; Thu, 20 Jul 2017 06:12:07 -0700 (PDT) From: Joseph Lorenzo Hall Date: Thu, 20 Jul 2017 15:12:07 +0200 Message-ID: To: saag@ietf.org Content-Type: multipart/alternative; boundary="94eb2c18ee721724cc0554bf80fe" Archived-At: Subject: [saag] draft notes from SAAG IETF99 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 13:12:33 -0000 --94eb2c18ee721724cc0554bf80fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 20-July-2017 - Note Well - Working group reports - - ACE: (Hannes) met monday. lots of different proposals floating around about how to carry different documents around. Many researcher= s providing input. No much progress on charter items but lots of ideas. - I2NSF: (?) Met Thursday. Lots of contribs on data and info models. Make sure they are aligned, lots of good results. - OAUTH: (Hannes) Final session is tomorrow. In first session discussed wrapping up working group documents. Documented attacks aga= ins JWD. - OpenPGP: (Barry) Remarkable success in getting anything done. It=E2= =80=99s been difficult, and we=E2=80=99ve asked EKR to close the working grou= p. Sad that we could not get it done. (DKG) There is continuing work to get that done. If they start submitting drafts, we may revisit it. - TOKBIND (Lief): Playing around with some documents. - Diameter E2E Security: - - Still looking for a solution for e2e in DIME here. - RFC7966 documents the e2e requirements. - We have reused a previous draft but there has been no progress. - Two new AVPs are defined for protecting other AVPs - - Are thinking of using CBOR/COSE or other alternatives. - Hop-to-hop provided by TLS but no e2e yet. - Jean Mahoney: Please help! Been pushed off and we can=E2=80=99t do = this by ourselves - PHB: I have to generate something similar for mesh work. It=E2=80= =99s written up but not separately but not pulled out. Willing to help. - Related working groups: - - DMARC: (Barry) Met this morning. Main thing that=E2=80=99s being di= scussed is whether or not to publish it (ARC spec) as experimental. Crocker pointed out we don=E2=80=99t know if this will work. In our queue to move DMA= RC to standards track=E2=80=A6 unsure. - NTP: current draft is going to to to WGLC soon, security group was responsive. - DPRIVE: bunch of discsussion of DKG=E2=80=99s proposal to do demux = over DNS on HTTP. - PERC: getting around some of the issues it had with double context encryption for RTP. Could benefit from folks when a new draft is out = in a couple weeks. If you like crypto in real-time protocols. - RADext: going to close soon. Work on one more draft. - UTA: meeting later today. We can sort of start to see the light at the end of the tunnel. Got the core documents that we were chartered to do in RFCs. If SAAG has other TLS application needs, let us know. - CURDLE for DKIM: three documents almost done. Deprecating RC4 and SHA1 for ED256. - PrivSec: traffic analysis draft. - IRTF open: checkoway talk on DUAL-EC-DRBG. - TEEP: tutorial on Sunday. Describe how it works, good attendance. Met Wed, to discuss charter. - FUD: firmware updates for IoT devices. had side meeting today. two new documents there. - Kathleen: we=E2=80=99re hoping to charter these last two soon. - W3C (Sam Weiler): WebAuthn making good progress. Trying to get more eyes doing privacy and security reviews on specs. Please get in touch with me if you want to keep our WGs from doing stupid things. - Post-Quantum (Kenny Patterson) - - Lifetime of SHA1 - Trade-off between SHA1 and SHA2 started in Apr 2016 - Progress in Quantum Computing - The coming cryptapocalypse - - RLB: on the ECC point (that ECC will be broken earlier), is there a detailed analysis? A: Look for the name Tim Spiller. - Paul Hoffman: paper a few months ago said that ECC is probably stronger for the same strengths. - Ways forward - Post-Quantum Crypto - But what about Quantum Cryptography? (Kenny rains on our parade) - Punch line: we shouldn=E2=80=99t be too worried but we need to thin= k about it. - RLB: What can IETF do? - - KP: comment on NIST process in terms of evaluation and the PQC process. - Paul Hoffman: current estimates for key sizes are going to be an order of mag larger=E2=80=A6 so like 50k-bit key sizes. If you have a protocol like UDP where everything fits in one packet, you=E2=80=99re going to have= a bad time. Paul has a draft (c2pq) at CFRG that basically asks what we should do here at IETF/CFRG. We are going to want to know when we should start working on this stuff. - PHB: 1) do have a degree in nuclear physics, QKD is probably not going to work given the engineering params. We do have Lamport signatures, and might need to back them in now. 2) CAs started moving to SHA-2 in 2008. The rest of the infrastructure wouldn=E2=80=99t accept them until muc= h later. As a CA, I can=E2=80=99t issue them if they don=E2=80=99t work. - Stephen Farrell: Comment: IETF could look at data items that might be sensitive in the future and then engineer to protect them. - - PK: not just the identifiers, but plaintext. - SF: had a nice timeline that said, sit back and relax for 7 years. What=E2=80=99s the IPR situation look like? - PK: this is a good question. SHA-3 was a declare and royalty-free license. Will have to look. - Nick Sullivan: There are PQC schemes that can trade key sizes and computation to be more performant. - - PK: Comment about isogenies was that it=E2=80=99s so new. - Tobias G: with timelines I feel like I=E2=80=99m in a quantum state= =E2=80=A6 we may only find out when the quantum state has collapsed. Protocols we desi= gn have lifetimes of 10 years +. Leads us to crypto-agility+ so that we = can update them without breaking things in 5-10 times. Need to consider n= ow. - Pretty Easy Privacy (Volker Birk) - - draft-birk-pep-00 - from mic: (once it's time for questions): has the pep foundation ever taken a look at the work in UTA (WG) with regard to email securi= ty. reporting and UI/security improvements? AFAIK pep is just implementin= g a kind of overlay for popular clients based on either smime or gpg/pgpU= TA meets later on, please join. - Paul Woters: not sure what you are suggesting. A new area in IETF, an effort. - - VB: there=E2=80=99s no central infrastructure, we don=E2=80=99t = manage identities. Mapping identifiers into your own management of identi= ties. - MT: read your draft, looked at your website. Neither of those things helped me understand what you are trying to do. Didn=E2=80=99t= see an architecture or things that connect principles to your code. This is = a massive project. There is a very big difference between implementing = code and shipping code where you get interop. - PHB: I=E2=80=99ve been following this and I like it. ATM, there are= a lot of useable secure messaging systems around. But they=E2=80=99re all s= ingle silo models. In order to talk to someone using Signal, I=E2=80=99ve got to= get the Signal app. They=E2=80=99re all being sold as ways around government providers. For anything to be secure, you=E2=80=99ll need documented standards or th= ey can just coerce through the single point of failure of the sw. - Standardize Application-supported list of certificate limitation (Dimitri Belyavskiy) - - MT: is there a draft? I don=E2=80=99t know what this is. I certainl= y haven=E2=80=99t read this. You are describing something that has sign= ificant overlap with existing things. Why would this be superior? - - DB: The CRL can be issues by the application. - RB: there are application vendors doing this today. Google Chrome does CRLSets and Mozilla does OneCRL for Firefox. What=E2=80=99s the = value in standardizing this and having so much more functionality. - - DB: want to provide a standard syntax. - DKG: Check out p11-glue. There is existing work that does this. - Rich Salz: OpenSSL hat on. It would be great to have something not just in browsers to do some of this stuff. - MT: as someone involved in one of the projects that has some of these things, we=E2=80=99d be willing to participate. - RLB: I can see there could be value to this. A soft prereq is going to be some notion of who is trusted to distribute this information. i= n Vendor/Application space this is clear. Not so true for OpenSSL or De= bian. - EKR: (no AD hat) there are two problems to solve: 1) the policy problem of which anchors you trust and intermediaries you trust.; 2) distribution is hard and compression is necessary. - - DB: expect trust anchor being distributed with the application. - Open mic: - - Stephen Farrell: there was a bit of a fuss in TLS session. TLS would need to re-charter to do the draft-green work. Wondering what y= ou guys think? - - KM: nothing has been adopted, still discussion, remains to be seen what will happen. Maybe there is an opp. for something data-center specific. - SF: if they adopt something like this, do you consider that within their current charter. - KM: would need to re-read the charter. We=E2=80=99ll see what th= e WG ulitmately decide. - EKR: speaking not as AD, I don=E2=80=99t believe that draft-gree= n would be within the charter. - Yaron: there was a Quantum Random Oracle mentioned in CFRG. Wanted to ask your personal opinion as to whether these models exist, are reliable, and are something that NIST can base their evaluation on. - - KP: yes, yes, and yes. Still getting around the QRO model. - --=20 Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --94eb2c18ee721724cc0554bf80fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
20-July-2017

  • Note Well
  • Working group reports
    • ACE: (Hannes) met monday. = lots of different proposals floating around about how to carry different do= cuments around. Many researchers providing input. No much progress on chart= er items but lots of ideas.
    • I2NSF: (?) Met Thursday. Lots of contri= bs on data and info models. Make sure they are aligned, lots of good result= s.
    • OAUTH: (Hannes) Final session is tomorrow. In first session disc= ussed wrapping up working group documents. Documented attacks agains JWD.
    • OpenPGP: (Barry) Remarkable success in getting anything done. It=E2= =80=99s been difficult, and we=E2=80=99ve asked EKR to close the working gr= oup. Sad that we could not get it done. (DKG) There is continuing work to g= et that done. If they start submitting drafts, we may revisit it.
    • T= OKBIND (Lief): Playing around with some documents.
  • Diamet= er E2E Security:
    • Sti= ll looking for a solution for e2e in DIME here.
    • RFC7966 documents t= he e2e requirements.
    • We have reused a previous draft but there has = been no progress.
    • Two new AVPs are defined for protecting other AVP= s
      • Are thinking of us= ing CBOR/COSE or other alternatives.
    • Hop-to-hop provided = by TLS but no e2e yet.
    • Jean Mahoney: Please help! Been pushed off a= nd we can=E2=80=99t do this by ourselves
    • PHB: I have to generate so= mething similar for mesh work. It=E2=80=99s written up but not separately b= ut not pulled out. Willing to help.
  • Related working group= s:
    • DMARC: (Barry) Me= t this morning. Main thing that=E2=80=99s being discussed is whether or not= to publish it (ARC spec) as experimental. Crocker pointed out we don=E2=80= =99t know if this will work. In our queue to move DMARC to standards track= =E2=80=A6 unsure.
    • NTP: current draft is going to to to WGLC soon, s= ecurity group was responsive.
    • DPRIVE: bunch of discsussion of DKG= =E2=80=99s proposal to do demux over DNS on HTTP.
    • PERC: getting aro= und some of the issues it had with double context encryption for RTP. Could= benefit from folks when a new draft is out in a couple weeks. If you like = crypto in real-time protocols.
    • RADext: going to close soon. Work on= one more draft.
    • UTA: meeting later today. We can sort of start to = see the light at the end of the tunnel. Got the core documents that we were= chartered to do in RFCs. If SAAG has other TLS application needs, let us k= now.
    • CURDLE for DKIM: three documents almost done. Deprecating RC4 = and SHA1 for ED256.
    • PrivSec: traffic analysis draft.=C2=A0
    • = IRTF open: checkoway talk on DUAL-EC-DRBG.
    • TEEP: tutorial on Sunday= . Describe how it works, good attendance. Met Wed, to discuss charter.
      • =
    • FUD: firmware updates for IoT devices. had side meeting today. two new = documents there.
    • Kathleen: we=E2=80=99re hoping to charter these la= st two soon.
    • W3C (Sam Weiler): WebAuthn making good progress. Tryin= g to get more eyes doing privacy and security reviews on specs. Please get = in touch with me if you want to keep our WGs from doing stupid things.
      • =
  • Post-Quantum (Kenny Patterson)
    • Lifetime of SHA1
    • Trade-off between SHA1 an= d SHA2 started in Apr 2016
    • Progress in Quantum Computing
    • Th= e coming cryptapocalypse
    • RLB: on the ECC point (that ECC will be broken earlier), is there a de= tailed analysis? A: Look for the name Tim Spiller.
    • Paul Hoffman: pa= per a few months ago said that ECC is probably stronger for the same streng= ths.
  • Ways forward - Post-Quantum Crypto
  • But what = about Quantum Cryptography? (Kenny rains on our parade)
  • Punch line:= we shouldn=E2=80=99t be too worried but we need to think about it.
    • RLB: What can IETF do?
    • =
    • KP: comment on NIST process in terms of evaluation and the PQC process.=
  • Paul Hoffman: current estimates for key sizes are going = to be an order of mag larger=E2=80=A6 so like 50k-bit key sizes. If you hav= e a protocol like UDP where everything fits in one packet, you=E2=80=99re g= oing to have a bad time. Paul has a draft (c2pq) at CFRG that basically ask= s what we should do here at IETF/CFRG. We are going to want to know when we= should start working on this stuff.
  • PHB: 1) do have a degree in nu= clear physics, QKD is probably not going to work given the engineering para= ms. We do have Lamport signatures, and might need to back them in now. 2) C= As started moving to SHA-2 in 2008. The rest of the infrastructure wouldn= =E2=80=99t accept them until much later. As a CA, I can=E2=80=99t issue the= m if they don=E2=80=99t work.
  • Stephen Farrell: Comment: IETF could = look at data items that might be sensitive in the future and then engineer = to protect them.
    • PK:= not just the identifiers, but plaintext.
    • SF: had a nice timeline t= hat said, sit back and relax for 7 years. What=E2=80=99s the IPR situation = look like?
    • PK: this is a good question. SHA-3 was a declare and roy= alty-free license. Will have to look.
  • Nick Sullivan: Ther= e are PQC schemes that can trade key sizes and computation to be more perfo= rmant.
    • PK: Comment a= bout isogenies was that it=E2=80=99s so new.
  • Tobias G: wi= th timelines I feel like I=E2=80=99m in a quantum state=E2=80=A6 we may onl= y find out when the quantum state has collapsed. Protocols we design have l= ifetimes of 10 years +. Leads us to crypto-agility+ so that we can update t= hem without breaking things in 5-10 times. Need to consider now.
<= /li>
  • Pretty Easy Privacy (Volker Birk)
    • draft-birk-pep-00
    • from mic:=C2=A0(once it'= ;s time for questions): has the pep foundation ever taken a look at the wor= k in UTA (WG) with regard to email security. reporting and UI/security impr= ovements? AFAIK pep is just implementing a kind of overlay for popular clie= nts based on either smime or gpg/pgpUTA meets later on, please join.
      • Paul Woters: not sure what you are suggesting. A new area in IETF, an eff= ort.
      • VB: there=E2=80= =99s no central infrastructure, we don=E2=80=99t manage identities. Mapping= identifiers into your own management of identities.
    • MT: = read your draft, looked at your website. Neither of those things helped me = understand what you are trying to do. Didn=E2=80=99t see an architecture or= things that connect principles to your code. This is a massive project. Th= ere is a very big difference between implementing code and shipping code wh= ere you get interop.
    • PHB: I=E2=80=99ve been following this and I li= ke it. ATM, there are a lot of useable secure messaging systems around. But= they=E2=80=99re all single silo models. In order to talk to someone using = Signal, I=E2=80=99ve got to get the Signal app. They=E2=80=99re all being s= old as ways around government providers. For anything to be secure, you=E2= =80=99ll need documented standards or they can just coerce through the sing= le point of failure of the sw.
  • Standardize Application-su= pported list of certificate limitation (Dimitri Belyavskiy)
    • MT: is there a draft? I don=E2=80= =99t know what this is. I certainly haven=E2=80=99t read this. You are desc= ribing something that has significant overlap with existing things. Why wou= ld this be superior?
      • DB: The CRL can be issues by the application.
    • RB: there = are application vendors doing this today. Google Chrome does CRLSets and Mo= zilla does OneCRL for Firefox. What=E2=80=99s the value in standardizing th= is and having so much more functionality.
      • DB: want to provide a standard syntax.
      • =
    • DKG: Check out p11-glue. There is existing work that does this.
      • Rich Salz: OpenSSL hat on. It would be great to have something not just in= browsers to do some of this stuff.
    • MT: as someone involved in one = of the projects that has some of these things, we=E2=80=99d be willing to p= articipate.
    • RLB: I can see there could be value to this. A soft pre= req is going to be some notion of who is trusted to distribute this informa= tion. in Vendor/Application space this is clear. Not so true for OpenSSL or= Debian.
    • EKR: (no AD hat) there are two problems to solve: 1) the p= olicy problem of which anchors you trust and intermediaries you trust.; 2) = distribution is hard and compression is necessary.
      • DB: expect trust anchor being distributed wi= th the application.
  • Open mic:
    • Stephen Farrell: there was a bit of a= fuss in TLS session. TLS would need to re-charter to do the draft-green wo= rk. Wondering what you guys think?
      • KM: nothing has been adopted, still discussion, remains to b= e seen what will happen. Maybe there is an opp. for something data-center s= pecific.
      • SF: if they adopt something like this, do you consider tha= t within their current charter.
      • KM: would need to re-read the chart= er. We=E2=80=99ll see what the WG ulitmately decide.
      • EKR: speaking = not as AD, I don=E2=80=99t believe that draft-green would be within the cha= rter.
    • Yaron: there was a Quantum Random Oracle mentioned = in CFRG. Wanted to ask your personal opinion as to whether these models exi= st, are reliable, and are something that NIST can base their evaluation on.=
      • KP: yes, yes, and y= es. Still getting around the QRO model.







    --
    Joseph Lorenzo Hall
    Chief Technologist, Center for= Democracy & Technology [https://www.cd= t.org]
    1401 K ST NW STE 200, Washington DC 20005-3497
    e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
    Finger= print: 3CA2 8D7B 9F6D DBD3 4B10 =C2=A01607 5F86 6987 40A9 A871
    • --94eb2c18ee721724cc0554bf80fe-- From nobody Thu Jul 20 09:14:41 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A323E12EC46 for ; Thu, 20 Jul 2017 09:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 5uT-SOI997XD for ; Thu, 20 Jul 2017 09:14:36 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 952E1127136 for ; Thu, 20 Jul 2017 09:14:36 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 7CB213740F3C for ; Thu, 20 Jul 2017 12:14:35 -0400 (EDT) References: <8c734c87-2e57-c43d-e1bd-92f3c4ddeae3@openca.org> From: "Dr. Pala" Organization: OpenCA Labs To: "saag@ietf.org" Message-ID: Date: Thu, 20 Jul 2017 18:14:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6382F48DE4760AAAD2A8849C" Content-Language: en-US Archived-At: Subject: Re: [saag] Considerations about the need to resume PKIX work X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:14:40 -0000 This is a multi-part message in MIME format. --------------6382F48DE4760AAAD2A8849C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Bernard, all, thanks for the support - we need people that chime in and say they are interested so we can convince WE Chairs and ADs that there is support for this work to happen. I do not know where this work might happen, it is always difficult to find the correct venue. Russ Housley (thanks Russ) suggested to write down separate charter items with a description of the deliverable and milestones for a possible LAMPS (spasm) WG recharter and adoption. Is anybody interested in helping me to provide Russ with the required items ? Please let me know. Cheers, Max P.S.: Again, thanks for replying to this message. I would encourage, again, other people to reply and indicate if they think this work might be important. On 7/20/17 3:05 PM, Bernard Aboba wrote: > Thank you very much for your thoughtful note. > > I share a number of the concerns you have articulated, particularly > about the increasing proliferation of poorly-thought-through > certificate schemes, both within IETF and outside of it. While it is > not clear to me that having an IETF forum for discussion of PKIX > issues would necessarily reverse these trends (since dubious schemes > began to proliferate while PKIX WG was active, particularly in the > wireless arena), I believe your concerns are real and deserve thorough > discussion. > > In general, the IETF likes WGs to operate with narrow charters for > finite periods of time, whereas some other SDOs maintain standing > groups with broad charters for long periods. > > This makes it possible for widely deployed protocols to not have an > active IETF WG (although sometimes mailing lists may remain > operational). When a WG is active, Chairs have a tendency to > strongly encourage a focus on topics relating to the Charter so as to > encourage forward progress. This can lead to IETF WGs being > ineffective in reviewing related work in other IETF WGs, let alone in > other SDOs. > > One potential solution to your concerns might be to create a WG to > deal with "PKIX extensions". However, if the core need is to create a > forum which can be used to strengthen PKI utilization both in the IETF > and outside of it, this may not be sufficient. For example, provision > may need to be made for review of specifications (e.g. "PKIX > doctors"), or for suitable liaison arrangements so as to encourage > cooperation between SDOs on PKI topics. > > With respect to the meme that "PKIs do not work", my observation is > that the IETF seems to pay more attention to developments in the "big > I" Internet, than to developments within "little i" internets, such as > private deployments in enterprise. Part of the reason is that > participation within IETF among users has been in decline for a very > long time. Without that customer participation, it can be difficult > for the IETF to assess protocol success. However, having been > involved in some of the world's largest PKI deployments, I think it is > safe to say that PKI can be considered "successful" if not "widely > successful" by the criteria of RFC 5218. > > > > > > On Thu, Jul 20, 2017 at 4:35 AM, Dr. Pala > wrote: > > Hi all, > > I would like to draw the Sec Area attention on an issue that I > think is becoming more relevant every day. > > It seems quite clear that today there is a lot of work around > authentication and encryption that make use of PKIX certificates. > However, there is no place in IETF, today, where problems related > to PKIX can be effectively tackled. In the following paragraphs I > try to summarize the issue and the proposed work and a call for > discussion around the feasibility of resuming the work in two > particular areas: revocation and discoverability. > > *The Problem > > *What I noticed in recent proposals in many working groups (when > it comes to certificate management) is that more and more people > turn towards the use of short-lived certificates to avoid checking > revocation information. Sometimes this choice is motivated by real > technical considerations, but in many cases the choice is "forced" > because nobody is currently working on fixing the two main issues > related to trust infrastructures: efficient revocation and > discoverability of services. > > *The Revocation Situation* > > Most of the times, when interacting with PKIs, we are still stuck > with CRLs, OCSP if we are lucky (including stapling - available in > TLS connections if really really lucky), and in most cases even > these mechanisms are criticized widely by people as being > inadequate today. This resulted in applications to use proprietary > methods for checking revocation (e.g., CRLSet) or to skip checking > all together (or mandate for short-lived certificates only as in > the case, for example, of STIR). > > Many people today ignore the fact that, when coupled with small > devices, the generation of new keys require (a) a lot of > resources, and (b) a good source of randomness. Requiring apps / > devices to generate new keys might seem a good idea at first, but > is this better than checking revocation ? What about the > complexity of key management ? > > /Examples of possible work to address the issues are OCSP over DNS > and some more efficient ways to verify the validity of a whole > chain of certificates efficiently./ > > *The Discoverability Situation* > > As far as I know, there are no standardized mechanisms that would > provide discoverability of services that would help users and > applications to discover Public Key Services providers and > associated services in a dynamic fashion. When I brought it up > during the BoFs of possible working groups where the issue could > be discussed.. well, the proposal was redirected to /dev/null > (e.g., ACME, SPASM, and LAMPS). > > Isn't that curious that still today nobody is working on some sort > of infrastructure that would facilitate interacting with PKIs ? > After all, PKIs are the core Trust mechanism that enables reliable > authentication and encryption over the Internet today. Such > infrastructure could really improve the security of the Internet > and make PKIs more usable from an application (and users) > standpoint of view. > > /Examples of possible work to address the issue are a PKI Resource > Query Protocol (PRQP) and/or the use of P2P systems as > distribution mechanisms for Public Key related operations (e.g., > EST, BRSKI, or ACME over P2P - 0-configuration support for PK)./ > > *Deployment Trends in the Real World* > > Today I am witnessing the deployment of arguably not-well-designed > PKIs (or, in other terms, what I call Weak PKIs) that do not > provide support for revocation and that are expected to use CAs > and EE certificates with validity periods of 30, 35, or 50 years > (yes, also EE - especially for devices). Besides the fact that it > is a common assumption that the algorithms (e.g., P-256) used in > these environments (e.g. IoT) are NOT going to pass the test of > time, ignoring the revocation could really affect the privacy of > millions of people - and we are currently not doing anything at > the IETF to prevent this issue. > > /There is the need for simple revocation services, but arguably we > do not have what's needed today (requires improvements)./ > > *IETF Specific Situation and Issues* > > Why are we so unprepared to face these issues ? I would say (still > personal point of view - based on almost 20 yrs of participation > in PKI discussions) that these might be some of the main reasons: > > * *There are NO venues where to discuss possible solutions to > existing problems.* The PKIX working group has been closed > down (very arbitrarily, I might say, since there is still a > lot of work needed to be done around PKIX as highlighted above) > > * *The LAMPS, SPASM, and ACME WGs have/have had, on purpose, > very narrow scoped Charters and only few items**(mostly quite > marginal issues, IMO) are actually accepted as working items > (w/ reference to SPASM and LAMPS in particular).* Solving > revocation and discoverability issues should be the 1st item > and the most important on the list (at least revocation) but > they are not - actually when that was proposed to be included > as part of the charter(s), the requests were not even > acknowledged or rejected with no real technical reasons. > > * *The constant**nonsense of people saying that PKIs do not work > as an excuse not to improve them while they (PKIs) are the > reason we can deploy secure protocols and provide privacy. *It > is evident that PKIs are here to stay, this is a fact. Their > usage has increased exponentially in the past years and they > have, so far, passed the test of time. IoT is one use-case. > ANIMA is another. ACME is another. Just to cite few of them. > > Moreover, things are happening in environments outside IETF (WIFI > 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of > working on these problems is really scary to me. The world moves > forward, fast, and the IETF is standing still on this topic./*I > really do not understand why.*/ > > *Final Considerations* > > In this message I try to summarize the reasons why I think there > is the need to provide a venue where these problems are discussed > and the need for key people to not actively block the possibility > for people that are willing to work on this to have a venue where > the work can be carried out. > > I think that this work is of the utter importance and I would like > to understand what the position of the whole security area is > around these points and the proposed work. > > /I hope that the discussion around this message can spark some > interest and that work in the PKIX area can finally resume at the > IETF - which was, in the past, thought of as the lighthouse where > these issues could be addressed./ > > A small request, please, try to read this e-mail carefully and > consider the implications of NOT taking on these tasks when > replying and/or discussing the topic. Also, since I know this > (PKIX) is a minefield for "political" reasons (which should not be > a drive here), please keep the discussion on the positive / > constructive side (thanks). > > /If you feel like a private response is better than on the mailing > list, please just reply privately./ > > Looking forward to hear your opinions on this hoping that this > e-mail can be the beginning of the end of PKIX still-standing > issues :D > > Cheers, > Max > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > OpenCA Logo > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > > -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------6382F48DE4760AAAD2A8849C Content-Type: multipart/related; boundary="------------C147798FD9B14CAFEF5E1ACD" --------------C147798FD9B14CAFEF5E1ACD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    Hi Bernard, all,

    thanks for the support - we need people that chime in and say they are interested so we can convince WE Chairs and ADs that there is support for this work to happen.

    I do not know where this work might happen, it is always difficult to find the correct venue.

    Russ Housley (thanks Russ) suggested to write down separate charter items with a description of the deliverable and milestones for a possible LAMPS (spasm) WG recharter and adoption.

    Is anybody interested in helping me to provide Russ with the required items ?

    Please let me know.

    Cheers,
    Max

    P.S.: Again, thanks for replying to this message. I would encourage, again, other people to reply and indicate if they think this work might be important.


    On 7/20/17 3:05 PM, Bernard Aboba wrote:
    Thank you very much for your thoughtful note. 

    I share a number of the concerns you have articulated, particularly about the increasing proliferation of poorly-thought-through certificate schemes, both within IETF and outside of it.  While it is not clear to me that having an IETF forum for discussion of PKIX issues would necessarily reverse these trends (since dubious schemes began to proliferate while PKIX WG was active, particularly in the wireless arena), I believe your concerns are real and deserve thorough discussion. 

    In general, the IETF likes WGs to operate with narrow charters for finite periods of time, whereas some other SDOs maintain standing groups with broad charters for long periods.

    This makes it possible for widely deployed protocols to not have an active IETF WG (although sometimes mailing lists may remain operational).  When a WG is active,  Chairs have a tendency to strongly encourage a focus on topics relating to the Charter so as to encourage forward progress.  This can lead to IETF WGs being ineffective in reviewing related work in other IETF WGs, let alone in other SDOs. 

    One potential solution to your concerns might be to create a WG to deal with "PKIX extensions".  However, if the core need is to create a forum which can be used to strengthen PKI utilization both in the IETF and outside of it, this may not be sufficient.  For example, provision may need to be made for review of specifications (e.g. "PKIX doctors"), or for suitable liaison arrangements so as to encourage cooperation between SDOs on PKI topics. 

    With respect to the meme that "PKIs do not work", my observation is that the IETF seems to pay more attention to developments in the "big I" Internet, than to developments within "little i" internets, such as private deployments in enterprise.  Part of the reason is that participation within IETF among users has been in decline for a very long time.  Without that customer participation, it can be difficult for the IETF to assess protocol success.  However, having been involved in some of the world's largest PKI deployments, I think it is safe to say that PKI can be considered "successful" if not "widely successful" by the criteria of RFC 5218. 





    On Thu, Jul 20, 2017 at 4:35 AM, Dr. Pala <director@openca.org> wrote:

    Hi all,

    I would like to draw the Sec Area attention on an issue that I think is becoming more relevant every day.

    It seems quite clear that today there is a lot of work around authentication and encryption that make use of PKIX certificates. However, there is no place in IETF, today, where problems related to PKIX can be effectively tackled. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussion around the feasibility of resuming the work in two particular areas: revocation and discoverability.

    The Problem

    What I noticed in recent proposals in many working groups (when it comes to certificate management) is that more and more people turn towards the use of short-lived certificates to avoid checking revocation information. Sometimes this choice is motivated by real technical considerations, but in many cases the choice is "forced" because nobody is currently working on fixing the two main issues related to trust infrastructures: efficient revocation and discoverability of services.

    The Revocation Situation

    Most of the times, when interacting with PKIs, we are still stuck with CRLs, OCSP if we are lucky (including stapling - available in TLS connections if really really lucky), and in most cases even these mechanisms are criticized widely by people as being inadequate today. This resulted in applications to use proprietary methods for checking revocation (e.g., CRLSet) or to skip checking all together (or mandate for short-lived certificates only as in the case, for example, of STIR).

    Many people today ignore the fact that, when coupled with small devices, the generation of new keys require (a) a lot of resources, and (b) a good source of randomness. Requiring apps / devices to generate new keys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of key management ?

    Examples of possible work to address the issues are OCSP over DNS and some more efficient ways to verify the validity of a whole chain of certificates efficiently.

    The Discoverability Situation

    As far as I know, there are no standardized mechanisms that would provide discoverability of services that would help users and applications to discover Public Key Services providers and associated services in a dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be discussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS).

    Isn't that curious that still today nobody is working on some sort of infrastructure that would facilitate interacting with PKIs ? After all, PKIs are the core Trust mechanism that enables reliable authentication and encryption over the Internet today. Such infrastructure could really improve the security of the Internet and make PKIs more usable from an application (and users) standpoint of view.

    Examples of possible work to address the issue are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-configuration support for PK).

    Deployment Trends in the Real World

    Today I am witnessing the deployment of arguably not-well-designed PKIs (or, in other terms, what I call Weak PKIs) that do not provide support for revocation and that are expected to use CAs and EE certificates with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that it is a common assumption that the algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT going to pass the test of time, ignoring the revocation could really affect the privacy of millions of people - and we are currently not doing anything at the IETF to prevent this issue.

    There is the need for simple revocation services, but arguably we do not have what's needed today (requires improvements).

    IETF Specific Situation and Issues

    Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in PKI discussions) that these might be some of the main reasons:

    • There are NO venues where to discuss possible solutions to existing problems. The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above)

    • The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow scoped Charters and only few items (mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular). Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons.

    • The constant nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them.

    Moreover, things are happening in environments outside IETF (WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these problems is really scary to me. The world moves forward, fast, and the IETF is standing still on this topic. I really do not understand why.

    Final Considerations

    In this message I try to summarize the reasons why I think there is the need to provide a venue where these problems are discussed and the need for key people to not actively block the possibility for people that are willing to work on this to have a venue where the work can be carried out.

    I think that this work is of the utter importance and I would like to understand what the position of the whole security area is around these points and the proposed work.

    I hope that the discussion around this message can spark some interest and that work in the PKIX area can finally resume at the IETF - which was, in the past, thought of as the lighthouse where these issues could be addressed.

    A small request, please, try to read this e-mail carefully and consider the implications of NOT taking on these tasks when replying and/or discussing the topic. Also, since I know this (PKIX) is a minefield for "political" reasons (which should not be a drive here), please keep the discussion on the positive / constructive side (thanks).

    If you feel like a private response is better than on the mailing list, please just reply privately.

    Looking forward to hear your opinions on this hoping that this e-mail can be the beginning of the end of PKIX still-standing issues :D

    Cheers,
    Max

    --
    Best Regards,
    Massimiliano Pala, Ph.D.
    OpenCA Labs Director
    OpenCA Logo

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



    --
    Best Regards,
    Massimiliano Pala, Ph.D.
    OpenCA Labs Director
    OpenCA Logo
    --------------C147798FD9B14CAFEF5E1ACD Content-Type: image/png; name="efhklhncoknghhph.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="efhklhncoknghhph.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------C147798FD9B14CAFEF5E1ACD Content-Type: image/png; name="afhjphfcegmloefa.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="afhjphfcegmloefa.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------C147798FD9B14CAFEF5E1ACD-- --------------6382F48DE4760AAAD2A8849C-- From nobody Thu Jul 20 10:03:10 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360BB131945 for ; Thu, 20 Jul 2017 10:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 4PIqlAihXO2C for ; Thu, 20 Jul 2017 10:03:06 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 6F969127B60 for ; Thu, 20 Jul 2017 10:03:06 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id g13so13859704ioj.5 for ; Thu, 20 Jul 2017 10:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=McsRGNtucvNAWApIRicMEX59uDfSZ6jTR6OHuusQWY0=; b=BWIV3bXXOiSa8iB7j2cP+V/HJjTjAQMlL1Y9LQVUYIgd2Rmefa7WHz2P5xupysJ7l7 /Hi9ajrFMrdeOOEBpLrY2oCLkpjKTrnNITzxr7tCM8WGgsGJfsJ6xNBCV9V76jnQNWk2 IRG0aYvTe/RDF4OVNO03Nv2VemTrdaAXcY3/8uHU9knbO1S4yApg/7XFeg6CDD8rSYec vWgTglVcK2n851I/Om//tzGjGYnRkwMCoZ4Lw/IwhMAtEgaMk5xbciFA2E6OaicO01hT aoJ1jbPf2pVFMTsTivgTlp6QrhF0v5f31lIlcE36bfnmdr0DaBzd66VKeQmtTQcB9zQh cEtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=McsRGNtucvNAWApIRicMEX59uDfSZ6jTR6OHuusQWY0=; b=LFUhGK/ApbqXfcKq4oi1AqEH0WnuVAwK6BantrGxpfl40IwEz46t6Cy4xz01yDeuz+ DsPeStb2KFY8Z3YXZV96Qo2bZC3pjuN2XCaQ+RggpnW5m/m3uyzmVPyye66YukYqsCFI WdzdDspgxNvAeKCk4H+B3Q+8xtcG50XPkG6qLvNP0jlK+rcBdGWcDM9uIwHXM0j/otl5 Gov4IpUl1ZAt8VOhLRS5gP492RtJR6/cdvv6uA7Gwtxt3jgCXndu8HIARnjg+c70iYmu DXeX75+pq0bv9aXVap6hWFADdIieIL3aXVdo5B4nUs4LTb6ckprf1Xcm3e9X3ALr23Rz DdmQ== X-Gm-Message-State: AIVw1117Lb2MJdaFTL4tuBe75MURsy5yXxYqt5eX6JTN60qCADYVDArZ V3D7OMIlhHmNE13ZEbgZIgPGxGAH6P3z3D0= X-Received: by 10.107.37.141 with SMTP id l135mr4121340iol.146.1500570185532; Thu, 20 Jul 2017 10:03:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.17.221 with HTTP; Thu, 20 Jul 2017 10:02:49 -0700 (PDT) From: Donald Eastlake Date: Thu, 20 Jul 2017 13:02:49 -0400 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] Publicly available general quantum computer X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 17:03:08 -0000 (posted with permission of the Security ADs) IBM maintains a general quantum computer for which the public can compose and run programs. Current, it supports 16 qubits. Just search for "ibm-q". (The IBM site seems to not be accessible via IPv6.) Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Thu Jul 20 15:28:30 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55035126B72 for ; Thu, 20 Jul 2017 15:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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 pouX955Sh7Ep for ; Thu, 20 Jul 2017 15:28:24 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0127.outbound.protection.outlook.com [104.47.1.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A21126B7E for ; Thu, 20 Jul 2017 15:28:22 -0700 (PDT) Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com (10.168.57.26) by DB6PR0601MB2165.eurprd06.prod.outlook.com (10.168.57.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Thu, 20 Jul 2017 22:28:19 +0000 Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com ([fe80::d82f:5230:5e12:43b4]) by DB6PR0601MB2167.eurprd06.prod.outlook.com ([fe80::d82f:5230:5e12:43b4%13]) with mapi id 15.01.1261.024; Thu, 20 Jul 2017 22:28:20 +0000 From: "Diego R. Lopez" To: "saag@ietf.org" Thread-Topic: [saag] Considerations about the need to resume PKIX work Thread-Index: AQHTAUxcgcfG5EnCwUSjQQYBMsZnzKJcrzeAgACdKoA= Date: Thu, 20 Jul 2017 22:28:19 +0000 Message-ID: References: <8c734c87-2e57-c43d-e1bd-92f3c4ddeae3@openca.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-originating-ip: [193.85.202.194] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2165; 7:iwqEXMWKf4JLnsAfm4fYUnVVKsZ5t6t4DtZFT1fa2l/GHt7SdZNs3P2aDnv7VrfSSRYuBW2w0XzOD9lPxQSNnalQQr/RL2euuvAOlma00lqu5V9CQMXqZsyVNxtLbY1l7YKVeh9HJSMbxB6HMxJz/dxlM2M3Q1N6c2U3qFw+9KuxF8JrsB9Fe83Z5TPDbZw0KTGKyA6G/JCBytA/81Tr51QYrvDEFRgYZwB4VSM6C4cc33SKV9liTbMs2teGh0JTClFCiObCd3pDKMnsNlU9MX+2EKdjIQ77y9VTwcFmBoicd3ibQqUfLlK+pkzG1wOGkR6vh6n2qGNiaZzncryJeOgRqsFcWbhmqBMCVinpMU4KOPZ1Y/O61p+R6CSTwgfWwce7X51AS31jXIBeDWVPQDyClsasz0K4eyi4s4VRGMK+U8zxnGejBwDcRws0FVxg63UhV8sZbt/9VXiNC1p91HRsJWc9YCZkk6J0c9MeGGUUAjPLtzHH4lc7PjGKrJMibDAAJN8LXu8blsInDNm1GhqXNPjiDVMjP9FHnoWZL6AWiGM+CwYhftCGya8B9dlL2BUIoCbZYGDCXXj/MBkJK/cJi2ajHsORQVT7lK1DJKkSkCVimWJEftaH8Tx8Sc0aWKibLLDzgfCjidR0dA13JyWjt/90ijWW3miYGlEY56tVNAR8p/1hcZ64FG5k8PDdmaMBx1vMA2H7RnEAGG0r33vBU7Iqt9xfZfpROqidpzbG285q9N8Y/yLkOlMsriB3m/s+TOeVDAJNrl3IVu8INp0NUCW22dxcDg1LU9E+VRI= x-ms-office365-filtering-correlation-id: bec973ce-6e0f-4b08-e89d-08d4cfbe9ff7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0601MB2165; x-ms-traffictypediagnostic: DB6PR0601MB2165: x-exchange-antispam-report-test: UriScan:(40392960112811)(278428928389397)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0601MB2165; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0601MB2165; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39410400002)(39840400002)(39850400002)(39400400002)(39450400003)(45984002)(51444003)(189002)(199003)(252514010)(377454003)(25724002)(24454002)(40134004)(53754006)(3660700001)(66066001)(53546010)(966005)(3280700002)(8936002)(8676002)(81166006)(81156014)(7736002)(1730700003)(2351001)(83716003)(2501003)(6512007)(6306002)(99286003)(54896002)(5660300001)(2900100001)(68736007)(86362001)(478600001)(5640700003)(33656002)(82746002)(25786009)(5250100002)(6436002)(14454004)(36756003)(236005)(6506006)(97736004)(53936002)(229853002)(101416001)(54356999)(561944003)(76176999)(6916009)(6486002)(38730400002)(2950100002)(110136004)(189998001)(606006)(102836003)(106356001)(105586002)(6246003)(50986999)(3846002)(6116002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0601MB2165; H:DB6PR0601MB2167.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CA369E06BA4E4A4289CED317CAAF9B2Atelefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 22:28:19.9705 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2165 Archived-At: Subject: Re: [saag] Considerations about the need to resume PKIX work X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 22:28:29 -0000 --_000_CA369E06BA4E4A4289CED317CAAF9B2Atelefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgZG8gc2hhcmUgbW9zdCBvZiBNYXjigJkgY29uY2VybnMgYW5kIHdvdWxkIGRlZmlu aXRlbHkgbGlrZSB0byBzZWUgYSB3YXkgb2YgYWRkcmVzc2luZyB0aGVtLCBhbmQgdGhlIElFVEYg c2VlbXMgYSBnb29kIHBsYWNlIGZvciBkb2luZyBpdC4gVG8gQmVybmFyZOKAmXMgY29tbWVudCBh Ym91dCB0aGUgd2lkdGggYW5kIGxlbmd0aCBvZiBjaGFydGVycyBJ4oCZZCByZXBseSBhc2tpbmcg d2hldGhlciB3ZSBjb3VsZCBhdHRlbXB0IGFuIOKAnFBLSVhPUFPigJ0gZ3JvdXAsIGluIHRoZSBz YW1lIHN0eWxlIG9mIG90aGVyICpvcHMgZ3JvdXBzLCBkZWRpY2F0ZWQgdG8gb3BlcmF0aW9uYWwg aXNzdWVzLiBBbGwgaW4gYWxsLCB0aG9zZSBjb25jZXJucyBhcmUgZXNzZW50aWFsbHkgb3BlcmF0 aW9uYWwsIGFzIGZhciBhcyBJIGNhbiB0ZWxs4oCmDQoNCkJlIGdvb2RlLA0KDQpPbiAyMCBKdWwg MjAxNywgYXQgMTU6MDUgLCBCZXJuYXJkIEFib2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbTxt YWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20+PiB3cm90ZToNCg0KVGhhbmsgeW91IHZlcnkg bXVjaCBmb3IgeW91ciB0aG91Z2h0ZnVsIG5vdGUuDQoNCkkgc2hhcmUgYSBudW1iZXIgb2YgdGhl IGNvbmNlcm5zIHlvdSBoYXZlIGFydGljdWxhdGVkLCBwYXJ0aWN1bGFybHkgYWJvdXQgdGhlIGlu Y3JlYXNpbmcgcHJvbGlmZXJhdGlvbiBvZiBwb29ybHktdGhvdWdodC10aHJvdWdoIGNlcnRpZmlj YXRlIHNjaGVtZXMsIGJvdGggd2l0aGluIElFVEYgYW5kIG91dHNpZGUgb2YgaXQuICBXaGlsZSBp dCBpcyBub3QgY2xlYXIgdG8gbWUgdGhhdCBoYXZpbmcgYW4gSUVURiBmb3J1bSBmb3IgZGlzY3Vz c2lvbiBvZiBQS0lYIGlzc3VlcyB3b3VsZCBuZWNlc3NhcmlseSByZXZlcnNlIHRoZXNlIHRyZW5k cyAoc2luY2UgZHViaW91cyBzY2hlbWVzIGJlZ2FuIHRvIHByb2xpZmVyYXRlIHdoaWxlIFBLSVgg V0cgd2FzIGFjdGl2ZSwgcGFydGljdWxhcmx5IGluIHRoZSB3aXJlbGVzcyBhcmVuYSksIEkgYmVs aWV2ZSB5b3VyIGNvbmNlcm5zIGFyZSByZWFsIGFuZCBkZXNlcnZlIHRob3JvdWdoIGRpc2N1c3Np b24uDQoNCkluIGdlbmVyYWwsIHRoZSBJRVRGIGxpa2VzIFdHcyB0byBvcGVyYXRlIHdpdGggbmFy cm93IGNoYXJ0ZXJzIGZvciBmaW5pdGUgcGVyaW9kcyBvZiB0aW1lLCB3aGVyZWFzIHNvbWUgb3Ro ZXIgU0RPcyBtYWludGFpbiBzdGFuZGluZyBncm91cHMgd2l0aCBicm9hZCBjaGFydGVycyBmb3Ig bG9uZyBwZXJpb2RzLg0KDQpUaGlzIG1ha2VzIGl0IHBvc3NpYmxlIGZvciB3aWRlbHkgZGVwbG95 ZWQgcHJvdG9jb2xzIHRvIG5vdCBoYXZlIGFuIGFjdGl2ZSBJRVRGIFdHIChhbHRob3VnaCBzb21l dGltZXMgbWFpbGluZyBsaXN0cyBtYXkgcmVtYWluIG9wZXJhdGlvbmFsKS4gIFdoZW4gYSBXRyBp cyBhY3RpdmUsICBDaGFpcnMgaGF2ZSBhIHRlbmRlbmN5IHRvIHN0cm9uZ2x5IGVuY291cmFnZSBh IGZvY3VzIG9uIHRvcGljcyByZWxhdGluZyB0byB0aGUgQ2hhcnRlciBzbyBhcyB0byBlbmNvdXJh Z2UgZm9yd2FyZCBwcm9ncmVzcy4gIFRoaXMgY2FuIGxlYWQgdG8gSUVURiBXR3MgYmVpbmcgaW5l ZmZlY3RpdmUgaW4gcmV2aWV3aW5nIHJlbGF0ZWQgd29yayBpbiBvdGhlciBJRVRGIFdHcywgbGV0 IGFsb25lIGluIG90aGVyIFNET3MuDQoNCk9uZSBwb3RlbnRpYWwgc29sdXRpb24gdG8geW91ciBj b25jZXJucyBtaWdodCBiZSB0byBjcmVhdGUgYSBXRyB0byBkZWFsIHdpdGggIlBLSVggZXh0ZW5z aW9ucyIuICBIb3dldmVyLCBpZiB0aGUgY29yZSBuZWVkIGlzIHRvIGNyZWF0ZSBhIGZvcnVtIHdo aWNoIGNhbiBiZSB1c2VkIHRvIHN0cmVuZ3RoZW4gUEtJIHV0aWxpemF0aW9uIGJvdGggaW4gdGhl IElFVEYgYW5kIG91dHNpZGUgb2YgaXQsIHRoaXMgbWF5IG5vdCBiZSBzdWZmaWNpZW50LiAgRm9y IGV4YW1wbGUsIHByb3Zpc2lvbiBtYXkgbmVlZCB0byBiZSBtYWRlIGZvciByZXZpZXcgb2Ygc3Bl Y2lmaWNhdGlvbnMgKGUuZy4gIlBLSVggZG9jdG9ycyIpLCBvciBmb3Igc3VpdGFibGUgbGlhaXNv biBhcnJhbmdlbWVudHMgc28gYXMgdG8gZW5jb3VyYWdlIGNvb3BlcmF0aW9uIGJldHdlZW4gU0RP cyBvbiBQS0kgdG9waWNzLg0KDQpXaXRoIHJlc3BlY3QgdG8gdGhlIG1lbWUgdGhhdCAiUEtJcyBk byBub3Qgd29yayIsIG15IG9ic2VydmF0aW9uIGlzIHRoYXQgdGhlIElFVEYgc2VlbXMgdG8gcGF5 IG1vcmUgYXR0ZW50aW9uIHRvIGRldmVsb3BtZW50cyBpbiB0aGUgImJpZyBJIiBJbnRlcm5ldCwg dGhhbiB0byBkZXZlbG9wbWVudHMgd2l0aGluICJsaXR0bGUgaSIgaW50ZXJuZXRzLCBzdWNoIGFz IHByaXZhdGUgZGVwbG95bWVudHMgaW4gZW50ZXJwcmlzZS4gIFBhcnQgb2YgdGhlIHJlYXNvbiBp cyB0aGF0IHBhcnRpY2lwYXRpb24gd2l0aGluIElFVEYgYW1vbmcgdXNlcnMgaGFzIGJlZW4gaW4g ZGVjbGluZSBmb3IgYSB2ZXJ5IGxvbmcgdGltZS4gIFdpdGhvdXQgdGhhdCBjdXN0b21lciBwYXJ0 aWNpcGF0aW9uLCBpdCBjYW4gYmUgZGlmZmljdWx0IGZvciB0aGUgSUVURiB0byBhc3Nlc3MgcHJv dG9jb2wgc3VjY2Vzcy4gIEhvd2V2ZXIsIGhhdmluZyBiZWVuIGludm9sdmVkIGluIHNvbWUgb2Yg dGhlIHdvcmxkJ3MgbGFyZ2VzdCBQS0kgZGVwbG95bWVudHMsIEkgdGhpbmsgaXQgaXMgc2FmZSB0 byBzYXkgdGhhdCBQS0kgY2FuIGJlIGNvbnNpZGVyZWQgInN1Y2Nlc3NmdWwiIGlmIG5vdCAid2lk ZWx5IHN1Y2Nlc3NmdWwiIGJ5IHRoZSBjcml0ZXJpYSBvZiBSRkMgNTIxOC4NCg0KDQoNCg0KDQpP biBUaHUsIEp1bCAyMCwgMjAxNyBhdCA0OjM1IEFNLCBEci4gUGFsYSA8ZGlyZWN0b3JAb3BlbmNh Lm9yZzxtYWlsdG86ZGlyZWN0b3JAb3BlbmNhLm9yZz4+IHdyb3RlOg0KDQpIaSBhbGwsDQoNCkkg d291bGQgbGlrZSB0byBkcmF3IHRoZSBTZWMgQXJlYSBhdHRlbnRpb24gb24gYW4gaXNzdWUgdGhh dCBJIHRoaW5rIGlzIGJlY29taW5nIG1vcmUgcmVsZXZhbnQgZXZlcnkgZGF5Lg0KDQpJdCBzZWVt cyBxdWl0ZSBjbGVhciB0aGF0IHRvZGF5IHRoZXJlIGlzIGEgbG90IG9mIHdvcmsgYXJvdW5kIGF1 dGhlbnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9uIHRoYXQgbWFrZSB1c2Ugb2YgUEtJWCBjZXJ0aWZp Y2F0ZXMuIEhvd2V2ZXIsIHRoZXJlIGlzIG5vIHBsYWNlIGluIElFVEYsIHRvZGF5LCB3aGVyZSBw cm9ibGVtcyByZWxhdGVkIHRvIFBLSVggY2FuIGJlIGVmZmVjdGl2ZWx5IHRhY2tsZWQuIEluIHRo ZSBmb2xsb3dpbmcgcGFyYWdyYXBocyBJIHRyeSB0byBzdW1tYXJpemUgdGhlIGlzc3VlIGFuZCB0 aGUgcHJvcG9zZWQgd29yayBhbmQgYSBjYWxsIGZvciBkaXNjdXNzaW9uIGFyb3VuZCB0aGUgZmVh c2liaWxpdHkgb2YgcmVzdW1pbmcgdGhlIHdvcmsgaW4gdHdvIHBhcnRpY3VsYXIgYXJlYXM6IHJl dm9jYXRpb24gYW5kIGRpc2NvdmVyYWJpbGl0eS4NCg0KVGhlIFByb2JsZW0NCg0KV2hhdCBJIG5v dGljZWQgaW4gcmVjZW50IHByb3Bvc2FscyBpbiBtYW55IHdvcmtpbmcgZ3JvdXBzICh3aGVuIGl0 IGNvbWVzIHRvIGNlcnRpZmljYXRlIG1hbmFnZW1lbnQpIGlzIHRoYXQgbW9yZSBhbmQgbW9yZSBw ZW9wbGUgdHVybiB0b3dhcmRzIHRoZSB1c2Ugb2Ygc2hvcnQtbGl2ZWQgY2VydGlmaWNhdGVzIHRv IGF2b2lkIGNoZWNraW5nIHJldm9jYXRpb24gaW5mb3JtYXRpb24uIFNvbWV0aW1lcyB0aGlzIGNo b2ljZSBpcyBtb3RpdmF0ZWQgYnkgcmVhbCB0ZWNobmljYWwgY29uc2lkZXJhdGlvbnMsIGJ1dCBp biBtYW55IGNhc2VzIHRoZSBjaG9pY2UgaXMgImZvcmNlZCIgYmVjYXVzZSBub2JvZHkgaXMgY3Vy cmVudGx5IHdvcmtpbmcgb24gZml4aW5nIHRoZSB0d28gbWFpbiBpc3N1ZXMgcmVsYXRlZCB0byB0 cnVzdCBpbmZyYXN0cnVjdHVyZXM6IGVmZmljaWVudCByZXZvY2F0aW9uIGFuZCBkaXNjb3ZlcmFi aWxpdHkgb2Ygc2VydmljZXMuDQoNClRoZSBSZXZvY2F0aW9uIFNpdHVhdGlvbg0KDQpNb3N0IG9m IHRoZSB0aW1lcywgd2hlbiBpbnRlcmFjdGluZyB3aXRoIFBLSXMsIHdlIGFyZSBzdGlsbCBzdHVj ayB3aXRoIENSTHMsIE9DU1AgaWYgd2UgYXJlIGx1Y2t5IChpbmNsdWRpbmcgc3RhcGxpbmcgLSBh dmFpbGFibGUgaW4gVExTIGNvbm5lY3Rpb25zIGlmIHJlYWxseSByZWFsbHkgbHVja3kpLCBhbmQg aW4gbW9zdCBjYXNlcyBldmVuIHRoZXNlIG1lY2hhbmlzbXMgYXJlIGNyaXRpY2l6ZWQgd2lkZWx5 IGJ5IHBlb3BsZSBhcyBiZWluZyBpbmFkZXF1YXRlIHRvZGF5LiBUaGlzIHJlc3VsdGVkIGluIGFw cGxpY2F0aW9ucyB0byB1c2UgcHJvcHJpZXRhcnkgbWV0aG9kcyBmb3IgY2hlY2tpbmcgcmV2b2Nh dGlvbiAoZS5nLiwgQ1JMU2V0KSBvciB0byBza2lwIGNoZWNraW5nIGFsbCB0b2dldGhlciAob3Ig bWFuZGF0ZSBmb3Igc2hvcnQtbGl2ZWQgY2VydGlmaWNhdGVzIG9ubHkgYXMgaW4gdGhlIGNhc2Us IGZvciBleGFtcGxlLCBvZiBTVElSKS4NCg0KTWFueSBwZW9wbGUgdG9kYXkgaWdub3JlIHRoZSBm YWN0IHRoYXQsIHdoZW4gY291cGxlZCB3aXRoIHNtYWxsIGRldmljZXMsIHRoZSBnZW5lcmF0aW9u IG9mIG5ldyBrZXlzIHJlcXVpcmUgKGEpIGEgbG90IG9mIHJlc291cmNlcywgYW5kIChiKSBhIGdv b2Qgc291cmNlIG9mIHJhbmRvbW5lc3MuIFJlcXVpcmluZyBhcHBzIC8gZGV2aWNlcyB0byBnZW5l cmF0ZSBuZXcga2V5cyBtaWdodCBzZWVtIGEgZ29vZCBpZGVhIGF0IGZpcnN0LCBidXQgaXMgdGhp cyBiZXR0ZXIgdGhhbiBjaGVja2luZyByZXZvY2F0aW9uID8gV2hhdCBhYm91dCB0aGUgY29tcGxl eGl0eSBvZiBrZXkgbWFuYWdlbWVudCA/DQoNCkV4YW1wbGVzIG9mIHBvc3NpYmxlIHdvcmsgdG8g YWRkcmVzcyB0aGUgaXNzdWVzIGFyZSBPQ1NQIG92ZXIgRE5TIGFuZCBzb21lIG1vcmUgZWZmaWNp ZW50IHdheXMgdG8gdmVyaWZ5IHRoZSB2YWxpZGl0eSBvZiBhIHdob2xlIGNoYWluIG9mIGNlcnRp ZmljYXRlcyBlZmZpY2llbnRseS4NCg0KVGhlIERpc2NvdmVyYWJpbGl0eSBTaXR1YXRpb24NCg0K QXMgZmFyIGFzIEkga25vdywgdGhlcmUgYXJlIG5vIHN0YW5kYXJkaXplZCBtZWNoYW5pc21zIHRo YXQgd291bGQgcHJvdmlkZSBkaXNjb3ZlcmFiaWxpdHkgb2Ygc2VydmljZXMgdGhhdCB3b3VsZCBo ZWxwIHVzZXJzIGFuZCBhcHBsaWNhdGlvbnMgdG8gZGlzY292ZXIgUHVibGljIEtleSBTZXJ2aWNl cyBwcm92aWRlcnMgYW5kIGFzc29jaWF0ZWQgc2VydmljZXMgaW4gYSBkeW5hbWljIGZhc2hpb24u IFdoZW4gSSBicm91Z2h0IGl0IHVwIGR1cmluZyB0aGUgQm9GcyBvZiBwb3NzaWJsZSB3b3JraW5n IGdyb3VwcyB3aGVyZSB0aGUgaXNzdWUgY291bGQgYmUgZGlzY3Vzc2VkLi4gd2VsbCwgdGhlIHBy b3Bvc2FsIHdhcyByZWRpcmVjdGVkIHRvIC9kZXYvbnVsbCAoZS5nLiwgQUNNRSwgU1BBU00sIGFu ZCBMQU1QUykuDQoNCklzbid0IHRoYXQgY3VyaW91cyB0aGF0IHN0aWxsIHRvZGF5IG5vYm9keSBp cyB3b3JraW5nIG9uIHNvbWUgc29ydCBvZiBpbmZyYXN0cnVjdHVyZSB0aGF0IHdvdWxkIGZhY2ls aXRhdGUgaW50ZXJhY3Rpbmcgd2l0aCBQS0lzID8gQWZ0ZXIgYWxsLCBQS0lzIGFyZSB0aGUgY29y ZSBUcnVzdCBtZWNoYW5pc20gdGhhdCBlbmFibGVzIHJlbGlhYmxlIGF1dGhlbnRpY2F0aW9uIGFu ZCBlbmNyeXB0aW9uIG92ZXIgdGhlIEludGVybmV0IHRvZGF5LiBTdWNoIGluZnJhc3RydWN0dXJl IGNvdWxkIHJlYWxseSBpbXByb3ZlIHRoZSBzZWN1cml0eSBvZiB0aGUgSW50ZXJuZXQgYW5kIG1h a2UgUEtJcyBtb3JlIHVzYWJsZSBmcm9tIGFuIGFwcGxpY2F0aW9uIChhbmQgdXNlcnMpIHN0YW5k cG9pbnQgb2Ygdmlldy4NCg0KRXhhbXBsZXMgb2YgcG9zc2libGUgd29yayB0byBhZGRyZXNzIHRo ZSBpc3N1ZSBhcmUgYSBQS0kgUmVzb3VyY2UgUXVlcnkgUHJvdG9jb2wgKFBSUVApIGFuZC9vciB0 aGUgdXNlIG9mIFAyUCBzeXN0ZW1zIGFzIGRpc3RyaWJ1dGlvbiBtZWNoYW5pc21zIGZvciBQdWJs aWMgS2V5IHJlbGF0ZWQgb3BlcmF0aW9ucyAoZS5nLiwgRVNULCBCUlNLSSwgb3IgQUNNRSBvdmVy IFAyUCAtIDAtY29uZmlndXJhdGlvbiBzdXBwb3J0IGZvciBQSykuDQoNCkRlcGxveW1lbnQgVHJl bmRzIGluIHRoZSBSZWFsIFdvcmxkDQoNClRvZGF5IEkgYW0gd2l0bmVzc2luZyB0aGUgZGVwbG95 bWVudCBvZiBhcmd1YWJseSBub3Qtd2VsbC1kZXNpZ25lZCBQS0lzIChvciwgaW4gb3RoZXIgdGVy bXMsIHdoYXQgSSBjYWxsIFdlYWsgUEtJcykgdGhhdCBkbyBub3QgcHJvdmlkZSBzdXBwb3J0IGZv ciByZXZvY2F0aW9uIGFuZCB0aGF0IGFyZSBleHBlY3RlZCB0byB1c2UgQ0FzIGFuZCBFRSBjZXJ0 aWZpY2F0ZXMgd2l0aCB2YWxpZGl0eSBwZXJpb2RzIG9mIDMwLCAzNSwgb3IgNTAgeWVhcnMgKHll cywgYWxzbyBFRSAtIGVzcGVjaWFsbHkgZm9yIGRldmljZXMpLiBCZXNpZGVzIHRoZSBmYWN0IHRo YXQgaXQgaXMgYSBjb21tb24gYXNzdW1wdGlvbiB0aGF0IHRoZSBhbGdvcml0aG1zIChlLmcuLCBQ LTI1NikgdXNlZCBpbiB0aGVzZSBlbnZpcm9ubWVudHMgKGUuZy4gSW9UKSBhcmUgTk9UIGdvaW5n IHRvIHBhc3MgdGhlIHRlc3Qgb2YgdGltZSwgaWdub3JpbmcgdGhlIHJldm9jYXRpb24gY291bGQg cmVhbGx5IGFmZmVjdCB0aGUgcHJpdmFjeSBvZiBtaWxsaW9ucyBvZiBwZW9wbGUgLSBhbmQgd2Ug YXJlIGN1cnJlbnRseSBub3QgZG9pbmcgYW55dGhpbmcgYXQgdGhlIElFVEYgdG8gcHJldmVudCB0 aGlzIGlzc3VlLg0KDQpUaGVyZSBpcyB0aGUgbmVlZCBmb3Igc2ltcGxlIHJldm9jYXRpb24gc2Vy dmljZXMsIGJ1dCBhcmd1YWJseSB3ZSBkbyBub3QgaGF2ZSB3aGF0J3MgbmVlZGVkIHRvZGF5IChy ZXF1aXJlcyBpbXByb3ZlbWVudHMpLg0KDQpJRVRGIFNwZWNpZmljIFNpdHVhdGlvbiBhbmQgSXNz dWVzDQoNCldoeSBhcmUgd2Ugc28gdW5wcmVwYXJlZCB0byBmYWNlIHRoZXNlIGlzc3VlcyA/IEkg d291bGQgc2F5IChzdGlsbCBwZXJzb25hbCBwb2ludCBvZiB2aWV3IC0gYmFzZWQgb24gYWxtb3N0 IDIwIHlycyBvZiBwYXJ0aWNpcGF0aW9uIGluIFBLSSBkaXNjdXNzaW9ucykgdGhhdCB0aGVzZSBt aWdodCBiZSBzb21lIG9mIHRoZSBtYWluIHJlYXNvbnM6DQoNCiAgKiAgIFRoZXJlIGFyZSBOTyB2 ZW51ZXMgd2hlcmUgdG8gZGlzY3VzcyBwb3NzaWJsZSBzb2x1dGlvbnMgdG8gZXhpc3RpbmcgcHJv YmxlbXMuIFRoZSBQS0lYIHdvcmtpbmcgZ3JvdXAgaGFzIGJlZW4gY2xvc2VkIGRvd24gKHZlcnkg YXJiaXRyYXJpbHksIEkgbWlnaHQgc2F5LCBzaW5jZSB0aGVyZSBpcyBzdGlsbCBhIGxvdCBvZiB3 b3JrIG5lZWRlZCB0byBiZSBkb25lIGFyb3VuZCBQS0lYIGFzIGhpZ2hsaWdodGVkIGFib3ZlKQ0K DQogICogICBUaGUgTEFNUFMsIFNQQVNNLCBhbmQgQUNNRSBXR3MgaGF2ZS9oYXZlIGhhZCwgb24g cHVycG9zZSwgdmVyeSBuYXJyb3cgc2NvcGVkIENoYXJ0ZXJzIGFuZCBvbmx5IGZldyBpdGVtcyAo bW9zdGx5IHF1aXRlIG1hcmdpbmFsIGlzc3VlcywgSU1PKSBhcmUgYWN0dWFsbHkgYWNjZXB0ZWQg YXMgd29ya2luZyBpdGVtcyAody8gcmVmZXJlbmNlIHRvIFNQQVNNIGFuZCBMQU1QUyBpbiBwYXJ0 aWN1bGFyKS4gU29sdmluZyByZXZvY2F0aW9uIGFuZCBkaXNjb3ZlcmFiaWxpdHkgaXNzdWVzIHNo b3VsZCBiZSB0aGUgMXN0IGl0ZW0gYW5kIHRoZSBtb3N0IGltcG9ydGFudCBvbiB0aGUgbGlzdCAo YXQgbGVhc3QgcmV2b2NhdGlvbikgYnV0IHRoZXkgYXJlIG5vdCAtIGFjdHVhbGx5IHdoZW4gdGhh dCB3YXMgcHJvcG9zZWQgdG8gYmUgaW5jbHVkZWQgYXMgcGFydCBvZiB0aGUgY2hhcnRlcihzKSwg dGhlIHJlcXVlc3RzIHdlcmUgbm90IGV2ZW4gYWNrbm93bGVkZ2VkIG9yIHJlamVjdGVkIHdpdGgg bm8gcmVhbCB0ZWNobmljYWwgcmVhc29ucy4NCg0KICAqICAgVGhlIGNvbnN0YW50IG5vbnNlbnNl IG9mIHBlb3BsZSBzYXlpbmcgdGhhdCBQS0lzIGRvIG5vdCB3b3JrIGFzIGFuIGV4Y3VzZSBub3Qg dG8gaW1wcm92ZSB0aGVtIHdoaWxlIHRoZXkgKFBLSXMpIGFyZSB0aGUgcmVhc29uIHdlIGNhbiBk ZXBsb3kgc2VjdXJlIHByb3RvY29scyBhbmQgcHJvdmlkZSBwcml2YWN5LiBJdCBpcyBldmlkZW50 IHRoYXQgUEtJcyBhcmUgaGVyZSB0byBzdGF5LCB0aGlzIGlzIGEgZmFjdC4gVGhlaXIgdXNhZ2Ug aGFzIGluY3JlYXNlZCBleHBvbmVudGlhbGx5IGluIHRoZSBwYXN0IHllYXJzIGFuZCB0aGV5IGhh dmUsIHNvIGZhciwgcGFzc2VkIHRoZSB0ZXN0IG9mIHRpbWUuIElvVCBpcyBvbmUgdXNlLWNhc2Uu IEFOSU1BIGlzIGFub3RoZXIuIEFDTUUgaXMgYW5vdGhlci4gSnVzdCB0byBjaXRlIGZldyBvZiB0 aGVtLg0KDQpNb3Jlb3ZlciwgdGhpbmdzIGFyZSBoYXBwZW5pbmcgaW4gZW52aXJvbm1lbnRzIG91 dHNpZGUgSUVURiAoV0lGSSAyLjAgQWxsaWFuY2UsIE9wZW5BRFIsIENNSSwgZXRjLikgYW5kIElF VEYgdW4td2lsbGluZ25lc3Mgb2Ygd29ya2luZyBvbiB0aGVzZSBwcm9ibGVtcyBpcyByZWFsbHkg c2NhcnkgdG8gbWUuIFRoZSB3b3JsZCBtb3ZlcyBmb3J3YXJkLCBmYXN0LCBhbmQgdGhlIElFVEYg aXMgc3RhbmRpbmcgc3RpbGwgb24gdGhpcyB0b3BpYy4gSSByZWFsbHkgZG8gbm90IHVuZGVyc3Rh bmQgd2h5Lg0KDQpGaW5hbCBDb25zaWRlcmF0aW9ucw0KDQpJbiB0aGlzIG1lc3NhZ2UgSSB0cnkg dG8gc3VtbWFyaXplIHRoZSByZWFzb25zIHdoeSBJIHRoaW5rIHRoZXJlIGlzIHRoZSBuZWVkIHRv IHByb3ZpZGUgYSB2ZW51ZSB3aGVyZSB0aGVzZSBwcm9ibGVtcyBhcmUgZGlzY3Vzc2VkIGFuZCB0 aGUgbmVlZCBmb3Iga2V5IHBlb3BsZSB0byBub3QgYWN0aXZlbHkgYmxvY2sgdGhlIHBvc3NpYmls aXR5IGZvciBwZW9wbGUgdGhhdCBhcmUgd2lsbGluZyB0byB3b3JrIG9uIHRoaXMgdG8gaGF2ZSBh IHZlbnVlIHdoZXJlIHRoZSB3b3JrIGNhbiBiZSBjYXJyaWVkIG91dC4NCg0KSSB0aGluayB0aGF0 IHRoaXMgd29yayBpcyBvZiB0aGUgdXR0ZXIgaW1wb3J0YW5jZSBhbmQgSSB3b3VsZCBsaWtlIHRv IHVuZGVyc3RhbmQgd2hhdCB0aGUgcG9zaXRpb24gb2YgdGhlIHdob2xlIHNlY3VyaXR5IGFyZWEg aXMgYXJvdW5kIHRoZXNlIHBvaW50cyBhbmQgdGhlIHByb3Bvc2VkIHdvcmsuDQoNCkkgaG9wZSB0 aGF0IHRoZSBkaXNjdXNzaW9uIGFyb3VuZCB0aGlzIG1lc3NhZ2UgY2FuIHNwYXJrIHNvbWUgaW50 ZXJlc3QgYW5kIHRoYXQgd29yayBpbiB0aGUgUEtJWCBhcmVhIGNhbiBmaW5hbGx5IHJlc3VtZSBh dCB0aGUgSUVURiAtIHdoaWNoIHdhcywgaW4gdGhlIHBhc3QsIHRob3VnaHQgb2YgYXMgdGhlIGxp Z2h0aG91c2Ugd2hlcmUgdGhlc2UgaXNzdWVzIGNvdWxkIGJlIGFkZHJlc3NlZC4NCg0KQSBzbWFs bCByZXF1ZXN0LCBwbGVhc2UsIHRyeSB0byByZWFkIHRoaXMgZS1tYWlsIGNhcmVmdWxseSBhbmQg Y29uc2lkZXIgdGhlIGltcGxpY2F0aW9ucyBvZiBOT1QgdGFraW5nIG9uIHRoZXNlIHRhc2tzIHdo ZW4gcmVwbHlpbmcgYW5kL29yIGRpc2N1c3NpbmcgdGhlIHRvcGljLiBBbHNvLCBzaW5jZSBJIGtu b3cgdGhpcyAoUEtJWCkgaXMgYSBtaW5lZmllbGQgZm9yICJwb2xpdGljYWwiIHJlYXNvbnMgKHdo aWNoIHNob3VsZCBub3QgYmUgYSBkcml2ZSBoZXJlKSwgcGxlYXNlIGtlZXAgdGhlIGRpc2N1c3Np b24gb24gdGhlIHBvc2l0aXZlIC8gY29uc3RydWN0aXZlIHNpZGUgKHRoYW5rcykuDQoNCklmIHlv dSBmZWVsIGxpa2UgYSBwcml2YXRlIHJlc3BvbnNlIGlzIGJldHRlciB0aGFuIG9uIHRoZSBtYWls aW5nIGxpc3QsIHBsZWFzZSBqdXN0IHJlcGx5IHByaXZhdGVseS4NCg0KTG9va2luZyBmb3J3YXJk IHRvIGhlYXIgeW91ciBvcGluaW9ucyBvbiB0aGlzIGhvcGluZyB0aGF0IHRoaXMgZS1tYWlsIGNh biBiZSB0aGUgYmVnaW5uaW5nIG9mIHRoZSBlbmQgb2YgUEtJWCBzdGlsbC1zdGFuZGluZyBpc3N1 ZXMgOkQNCg0KQ2hlZXJzLA0KTWF4DQoNCi0tDQpCZXN0IFJlZ2FyZHMsDQpNYXNzaW1pbGlhbm8g UGFsYSwgUGguRC4NCk9wZW5DQSBMYWJzIERpcmVjdG9yDQo8ZWZoa2xobmNva25naGhwaC5wbmc+ DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzYWFn IG1haWxpbmcgbGlzdA0Kc2FhZ0BpZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZw0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzYWFnIG1haWxpbmcgbGlzdA0Kc2Fh Z0BpZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2FhZw0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3Rv ciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8v cGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnby5yLmxvcGV6QHRlbGVm b25pY2EuY29tDQpUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAw OTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGly aWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5m b3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1 c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4g ZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0 dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nD s24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmln ZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBx dWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkg cHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi4NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3Jt YXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRp dHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNz ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24g aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21p c3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkg dG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBp biBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQuDQoNCkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhv cyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNv bnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEg dXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDD qSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2Fk byBkZSBxdWUgYSBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3Bp YSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVn aXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9n YW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21h IHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvDQo= --_000_CA369E06BA4E4A4289CED317CAAF9B2Atelefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <982FECD8DEBAFB4EB4EDC36343C2A9BE@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGRvIHNoYXJlIG1vc3Qgb2YgTWF4 4oCZIGNvbmNlcm5zIGFuZCB3b3VsZCBkZWZpbml0ZWx5IGxpa2UgdG8gc2VlIGEgd2F5IG9mIGFk ZHJlc3NpbmcgdGhlbSwgYW5kIHRoZSBJRVRGIHNlZW1zIGEgZ29vZCBwbGFjZSBmb3IgZG9pbmcg aXQuIFRvIEJlcm5hcmTigJlzIGNvbW1lbnQgYWJvdXQgdGhlIHdpZHRoIGFuZCBsZW5ndGggb2Yg Y2hhcnRlcnMgSeKAmWQgcmVwbHkgYXNraW5nIHdoZXRoZXIgd2UgY291bGQgYXR0ZW1wdCBhbg0K IOKAnFBLSVhPUFPigJ0gZ3JvdXAsIGluIHRoZSBzYW1lIHN0eWxlIG9mIG90aGVyICpvcHMgZ3Jv dXBzLCBkZWRpY2F0ZWQgdG8gb3BlcmF0aW9uYWwgaXNzdWVzLiBBbGwgaW4gYWxsLCB0aG9zZSBj b25jZXJucyBhcmUgZXNzZW50aWFsbHkgb3BlcmF0aW9uYWwsIGFzIGZhciBhcyBJIGNhbiB0ZWxs 4oCmPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5CZSBnb29kZSw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAyMCBK dWwgMjAxNywgYXQgMTU6MDUgLCBCZXJuYXJkIEFib2JhICZsdDs8YSBocmVmPSJtYWlsdG86YmVy bmFyZC5hYm9iYUBnbWFpbC5jb20iIGNsYXNzPSIiPmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPlRoYW5rIHlvdSB2ZXJ5 IG11Y2ggZm9yIHlvdXIgdGhvdWdodGZ1bCBub3RlLiZuYnNwOw0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBzaGFyZSBhIG51bWJlciBvZiB0aGUg Y29uY2VybnMgeW91IGhhdmUgYXJ0aWN1bGF0ZWQsIHBhcnRpY3VsYXJseSBhYm91dCB0aGUgaW5j cmVhc2luZyBwcm9saWZlcmF0aW9uIG9mIHBvb3JseS10aG91Z2h0LXRocm91Z2ggY2VydGlmaWNh dGUgc2NoZW1lcywgYm90aCB3aXRoaW4gSUVURiBhbmQgb3V0c2lkZSBvZiBpdC4mbmJzcDsgV2hp bGUgaXQgaXMgbm90IGNsZWFyIHRvIG1lIHRoYXQgaGF2aW5nIGFuIElFVEYgZm9ydW0gZm9yDQog ZGlzY3Vzc2lvbiBvZiBQS0lYIGlzc3VlcyB3b3VsZCBuZWNlc3NhcmlseSByZXZlcnNlIHRoZXNl IHRyZW5kcyAoc2luY2UgZHViaW91cyBzY2hlbWVzIGJlZ2FuIHRvIHByb2xpZmVyYXRlIHdoaWxl IFBLSVggV0cgd2FzIGFjdGl2ZSwgcGFydGljdWxhcmx5IGluIHRoZSB3aXJlbGVzcyBhcmVuYSks IEkgYmVsaWV2ZSB5b3VyIGNvbmNlcm5zIGFyZSByZWFsIGFuZCBkZXNlcnZlIHRob3JvdWdoIGRp c2N1c3Npb24uJm5ic3A7PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW4gZ2VuZXJhbCwgdGhlIElFVEYgbGlrZXMgV0dzIHRv IG9wZXJhdGUgd2l0aCBuYXJyb3cgY2hhcnRlcnMgZm9yIGZpbml0ZSBwZXJpb2RzIG9mIHRpbWUs IHdoZXJlYXMgc29tZSBvdGhlciBTRE9zIG1haW50YWluIHN0YW5kaW5nIGdyb3VwcyB3aXRoIGJy b2FkIGNoYXJ0ZXJzIGZvciBsb25nIHBlcmlvZHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlzIG1ha2VzIGl0IHBvc3NpYmxlIGZv ciB3aWRlbHkgZGVwbG95ZWQgcHJvdG9jb2xzIHRvIG5vdCBoYXZlIGFuIGFjdGl2ZSBJRVRGIFdH IChhbHRob3VnaCBzb21ldGltZXMgbWFpbGluZyBsaXN0cyBtYXkgcmVtYWluIG9wZXJhdGlvbmFs KS4mbmJzcDsgV2hlbiBhIFdHIGlzIGFjdGl2ZSwgJm5ic3A7Q2hhaXJzIGhhdmUgYSB0ZW5kZW5j eSB0byBzdHJvbmdseSBlbmNvdXJhZ2UgYSBmb2N1cyBvbiB0b3BpY3MgcmVsYXRpbmcgdG8gdGhl DQogQ2hhcnRlciBzbyBhcyB0byBlbmNvdXJhZ2UgZm9yd2FyZCBwcm9ncmVzcy4mbmJzcDsgVGhp cyBjYW4gbGVhZCB0byBJRVRGIFdHcyBiZWluZyBpbmVmZmVjdGl2ZSBpbiByZXZpZXdpbmcgcmVs YXRlZCB3b3JrIGluIG90aGVyIElFVEYgV0dzLCBsZXQgYWxvbmUgaW4gb3RoZXIgU0RPcy4mbmJz cDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPk9uZSBwb3RlbnRpYWwgc29sdXRpb24gdG8geW91ciBjb25jZXJucyBtaWdodCBiZSB0byBj cmVhdGUgYSBXRyB0byBkZWFsIHdpdGggJnF1b3Q7UEtJWCBleHRlbnNpb25zJnF1b3Q7LiZuYnNw OyBIb3dldmVyLCBpZiB0aGUgY29yZSBuZWVkIGlzIHRvIGNyZWF0ZSBhIGZvcnVtIHdoaWNoIGNh biBiZSB1c2VkIHRvIHN0cmVuZ3RoZW4gUEtJIHV0aWxpemF0aW9uIGJvdGggaW4gdGhlIElFVEYg YW5kIG91dHNpZGUgb2YgaXQsIHRoaXMgbWF5IG5vdCBiZQ0KIHN1ZmZpY2llbnQuJm5ic3A7IEZv ciBleGFtcGxlLCBwcm92aXNpb24gbWF5IG5lZWQgdG8gYmUgbWFkZSBmb3IgcmV2aWV3IG9mIHNw ZWNpZmljYXRpb25zIChlLmcuICZxdW90O1BLSVggZG9jdG9ycyZxdW90OyksIG9yIGZvciBzdWl0 YWJsZSBsaWFpc29uIGFycmFuZ2VtZW50cyBzbyBhcyB0byBlbmNvdXJhZ2UgY29vcGVyYXRpb24g YmV0d2VlbiBTRE9zIG9uIFBLSSB0b3BpY3MuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XaXRoIHJlc3BlY3QgdG8gdGhlIG1l bWUgdGhhdCAmcXVvdDtQS0lzIGRvIG5vdCB3b3JrJnF1b3Q7LCBteSBvYnNlcnZhdGlvbiBpcyB0 aGF0IHRoZSBJRVRGIHNlZW1zIHRvIHBheSBtb3JlIGF0dGVudGlvbiB0byBkZXZlbG9wbWVudHMg aW4gdGhlICZxdW90O2JpZyBJJnF1b3Q7IEludGVybmV0LCB0aGFuIHRvIGRldmVsb3BtZW50cyB3 aXRoaW4gJnF1b3Q7bGl0dGxlIGkmcXVvdDsgaW50ZXJuZXRzLCBzdWNoIGFzIHByaXZhdGUgZGVw bG95bWVudHMgaW4gZW50ZXJwcmlzZS4mbmJzcDsNCiBQYXJ0IG9mIHRoZSByZWFzb24gaXMgdGhh dCBwYXJ0aWNpcGF0aW9uIHdpdGhpbiBJRVRGIGFtb25nIHVzZXJzIGhhcyBiZWVuIGluIGRlY2xp bmUgZm9yIGEgdmVyeSBsb25nIHRpbWUuJm5ic3A7IFdpdGhvdXQgdGhhdCBjdXN0b21lciBwYXJ0 aWNpcGF0aW9uLCBpdCBjYW4gYmUgZGlmZmljdWx0IGZvciB0aGUgSUVURiB0byBhc3Nlc3MgcHJv dG9jb2wgc3VjY2Vzcy4mbmJzcDsgSG93ZXZlciwgaGF2aW5nIGJlZW4gaW52b2x2ZWQgaW4gc29t ZSBvZiB0aGUgd29ybGQncw0KIGxhcmdlc3QgUEtJIGRlcGxveW1lbnRzLCBJIHRoaW5rIGl0IGlz IHNhZmUgdG8gc2F5IHRoYXQgUEtJIGNhbiBiZSBjb25zaWRlcmVkICZxdW90O3N1Y2Nlc3NmdWwm cXVvdDsgaWYgbm90ICZxdW90O3dpZGVseSBzdWNjZXNzZnVsJnF1b3Q7IGJ5IHRoZSBjcml0ZXJp YSBvZiBSRkMgNTIxOC4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUaHUsIEp1bCAyMCwgMjAxNyBhdCA0OjM1 IEFNLCBEci4gUGFsYSA8c3BhbiBkaXI9Imx0ciIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFp bHRvOmRpcmVjdG9yQG9wZW5jYS5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5kaXJlY3Rv ckBvcGVuY2Eub3JnPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1s ZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiB0ZXh0PSIjMDAwMDAw IiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0iIj4NCjxwIGNsYXNzPSIiPkhpIGFsbCw8L3A+DQo8 cCBjbGFzcz0iIj5JIHdvdWxkIGxpa2UgdG8gZHJhdyB0aGUgU2VjIEFyZWEgYXR0ZW50aW9uIG9u IGFuIGlzc3VlIHRoYXQgSSB0aGluayBpcyBiZWNvbWluZyBtb3JlIHJlbGV2YW50IGV2ZXJ5IGRh eS48YnIgY2xhc3M9IiI+DQo8L3A+DQpJdCBzZWVtcyBxdWl0ZSBjbGVhciB0aGF0IHRvZGF5IHRo ZXJlIGlzIGEgbG90IG9mIHdvcmsgYXJvdW5kIGF1dGhlbnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9u IHRoYXQgbWFrZSB1c2Ugb2YgUEtJWCBjZXJ0aWZpY2F0ZXMuIEhvd2V2ZXIsIHRoZXJlIGlzIG5v IHBsYWNlIGluIElFVEYsIHRvZGF5LCB3aGVyZSBwcm9ibGVtcyByZWxhdGVkIHRvIFBLSVggY2Fu IGJlIGVmZmVjdGl2ZWx5IHRhY2tsZWQuIEluIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBocw0KIEkg dHJ5IHRvIHN1bW1hcml6ZSB0aGUgaXNzdWUgYW5kIHRoZSBwcm9wb3NlZCB3b3JrIGFuZCBhIGNh bGwgZm9yIGRpc2N1c3Npb24gYXJvdW5kIHRoZSBmZWFzaWJpbGl0eSBvZiByZXN1bWluZyB0aGUg d29yayBpbiB0d28gcGFydGljdWxhciBhcmVhczogcmV2b2NhdGlvbiBhbmQgZGlzY292ZXJhYmls aXR5LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRoZSBQcm9ibGVt PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9iPldoYXQgSSBub3RpY2VkIGluIHJlY2Vu dCBwcm9wb3NhbHMgaW4gbWFueSB3b3JraW5nIGdyb3VwcyAod2hlbiBpdCBjb21lcyB0byBjZXJ0 aWZpY2F0ZSBtYW5hZ2VtZW50KSBpcyB0aGF0IG1vcmUgYW5kIG1vcmUgcGVvcGxlIHR1cm4gdG93 YXJkcyB0aGUgdXNlIG9mIHNob3J0LWxpdmVkIGNlcnRpZmljYXRlcyB0byBhdm9pZCBjaGVja2lu ZyByZXZvY2F0aW9uIGluZm9ybWF0aW9uLiBTb21ldGltZXMgdGhpcyBjaG9pY2UgaXMgbW90aXZh dGVkDQogYnkgcmVhbCB0ZWNobmljYWwgY29uc2lkZXJhdGlvbnMsIGJ1dCBpbiBtYW55IGNhc2Vz IHRoZSBjaG9pY2UgaXMgJnF1b3Q7Zm9yY2VkJnF1b3Q7IGJlY2F1c2Ugbm9ib2R5IGlzIGN1cnJl bnRseSB3b3JraW5nIG9uIGZpeGluZyB0aGUgdHdvIG1haW4gaXNzdWVzIHJlbGF0ZWQgdG8gdHJ1 c3QgaW5mcmFzdHJ1Y3R1cmVzOiBlZmZpY2llbnQgcmV2b2NhdGlvbiBhbmQgZGlzY292ZXJhYmls aXR5IG9mIHNlcnZpY2VzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIi PlRoZSBSZXZvY2F0aW9uIFNpdHVhdGlvbjwvYj48YnIgY2xhc3M9IiI+DQo8cCBjbGFzcz0iIj5N b3N0IG9mIHRoZSB0aW1lcywgd2hlbiBpbnRlcmFjdGluZyB3aXRoIFBLSXMsIHdlIGFyZSBzdGls bCBzdHVjayB3aXRoIENSTHMsIE9DU1AgaWYgd2UgYXJlIGx1Y2t5IChpbmNsdWRpbmcgc3RhcGxp bmcgLSBhdmFpbGFibGUgaW4gVExTIGNvbm5lY3Rpb25zIGlmIHJlYWxseSByZWFsbHkgbHVja3kp LCBhbmQgaW4gbW9zdCBjYXNlcyBldmVuIHRoZXNlIG1lY2hhbmlzbXMgYXJlIGNyaXRpY2l6ZWQg d2lkZWx5IGJ5IHBlb3BsZQ0KIGFzIGJlaW5nIGluYWRlcXVhdGUgdG9kYXkuIFRoaXMgcmVzdWx0 ZWQgaW4gYXBwbGljYXRpb25zIHRvIHVzZSBwcm9wcmlldGFyeSBtZXRob2RzIGZvciBjaGVja2lu ZyByZXZvY2F0aW9uIChlLmcuLCBDUkxTZXQpIG9yIHRvIHNraXAgY2hlY2tpbmcgYWxsIHRvZ2V0 aGVyIChvciBtYW5kYXRlIGZvciBzaG9ydC1saXZlZCBjZXJ0aWZpY2F0ZXMgb25seSBhcyBpbiB0 aGUgY2FzZSwgZm9yIGV4YW1wbGUsIG9mIFNUSVIpLjwvcD4NCjxwIGNsYXNzPSIiPk1hbnkgcGVv cGxlIHRvZGF5IGlnbm9yZSB0aGUgZmFjdCB0aGF0LCB3aGVuIGNvdXBsZWQgd2l0aCBzbWFsbCBk ZXZpY2VzLCB0aGUgZ2VuZXJhdGlvbiBvZiBuZXcga2V5cyByZXF1aXJlIChhKSBhIGxvdCBvZiBy ZXNvdXJjZXMsIGFuZCAoYikgYSBnb29kIHNvdXJjZSBvZiByYW5kb21uZXNzLiBSZXF1aXJpbmcg YXBwcyAvIGRldmljZXMgdG8gZ2VuZXJhdGUgbmV3IGtleXMgbWlnaHQgc2VlbSBhIGdvb2QgaWRl YSBhdCBmaXJzdCwNCiBidXQgaXMgdGhpcyBiZXR0ZXIgdGhhbiBjaGVja2luZyByZXZvY2F0aW9u ID8gV2hhdCBhYm91dCB0aGUgY29tcGxleGl0eSBvZiBrZXkgbWFuYWdlbWVudCA/PGJyIGNsYXNz PSIiPg0KPC9wPg0KPHAgY2xhc3M9IiI+PGkgY2xhc3M9IiI+RXhhbXBsZXMgb2YgcG9zc2libGUg d29yayB0byBhZGRyZXNzIHRoZSBpc3N1ZXMgYXJlIE9DU1Agb3ZlciBETlMgYW5kIHNvbWUgbW9y ZSBlZmZpY2llbnQgd2F5cyB0byB2ZXJpZnkgdGhlIHZhbGlkaXR5IG9mIGEgd2hvbGUgY2hhaW4g b2YgY2VydGlmaWNhdGVzIGVmZmljaWVudGx5LjwvaT48YnIgY2xhc3M9IiI+DQo8L3A+DQo8cCBj bGFzcz0iIj48YiBjbGFzcz0iIj5UaGUgRGlzY292ZXJhYmlsaXR5IFNpdHVhdGlvbjwvYj48L3A+ DQo8cCBjbGFzcz0iIj5BcyBmYXIgYXMgSSBrbm93LCB0aGVyZSBhcmUgbm8gc3RhbmRhcmRpemVk IG1lY2hhbmlzbXMgdGhhdCB3b3VsZCBwcm92aWRlIGRpc2NvdmVyYWJpbGl0eSBvZiBzZXJ2aWNl cyB0aGF0IHdvdWxkIGhlbHAgdXNlcnMgYW5kIGFwcGxpY2F0aW9ucyB0byBkaXNjb3ZlciBQdWJs aWMgS2V5IFNlcnZpY2VzIHByb3ZpZGVycyBhbmQgYXNzb2NpYXRlZCBzZXJ2aWNlcyBpbiBhIGR5 bmFtaWMgZmFzaGlvbi4gV2hlbiBJIGJyb3VnaHQgaXQNCiB1cCBkdXJpbmcgdGhlIEJvRnMgb2Yg cG9zc2libGUgd29ya2luZyBncm91cHMgd2hlcmUgdGhlIGlzc3VlIGNvdWxkIGJlIGRpc2N1c3Nl ZC4uIHdlbGwsIHRoZSBwcm9wb3NhbCB3YXMgcmVkaXJlY3RlZCB0byAvZGV2L251bGwgKGUuZy4s IEFDTUUsIFNQQVNNLCBhbmQgTEFNUFMpLjxiciBjbGFzcz0iIj4NCjwvcD4NCjxwIGNsYXNzPSIi Pklzbid0IHRoYXQgY3VyaW91cyB0aGF0IHN0aWxsIHRvZGF5IG5vYm9keSBpcyB3b3JraW5nIG9u IHNvbWUgc29ydCBvZiBpbmZyYXN0cnVjdHVyZSB0aGF0IHdvdWxkIGZhY2lsaXRhdGUgaW50ZXJh Y3Rpbmcgd2l0aCBQS0lzID8gQWZ0ZXIgYWxsLCBQS0lzIGFyZSB0aGUgY29yZSBUcnVzdCBtZWNo YW5pc20gdGhhdCBlbmFibGVzIHJlbGlhYmxlIGF1dGhlbnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9u IG92ZXIgdGhlIEludGVybmV0DQogdG9kYXkuIFN1Y2ggaW5mcmFzdHJ1Y3R1cmUgY291bGQgcmVh bGx5IGltcHJvdmUgdGhlIHNlY3VyaXR5IG9mIHRoZSBJbnRlcm5ldCBhbmQgbWFrZSBQS0lzIG1v cmUgdXNhYmxlIGZyb20gYW4gYXBwbGljYXRpb24gKGFuZCB1c2Vycykgc3RhbmRwb2ludCBvZiB2 aWV3LjwvcD4NCjxwIGNsYXNzPSIiPjxpIGNsYXNzPSIiPkV4YW1wbGVzIG9mIHBvc3NpYmxlIHdv cmsgdG8gYWRkcmVzcyB0aGUgaXNzdWUgYXJlIGEgUEtJIFJlc291cmNlIFF1ZXJ5IFByb3RvY29s IChQUlFQKSBhbmQvb3IgdGhlIHVzZSBvZiBQMlAgc3lzdGVtcyBhcyBkaXN0cmlidXRpb24gbWVj aGFuaXNtcyBmb3IgUHVibGljIEtleSByZWxhdGVkIG9wZXJhdGlvbnMgKGUuZy4sIEVTVCwgQlJT S0ksIG9yIEFDTUUgb3ZlciBQMlAgLSAwLWNvbmZpZ3VyYXRpb24NCiBzdXBwb3J0IGZvciBQSyku PC9pPjxiciBjbGFzcz0iIj4NCjwvcD4NCjxwIGNsYXNzPSIiPjxiIGNsYXNzPSIiPkRlcGxveW1l bnQgVHJlbmRzIGluIHRoZSBSZWFsIFdvcmxkPC9iPjxiciBjbGFzcz0iIj4NCjwvcD4NCjxwIGNs YXNzPSIiPlRvZGF5IEkgYW0gd2l0bmVzc2luZyB0aGUgZGVwbG95bWVudCBvZiBhcmd1YWJseSBu b3Qtd2VsbC1kZXNpZ25lZCBQS0lzIChvciwgaW4gb3RoZXIgdGVybXMsIHdoYXQgSSBjYWxsIFdl YWsgUEtJcykgdGhhdCBkbyBub3QgcHJvdmlkZSBzdXBwb3J0IGZvciByZXZvY2F0aW9uIGFuZCB0 aGF0IGFyZSBleHBlY3RlZCB0byB1c2UgQ0FzIGFuZCBFRSBjZXJ0aWZpY2F0ZXMgd2l0aCB2YWxp ZGl0eSBwZXJpb2RzIG9mIDMwLCAzNSwNCiBvciA1MCB5ZWFycyAoeWVzLCBhbHNvIEVFIC0gZXNw ZWNpYWxseSBmb3IgZGV2aWNlcykuIEJlc2lkZXMgdGhlIGZhY3QgdGhhdCBpdCBpcyBhIGNvbW1v biBhc3N1bXB0aW9uIHRoYXQgdGhlIGFsZ29yaXRobXMgKGUuZy4sIFAtMjU2KSB1c2VkIGluIHRo ZXNlIGVudmlyb25tZW50cyAoZS5nLiBJb1QpIGFyZSBOT1QgZ29pbmcgdG8gcGFzcyB0aGUgdGVz dCBvZiB0aW1lLCBpZ25vcmluZyB0aGUgcmV2b2NhdGlvbiBjb3VsZCByZWFsbHkgYWZmZWN0DQog dGhlIHByaXZhY3kgb2YgbWlsbGlvbnMgb2YgcGVvcGxlIC0gYW5kIHdlIGFyZSBjdXJyZW50bHkg bm90IGRvaW5nIGFueXRoaW5nIGF0IHRoZSBJRVRGIHRvIHByZXZlbnQgdGhpcyBpc3N1ZS48L3A+ DQo8cCBjbGFzcz0iIj48aSBjbGFzcz0iIj5UaGVyZSBpcyB0aGUgbmVlZCBmb3Igc2ltcGxlIHJl dm9jYXRpb24gc2VydmljZXMsIGJ1dCBhcmd1YWJseSB3ZSBkbyBub3QgaGF2ZSB3aGF0J3MgbmVl ZGVkIHRvZGF5IChyZXF1aXJlcyBpbXByb3ZlbWVudHMpLjwvaT48YnIgY2xhc3M9IiI+DQo8L3A+ DQo8cCBjbGFzcz0iIj48YiBjbGFzcz0iIj5JRVRGIFNwZWNpZmljIFNpdHVhdGlvbiBhbmQgSXNz dWVzPC9iPjxiciBjbGFzcz0iIj4NCjwvcD4NCjxwIGNsYXNzPSIiPldoeSBhcmUgd2Ugc28gdW5w cmVwYXJlZCB0byBmYWNlIHRoZXNlIGlzc3VlcyA/IEkgd291bGQgc2F5IChzdGlsbCBwZXJzb25h bCBwb2ludCBvZiB2aWV3IC0gYmFzZWQgb24gYWxtb3N0IDIwIHlycyBvZiBwYXJ0aWNpcGF0aW9u IGluIFBLSSBkaXNjdXNzaW9ucykgdGhhdCB0aGVzZSBtaWdodCBiZSBzb21lIG9mIHRoZSBtYWlu IHJlYXNvbnM6PC9wPg0KPHVsIGNsYXNzPSIiPg0KPGxpIGNsYXNzPSIiPjxiIGNsYXNzPSIiPlRo ZXJlIGFyZSBOTyB2ZW51ZXMgd2hlcmUgdG8gZGlzY3VzcyBwb3NzaWJsZSBzb2x1dGlvbnMgdG8g ZXhpc3RpbmcgcHJvYmxlbXMuPC9iPiBUaGUgUEtJWCB3b3JraW5nIGdyb3VwIGhhcyBiZWVuIGNs b3NlZCBkb3duICh2ZXJ5IGFyYml0cmFyaWx5LCBJIG1pZ2h0IHNheSwgc2luY2UgdGhlcmUgaXMg c3RpbGwgYSBsb3Qgb2Ygd29yayBuZWVkZWQgdG8gYmUgZG9uZSBhcm91bmQgUEtJWCBhcyBoaWdo bGlnaHRlZA0KIGFib3ZlKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvbGk+PGxpIGNs YXNzPSIiPjxiIGNsYXNzPSIiPlRoZSBMQU1QUywgU1BBU00sIGFuZCBBQ01FIFdHcyBoYXZlL2hh dmUgaGFkLCBvbiBwdXJwb3NlLCB2ZXJ5IG5hcnJvdyBzY29wZWQgQ2hhcnRlcnMgYW5kIG9ubHkg ZmV3IGl0ZW1zPC9iPjxiIGNsYXNzPSIiPiAobW9zdGx5IHF1aXRlIG1hcmdpbmFsIGlzc3Vlcywg SU1PKSBhcmUgYWN0dWFsbHkgYWNjZXB0ZWQgYXMgd29ya2luZyBpdGVtcyAody8gcmVmZXJlbmNl IHRvIFNQQVNNIGFuZCBMQU1QUyBpbg0KIHBhcnRpY3VsYXIpLjwvYj4gU29sdmluZyByZXZvY2F0 aW9uIGFuZCBkaXNjb3ZlcmFiaWxpdHkgaXNzdWVzIHNob3VsZCBiZSB0aGUgMXN0IGl0ZW0gYW5k IHRoZSBtb3N0IGltcG9ydGFudCBvbiB0aGUgbGlzdCAoYXQgbGVhc3QgcmV2b2NhdGlvbikgYnV0 IHRoZXkgYXJlIG5vdCAtIGFjdHVhbGx5IHdoZW4gdGhhdCB3YXMgcHJvcG9zZWQgdG8gYmUgaW5j bHVkZWQgYXMgcGFydCBvZiB0aGUgY2hhcnRlcihzKSwgdGhlIHJlcXVlc3RzIHdlcmUgbm90DQog ZXZlbiBhY2tub3dsZWRnZWQgb3IgcmVqZWN0ZWQgd2l0aCBubyByZWFsIHRlY2huaWNhbCByZWFz b25zLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvbGk+PGxpIGNsYXNzPSIiPjxiIGNs YXNzPSIiPlRoZSBjb25zdGFudDwvYj48YiBjbGFzcz0iIj4gbm9uc2Vuc2Ugb2YgcGVvcGxlIHNh eWluZyB0aGF0IFBLSXMgZG8gbm90IHdvcmsgYXMgYW4gZXhjdXNlIG5vdCB0byBpbXByb3ZlIHRo ZW0gd2hpbGUgdGhleSAoUEtJcykgYXJlIHRoZSByZWFzb24gd2UgY2FuIGRlcGxveSBzZWN1cmUg cHJvdG9jb2xzIGFuZCBwcm92aWRlIHByaXZhY3kuDQo8L2I+SXQgaXMgZXZpZGVudCB0aGF0IFBL SXMgYXJlIGhlcmUgdG8gc3RheSwgdGhpcyBpcyBhIGZhY3QuIFRoZWlyIHVzYWdlIGhhcyBpbmNy ZWFzZWQgZXhwb25lbnRpYWxseSBpbiB0aGUgcGFzdCB5ZWFycyBhbmQgdGhleSBoYXZlLCBzbyBm YXIsIHBhc3NlZCB0aGUgdGVzdCBvZiB0aW1lLiBJb1QgaXMgb25lIHVzZS1jYXNlLiBBTklNQSBp cyBhbm90aGVyLiBBQ01FIGlzIGFub3RoZXIuIEp1c3QgdG8gY2l0ZSBmZXcgb2YgdGhlbS48YnIg Y2xhc3M9IiI+DQo8L2xpPjwvdWw+DQo8cCBjbGFzcz0iIj5Nb3Jlb3ZlciwgdGhpbmdzIGFyZSBo YXBwZW5pbmcgaW4gZW52aXJvbm1lbnRzIG91dHNpZGUgSUVURiAoV0lGSSAyLjAgQWxsaWFuY2Us IE9wZW5BRFIsIENNSSwgZXRjLikgYW5kIElFVEYgdW4td2lsbGluZ25lc3Mgb2Ygd29ya2luZyBv biB0aGVzZSBwcm9ibGVtcyBpcyByZWFsbHkgc2NhcnkgdG8gbWUuIFRoZSB3b3JsZCBtb3ZlcyBm b3J3YXJkLCBmYXN0LCBhbmQgdGhlIElFVEYgaXMgc3RhbmRpbmcgc3RpbGwgb24gdGhpcw0KIHRv cGljLjxpIGNsYXNzPSIiPjxiIGNsYXNzPSIiPiBJIHJlYWxseSBkbyBub3QgdW5kZXJzdGFuZCB3 aHkuPC9iPjwvaT48L3A+DQo8cCBjbGFzcz0iIj48YiBjbGFzcz0iIj5GaW5hbCBDb25zaWRlcmF0 aW9uczwvYj48L3A+DQo8cCBjbGFzcz0iIj5JbiB0aGlzIG1lc3NhZ2UgSSB0cnkgdG8gc3VtbWFy aXplIHRoZSByZWFzb25zIHdoeSBJIHRoaW5rIHRoZXJlIGlzIHRoZSBuZWVkIHRvIHByb3ZpZGUg YSB2ZW51ZSB3aGVyZSB0aGVzZSBwcm9ibGVtcyBhcmUgZGlzY3Vzc2VkIGFuZCB0aGUgbmVlZCBm b3Iga2V5IHBlb3BsZSB0byBub3QgYWN0aXZlbHkgYmxvY2sgdGhlIHBvc3NpYmlsaXR5IGZvciBw ZW9wbGUgdGhhdCBhcmUgd2lsbGluZyB0byB3b3JrIG9uIHRoaXMgdG8gaGF2ZQ0KIGEgdmVudWUg d2hlcmUgdGhlIHdvcmsgY2FuIGJlIGNhcnJpZWQgb3V0LjwvcD4NCkkgdGhpbmsgdGhhdCB0aGlz IHdvcmsgaXMgb2YgdGhlIHV0dGVyIGltcG9ydGFuY2UgYW5kIEkgd291bGQgbGlrZSB0byB1bmRl cnN0YW5kIHdoYXQgdGhlIHBvc2l0aW9uIG9mIHRoZSB3aG9sZSBzZWN1cml0eSBhcmVhIGlzIGFy b3VuZCB0aGVzZSBwb2ludHMgYW5kIHRoZSBwcm9wb3NlZCB3b3JrLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjxpIGNsYXNzPSIiPkkgaG9wZSB0aGF0IHRoZSBkaXNjdXNzaW9uIGFyb3Vu ZCB0aGlzIG1lc3NhZ2UgY2FuIHNwYXJrIHNvbWUgaW50ZXJlc3QgYW5kIHRoYXQgd29yayBpbiB0 aGUgUEtJWCBhcmVhIGNhbiBmaW5hbGx5IHJlc3VtZSBhdCB0aGUgSUVURiAtIHdoaWNoIHdhcywg aW4gdGhlIHBhc3QsIHRob3VnaHQgb2YgYXMgdGhlIGxpZ2h0aG91c2Ugd2hlcmUgdGhlc2UgaXNz dWVzIGNvdWxkIGJlIGFkZHJlc3NlZC48L2k+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K QSBzbWFsbCByZXF1ZXN0LCBwbGVhc2UsIHRyeSB0byByZWFkIHRoaXMgZS1tYWlsIGNhcmVmdWxs eSBhbmQgY29uc2lkZXIgdGhlIGltcGxpY2F0aW9ucyBvZiBOT1QgdGFraW5nIG9uIHRoZXNlIHRh c2tzIHdoZW4gcmVwbHlpbmcgYW5kL29yIGRpc2N1c3NpbmcgdGhlIHRvcGljLiBBbHNvLCBzaW5j ZSBJIGtub3cgdGhpcyAoUEtJWCkgaXMgYSBtaW5lZmllbGQgZm9yICZxdW90O3BvbGl0aWNhbCZx dW90OyByZWFzb25zICh3aGljaCBzaG91bGQgbm90IGJlIGEgZHJpdmUNCiBoZXJlKSwgcGxlYXNl IGtlZXAgdGhlIGRpc2N1c3Npb24gb24gdGhlIHBvc2l0aXZlIC8gY29uc3RydWN0aXZlIHNpZGUg KHRoYW5rcykuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGkgY2xhc3M9IiI+SWYgeW91 IGZlZWwgbGlrZSBhIHByaXZhdGUgcmVzcG9uc2UgaXMgYmV0dGVyIHRoYW4gb24gdGhlIG1haWxp bmcgbGlzdCwgcGxlYXNlIGp1c3QgcmVwbHkgcHJpdmF0ZWx5LjwvaT48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpMb29raW5nIGZvcndhcmQgdG8gaGVhciB5b3VyIG9waW5pb25zIG9uIHRo aXMgaG9waW5nIHRoYXQgdGhpcyBlLW1haWwgY2FuIGJlIHRoZSBiZWdpbm5pbmcgb2YgdGhlIGVu ZCBvZiBQS0lYIHN0aWxsLXN0YW5kaW5nIGlzc3VlcyA6RDxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkNoZWVycyw8YnIgY2xhc3M9IiI+DQpNYXggPHNwYW4gY2xhc3M9IkhPRW5aYiI+PGZv bnQgY29sb3I9IiM4ODg4ODgiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0ibV81ODczNzc5OTE0Njc0 ODEzODczbW96LXNpZ25hdHVyZSI+PGJyIGNsYXNzPSIiPg0KLS0gPGJyIGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luLXRvcDogMTBweDsiIGNsYXNzPSIiPkJlc3QgUmVnYXJkcywNCjxkaXYg c3R5bGU9Im1hcmdpbi10b3A6NXB4O21hcmdpbi1sZWZ0OjBweCIgY2xhc3M9IiI+TWFzc2ltaWxp YW5vIFBhbGEsIFBoLkQuPGJyIGNsYXNzPSIiPg0KT3BlbkNBIExhYnMgRGlyZWN0b3I8YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJjaWQ6cGFydDEuMTNBN0JCQTMuQTg2NjVDOUVAb3Bl bmNhLm9yZyI+Jmx0O2VmaGtsaG5jb2tuZ2hocGgucG5nJmd0Ozwvc3Bhbj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzx3YnIgY2xhc3M9IiI+X19fX19fX19fX19fX19f X188YnIgY2xhc3M9IiI+DQpzYWFnIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9 Im1haWx0bzpzYWFnQGlldGYub3JnIiBjbGFzcz0iIj5zYWFnQGlldGYub3JnPC9hPjxiciBjbGFz cz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Fh ZyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi88d2JyIGNsYXNzPSIiPmxpc3RpbmZvL3NhYWc8L2E+PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyIGNsYXNzPSIiPg0Kc2FhZyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJt YWlsdG86c2FhZ0BpZXRmLm9yZyIgY2xhc3M9IiI+c2FhZ0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9 IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhYWc8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBh cHBsZS1jb250ZW50LWVkaXRlZD0idHJ1ZSIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IiBjbGFzcz0iIj4NCi0tPGJyIGNsYXNzPSIiPg0KJnF1b3Q7RXN0YSB2ZXogbm8gZmFsbGFyZW1v cywgRG9jdG9yIEluZmllcm5vJnF1b3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRHIg RGllZ28gUi4gTG9wZXo8YnIgY2xhc3M9IiI+DQpUZWxlZm9uaWNhIEkmIzQzO0Q8YnIgY2xhc3M9 IiI+DQo8YSBocmVmPSJodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8iIGNsYXNzPSIi Pmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6LzwvYT48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQplLW1haWw6IGRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb208YnIgY2xhc3M9 IiI+DQpUZWw6ICZuYnNwOyAmbmJzcDsmIzQzOzM0IDkxMyAxMjkgMDQxPGJyIGNsYXNzPSIiPg0K TW9iaWxlOiAmIzQzOzM0IDY4MiAwNTEgMDkxPGJyIGNsYXNzPSIiPg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N Cjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0iMSI+PGJy Pg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUg YSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lh ZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBv IGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRp Y2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGENCiBsZWN0dXJhLCB1dGlsaXphY2nDs24s IGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJv aGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJp ZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1 ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3Ry dWNjacOzbi48YnI+DQo8YnI+DQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgdHJh bnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBpbnRl bmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBuYW1lZCBh Ym92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24s DQogZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmlj dGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGlu IGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBz ZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3Ig YW5kIHRoZW4gZGVsZXRlIGl0Ljxicj4NCjxicj4NCkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhv cyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNv bnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEg dXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDD qSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2Fk byBkZSBxdWUgYQ0KIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8Oz cGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBs ZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCBy b2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVz bWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo288YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_CA369E06BA4E4A4289CED317CAAF9B2Atelefonicacom_-- From nobody Thu Jul 20 17:03:14 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E2C131683 for ; Thu, 20 Jul 2017 17:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RferBd74yIFo for ; Thu, 20 Jul 2017 17:03:09 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.200.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89607126B71 for ; Thu, 20 Jul 2017 17:03:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id CB3C22813B; Fri, 21 Jul 2017 00:03:08 +0000 (UTC) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo02-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQjoXQBDg7Pq; Fri, 21 Jul 2017 00:03:08 +0000 (UTC) Received: from [10.178.253.119] (unknown [204.89.11.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id EE71028085; Fri, 21 Jul 2017 00:03:06 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: Date: Thu, 20 Jul 2017 17:03:05 -0700 Cc: "saag@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8c734c87-2e57-c43d-e1bd-92f3c4ddeae3@openca.org> To: "Diego R. Lopez" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [saag] Considerations about the need to resume PKIX work X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 00:03:12 -0000 I do support reconstituting a PKIX-like group, but my personal opinion = is that the PKIX architecture is fundamentally broken. The whole idea = that an auditor in Canada can attest that a certificate issued in = Switzerland accurately represents a server in the office next door to me = is simply wrong. Before it was closed down it appeared that the people in the group had = no interest in fixing any fundamental problems. For example: the = CRL/OCSP content was revised, but intentionally did not address the = disconnect between the =E2=80=9Cunknown=E2=80=9D state in the response = and the =E2=80=9Cunknown=E2=80=9D real-world state where a CA has never = heard of the certificate. I wonder if we can avoid the problems which the PKIX WG had in the past. = I also wonder if some work on X.509 alternatives/successors isn=E2=80=99t = in order. While the situation has improved, X.509 software is still = generally buggy and unreliable. Something simpler would be better. It=E2=80=99s silly to pretend that =E2=80=9CPKIs don=E2=80=99t work=E2=80=9D= since, e.g., the Scandinavian banking industry proves they can. The = issue is we need to discourage the multiplicity of variations and = ambiguity which make it difficult to interoperate and difficult to = exhaustively test. We also need certs to be issued by the organizations = which actually know about what the certs represent (and so you don=E2=80=99= t have to read a CPS). I do think a new PKIX group could be extremely useful, but only if it = focuses on eliminating real-world complexity (like disconnects between = semantics and representation). New, shiny extensions will generally make = the situation worse. > On Jul 20, 2017, at 3:28 PM, Diego R. Lopez = wrote: >=20 > Hi, >=20 > I do share most of Max=E2=80=99 concerns and would definitely like to = see a way of addressing them, and the IETF seems a good place for doing = it. To Bernard=E2=80=99s comment about the width and length of charters = I=E2=80=99d reply asking whether we could attempt an =E2=80=9CPKIXOPS=E2=80= =9D group, in the same style of other *ops groups, dedicated to = operational issues. All in all, those concerns are essentially = operational, as far as I can tell=E2=80=A6 >=20 > Be goode, >=20 >> On 20 Jul 2017, at 15:05 , Bernard Aboba = wrote: >>=20 >> Thank you very much for your thoughtful note.=20 >>=20 >> I share a number of the concerns you have articulated, particularly = about the increasing proliferation of poorly-thought-through certificate = schemes, both within IETF and outside of it. While it is not clear to = me that having an IETF forum for discussion of PKIX issues would = necessarily reverse these trends (since dubious schemes began to = proliferate while PKIX WG was active, particularly in the wireless = arena), I believe your concerns are real and deserve thorough = discussion.=20 >>=20 >> In general, the IETF likes WGs to operate with narrow charters for = finite periods of time, whereas some other SDOs maintain standing groups = with broad charters for long periods. >>=20 >> This makes it possible for widely deployed protocols to not have an = active IETF WG (although sometimes mailing lists may remain = operational). When a WG is active, Chairs have a tendency to strongly = encourage a focus on topics relating to the Charter so as to encourage = forward progress. This can lead to IETF WGs being ineffective in = reviewing related work in other IETF WGs, let alone in other SDOs.=20 >>=20 >> One potential solution to your concerns might be to create a WG to = deal with "PKIX extensions". However, if the core need is to create a = forum which can be used to strengthen PKI utilization both in the IETF = and outside of it, this may not be sufficient. For example, provision = may need to be made for review of specifications (e.g. "PKIX doctors"), = or for suitable liaison arrangements so as to encourage cooperation = between SDOs on PKI topics.=20 >>=20 >> With respect to the meme that "PKIs do not work", my observation is = that the IETF seems to pay more attention to developments in the "big I" = Internet, than to developments within "little i" internets, such as = private deployments in enterprise. Part of the reason is that = participation within IETF among users has been in decline for a very = long time. Without that customer participation, it can be difficult for = the IETF to assess protocol success. However, having been involved in = some of the world's largest PKI deployments, I think it is safe to say = that PKI can be considered "successful" if not "widely successful" by = the criteria of RFC 5218.=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Thu, Jul 20, 2017 at 4:35 AM, Dr. Pala = wrote: >> Hi all, >>=20 >> I would like to draw the Sec Area attention on an issue that I think = is becoming more relevant every day. >> It seems quite clear that today there is a lot of work around = authentication and encryption that make use of PKIX certificates. = However, there is no place in IETF, today, where problems related to = PKIX can be effectively tackled. In the following paragraphs I try to = summarize the issue and the proposed work and a call for discussion = around the feasibility of resuming the work in two particular areas: = revocation and discoverability. >>=20 >> The Problem >>=20 >> What I noticed in recent proposals in many working groups (when it = comes to certificate management) is that more and more people turn = towards the use of short-lived certificates to avoid checking revocation = information. Sometimes this choice is motivated by real technical = considerations, but in many cases the choice is "forced" because nobody = is currently working on fixing the two main issues related to trust = infrastructures: efficient revocation and discoverability of services. >>=20 >> The Revocation Situation >> Most of the times, when interacting with PKIs, we are still stuck = with CRLs, OCSP if we are lucky (including stapling - available in TLS = connections if really really lucky), and in most cases even these = mechanisms are criticized widely by people as being inadequate today. = This resulted in applications to use proprietary methods for checking = revocation (e.g., CRLSet) or to skip checking all together (or mandate = for short-lived certificates only as in the case, for example, of STIR). >>=20 >> Many people today ignore the fact that, when coupled with small = devices, the generation of new keys require (a) a lot of resources, and = (b) a good source of randomness. Requiring apps / devices to generate = new keys might seem a good idea at first, but is this better than = checking revocation ? What about the complexity of key management ? >> Examples of possible work to address the issues are OCSP over DNS and = some more efficient ways to verify the validity of a whole chain of = certificates efficiently. >> The Discoverability Situation >>=20 >> As far as I know, there are no standardized mechanisms that would = provide discoverability of services that would help users and = applications to discover Public Key Services providers and associated = services in a dynamic fashion. When I brought it up during the BoFs of = possible working groups where the issue could be discussed.. well, the = proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS). >> Isn't that curious that still today nobody is working on some sort of = infrastructure that would facilitate interacting with PKIs ? After all, = PKIs are the core Trust mechanism that enables reliable authentication = and encryption over the Internet today. Such infrastructure could really = improve the security of the Internet and make PKIs more usable from an = application (and users) standpoint of view. >>=20 >> Examples of possible work to address the issue are a PKI Resource = Query Protocol (PRQP) and/or the use of P2P systems as distribution = mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME = over P2P - 0-configuration support for PK). >> Deployment Trends in the Real World >> Today I am witnessing the deployment of arguably not-well-designed = PKIs (or, in other terms, what I call Weak PKIs) that do not provide = support for revocation and that are expected to use CAs and EE = certificates with validity periods of 30, 35, or 50 years (yes, also EE = - especially for devices). Besides the fact that it is a common = assumption that the algorithms (e.g., P-256) used in these environments = (e.g. IoT) are NOT going to pass the test of time, ignoring the = revocation could really affect the privacy of millions of people - and = we are currently not doing anything at the IETF to prevent this issue. >>=20 >> There is the need for simple revocation services, but arguably we do = not have what's needed today (requires improvements). >> IETF Specific Situation and Issues >> Why are we so unprepared to face these issues ? I would say (still = personal point of view - based on almost 20 yrs of participation in PKI = discussions) that these might be some of the main reasons: >>=20 >> =E2=80=A2 There are NO venues where to discuss possible = solutions to existing problems. The PKIX working group has been closed = down (very arbitrarily, I might say, since there is still a lot of work = needed to be done around PKIX as highlighted above) >>=20 >> =E2=80=A2 The LAMPS, SPASM, and ACME WGs have/have had, on = purpose, very narrow scoped Charters and only few items (mostly quite = marginal issues, IMO) are actually accepted as working items (w/ = reference to SPASM and LAMPS in particular). Solving revocation and = discoverability issues should be the 1st item and the most important on = the list (at least revocation) but they are not - actually when that was = proposed to be included as part of the charter(s), the requests were not = even acknowledged or rejected with no real technical reasons. >>=20 >> =E2=80=A2 The constant nonsense of people saying that PKIs do = not work as an excuse not to improve them while they (PKIs) are the = reason we can deploy secure protocols and provide privacy. It is evident = that PKIs are here to stay, this is a fact. Their usage has increased = exponentially in the past years and they have, so far, passed the test = of time. IoT is one use-case. ANIMA is another. ACME is another. Just to = cite few of them. >> Moreover, things are happening in environments outside IETF (WIFI 2.0 = Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on = these problems is really scary to me. The world moves forward, fast, and = the IETF is standing still on this topic. I really do not understand = why. >>=20 >> Final Considerations >>=20 >> In this message I try to summarize the reasons why I think there is = the need to provide a venue where these problems are discussed and the = need for key people to not actively block the possibility for people = that are willing to work on this to have a venue where the work can be = carried out. >>=20 >> I think that this work is of the utter importance and I would like to = understand what the position of the whole security area is around these = points and the proposed work. >>=20 >> I hope that the discussion around this message can spark some = interest and that work in the PKIX area can finally resume at the IETF - = which was, in the past, thought of as the lighthouse where these issues = could be addressed. >>=20 >> A small request, please, try to read this e-mail carefully and = consider the implications of NOT taking on these tasks when replying = and/or discussing the topic. Also, since I know this (PKIX) is a = minefield for "political" reasons (which should not be a drive here), = please keep the discussion on the positive / constructive side (thanks). >>=20 >> If you feel like a private response is better than on the mailing = list, please just reply privately. >>=20 >> Looking forward to hear your opinions on this hoping that this e-mail = can be the beginning of the end of PKIX still-standing issues :D >>=20 >> Cheers, >> Max >>=20 >> --=20 >> Best Regards, >> Massimiliano Pala, Ph.D. >> OpenCA Labs Director >> >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >>=20 >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 > -- > "Esta vez no fallaremos, Doctor Infierno" >=20 > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ >=20 > e-mail: diego.r.lopez@telefonica.com > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ---------------------------------- >=20 >=20 >=20 > Este mensaje y sus adjuntos se dirigen exclusivamente a su = destinatario, puede contener informaci=C3=B3n privilegiada o = confidencial y es para uso exclusivo de la persona o entidad de destino. = Si no es usted. el destinatario indicado, queda notificado de que la = lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha = recibido este mensaje por error, le rogamos que nos lo comunique = inmediatamente por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n. >=20 > The information contained in this transmission is privileged and = confidential information intended only for the use of the individual or = entity named above. If the reader of this message is not the intended = recipient, you are hereby notified that any dissemination, distribution = or copying of this communication is strictly prohibited. If you have = received this transmission in error, do not read it. Please immediately = reply to the sender that you have received this communication in error = and then delete it. >=20 > Esta mensagem e seus anexos se dirigem exclusivamente ao seu = destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada ou = confidencial e =C3=A9 para uso exclusivo da pessoa ou entidade de = destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1rio indicado, = fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3= o e/ou c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode estar proibida em = virtude da legisla=C3=A7=C3=A3o vigente. Se recebeu esta mensagem por = erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e = proceda a sua destrui=C3=A7=C3=A3o > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag Personal email. hbhotz@oxy.edu From nobody Thu Jul 20 20:30:08 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC233131DAB for ; Thu, 20 Jul 2017 20:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=auckland.ac.nz 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 26-uUMvqdm24 for ; Thu, 20 Jul 2017 20:30:05 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7724E131DA7 for ; Thu, 20 Jul 2017 20:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1500607805; x=1532143805; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8HRsdRKOHL38+pfm00TGxvX9DU2XtSW/c8gi+68b5nE=; b=WFafapwCfJkoCO0Tp1e/gXY9JOCtCwmgqjzuJst5yz0H7ZuSuZ4nhTT7 pTdrarCEFRIjzgZ6egO/rXkM9D/aEsow/EFn8IzRmC67y4ZWDMRPYbp5f iBQL9nFR1w9BZovIjpkcQFHCPhHanzrtmMX+KRh6KR7e0pnEfgRbcSC2d Ae8e7qWrcb6y19nLy152U54/8j6JIqHjpxVzy880/5glOW91NUW/X08QC EMOuP7d2N6ar++sHK+CuIi41XgFZrgp6t8DraMoNr8JJDCXrK2Ly9TZyh 4bd4RSI9Du5N0LzDscvz3ipLZckSBH7JIOQQXVKjttuqstFFEu2DkXKj5 Q==; X-IronPort-AV: E=Sophos;i="5.40,387,1496059200"; d="scan'208";a="167046470" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from uxcn13-ogg-c.uoa.auckland.ac.nz ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Jul 2017 15:30:03 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 21 Jul 2017 15:30:03 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Fri, 21 Jul 2017 15:30:03 +1200 From: Peter Gutmann To: "Henry B (Hank) Hotz, CISSP" , "Diego R. Lopez" CC: "saag@ietf.org" Thread-Topic: [saag] Considerations about the need to resume PKIX work Thread-Index: AQHTAUxPush7YGBC00aPZ+CaHZy9FaJb5g2AgACdKYCAABp6gIABAljY Date: Fri, 21 Jul 2017 03:30:03 +0000 Message-ID: <1500607781839.88968@cs.auckland.ac.nz> References: <8c734c87-2e57-c43d-e1bd-92f3c4ddeae3@openca.org> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Considerations about the need to resume PKIX work X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 03:30:07 -0000 Henry B (Hank) Hotz, CISSP writes:=0A= =0A= >It=92s silly to pretend that =93PKIs don=92t work=94 since, e.g., the Scan= dinavian=0A= >banking industry proves they can=0A= =0A= The Scandinavian banking industry, or specifically the Norwegian one, isn't= =0A= proof that PKI works, it's proof that given a sufficiently contorted and=0A= convoluted design you can do something that involves certificates while not= =0A= really doing anything that resembles what most people would regard as PKI.= =0A= That's literally something pretending PKIs do work, I really wouldn't use t= hat=0A= as an example.=0A= =0A= And don't even talk about the Norwegian healthcare PKI, which managed to do= to=0A= their healthcare system what no Russian hacker ever could...=0A= =0A= Peter.=0A= From nobody Mon Jul 24 12:13:55 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF5C131CE5 for ; Mon, 24 Jul 2017 12:13:54 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 PVX1VeuCWy6k for ; Mon, 24 Jul 2017 12:13:52 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 8FA64131687 for ; Mon, 24 Jul 2017 12:13:52 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id x3so29685066oia.1 for ; Mon, 24 Jul 2017 12:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=y7oSEhs62zlL6dHYXAck1Hc246O3dRsFpCStaPcenOE=; b=X52OW+DetNoF0rEmL9ITppEcQnML0eqKpY4eQx1Ydt1n8ZLrUrnDX7iacNuduLNDlf KJObNFjjJelTxCFr1T3s/XyX10YOTIDlDlmM9FCsw92RvmxLnGH92ZSjODudtdZCXXyG 75DThHth+HVcq+qr5ffJCrs1ku5nw5JLlIu3iCN2MWbnWX1OHf3cErxAyjuiTBkW5mwZ FSCOBFE4zFW9tnRGCScPGROjUL+tEyKjPV46HZswo7s3yYW/FcsnD7T3lU3rN9m0CmqT QJ8E5UEMGycpLWdkM50edQW/c9b9JcPc0AydaX3MxUrzggkwuHjYDqEdbckPa/6hT00b oidw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=y7oSEhs62zlL6dHYXAck1Hc246O3dRsFpCStaPcenOE=; b=FqNmZAqqMUcoMx3ihwP2EQpP1EgIzsZVP/n+k+PaMKizITDPKivacVJfSIBDCxULUV +ZyZoZ39A28mUliGR4qipcomIexqLeEaFv52WI51mlSLolu2wU5F0nR05pgyd5jp1eOT bGJO9Br78lEeoJ2KT+hsy8bUAjlP9IE0GJjiRIDKRaeRqZHgcwQ4SCSXj7ORqxvJGKLA 1ZY7XZvpY/Y49RPlkBgoDQ8nSNcVv1VMYHTC3gW/CGZkhoWjB2isumlKq9aPsAWQ687h SJNWq53Dm49+A146YsUI6pNNegP86riA5lS9nWZE1psFCa1j7EHH8RfULlsMznhOppg1 dAjw== X-Gm-Message-State: AIVw110J8IRyB/CpssHc0Wr7LZQEyb0EDpxRHZbrmSEwNmnaoxVWT3NZ lgR3M99wodDwPWU24LyYg7vkV7Eo5HEGSVI= X-Received: by 10.202.208.79 with SMTP id h76mr8960757oig.65.1500923631739; Mon, 24 Jul 2017 12:13:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.237.18 with HTTP; Mon, 24 Jul 2017 12:13:51 -0700 (PDT) In-Reply-To: <150092332977.31997.13480610609578646985.idtracker@ietfa.amsl.com> References: <150092332977.31997.13480610609578646985.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Mon, 24 Jul 2017 22:13:51 +0300 Message-ID: To: "saag@ietf.org" Content-Type: multipart/alternative; boundary="001a113e4038e7aa0c0555150302" Archived-At: Subject: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-03.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 19:13:54 -0000 --001a113e4038e7aa0c0555150302 Content-Type: text/plain; charset="UTF-8" Hello, I've uploaded the updated version of the draft-belyavskiy-certificate- limitation-policy. The new version contains some improvements motivated by discussion after my presentation on SAAG. ---------- Forwarded message ---------- From: Date: Mon, Jul 24, 2017 at 10:08 PM Subject: New Version Notification for draft-belyavskiy-certificate-limitation-policy-03.txt To: Dmitry Belyavskiy A new version of I-D, draft-belyavskiy-certificate-limitation-policy-03.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-belyavskiy-certificate-limitation-policy Revision: 03 Title: Certificate Limitation Policy Document date: 2017-07-23 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-belyavskiy- certificate-limitation-policy-03.txt Status: https://datatracker.ietf.org/doc/draft-belyavskiy- certificate-limitation-policy/ Htmlized: https://tools.ietf.org/html/draft-belyavskiy-certificate- limitation-policy-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-belyavskiy- certificate-limitation-policy-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-belyavskiy- certificate-limitation-policy-03 Abstract: The document provides a specification of the application-level trust model. Being provided at the application level, the limitations of trust can be distributed separately using cryptographically protected format instead of hardcoding the checks into the application itself. 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 -- SY, Dmitry Belyavsky --001a113e4038e7aa0c0555150302 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello,

    I've uploaded the updated ve= rsion of the=C2=A0draft-belyavskiy-certificate-limitation-policy.=C2= =A0
    The new version contains some improvements motivated by discussion a= fter my presentation on SAAG.

    ----= ------ Forwarded message ----------
    From: = <inte= rnet-drafts@ietf.org>
    Date: Mon, Jul 24, 2017 at 10:08 PM<= br>Subject: New Version Notification for draft-belyavskiy-certificate-limit= ation-policy-03.txt
    To: Dmitry Belyavskiy <beldmit@gmail.com>



    A new version of I-D, draft-belyavskiy-certificate-limitation-policy-0= 3.txt
    has been successfully submitted by Dmitry Belyavskiy and posted to the
    IETF repository.

    Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-belyavskiy-certificate-= limitation-policy
    Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
    Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate Limitation Policy
    Document date:=C2=A0 2017-07-23
    Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
    Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
    URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draf= ts/draft-belyavskiy-certificate-limitation-policy-03.txt
    Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-belyavskiy= -certificate-limitation-policy/
    Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-belyavskiy-certificate-= limitation-policy-03
    Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-bel= yavskiy-certificate-limitation-policy-03
    Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddra= ft-belyavskiy-certificate-limitation-policy-03

    Abstract:
    =C2=A0 =C2=A0The document provides a specification of the application-level= trust
    =C2=A0 =C2=A0model.=C2=A0 Being provided at the application level, the limi= tations of
    =C2=A0 =C2=A0trust can be distributed separately using cryptographically pr= otected
    =C2=A0 =C2=A0format instead of hardcoding the checks into the application i= tself.




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

    The IETF Secretariat




    --
    SY, Dmitry Belyavsky
    --001a113e4038e7aa0c0555150302-- From nobody Mon Jul 31 09:41:14 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8F2126E3A; Mon, 31 Jul 2017 09:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJAU55H7B8KE; Mon, 31 Jul 2017 09:41:04 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id CA922131C04; Mon, 31 Jul 2017 09:41:03 -0700 (PDT) Received: from maxs-mbp.cablelabs.com (host64-111.cablelabs.com [192.160.73.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 4D7083740CC5; Mon, 31 Jul 2017 12:41:03 -0400 (EDT) To: LAMPS , PKIX , "saag@ietf.org" References: <04e73e42-7c5b-912d-cc79-7959a710927e@openca.org> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <8129749b-f608-bc38-8a5f-546c6d360b63@openca.org> Date: Mon, 31 Jul 2017 10:41:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060003020108090109000303" Archived-At: Subject: Re: [saag] [lamps] Considerations about the need to resume PKIX work X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 16:41:07 -0000 This is a cryptographically signed message in MIME format. --------------ms060003020108090109000303 Content-Type: multipart/alternative; boundary="------------55C774AE3E7DB6AD8D34BB65" Content-Language: en-US This is a multi-part message in MIME format. --------------55C774AE3E7DB6AD8D34BB65 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable [ Cross Post: Saag, PKIX, and LAMPS ] I just wanted to thank everybody for entertaining the idea of resuming=20 the identified work for PKIX - it seems that we have overall support for = the work considering the replies across the three MLs, thanks for=20 expressing your opinions. The candidate working group for picking up the work items seems LAMPS=20 (thanks Russ for considering the work), so the discussion shall probably = continue there. I will send the tentative items for the charter and=20 milestones to the mailing list and see where this will take us. Thanks again and looking forward to work on these important topics :D Cheers, Max On 7/20/17 5:43 AM, Russ Housley wrote: > Max: > > If you can turn these into separate charter items with a description=20 > of the deliverable and milestones, then we can discuss each idea on=20 > its own. Of course, in this group we expect that there be a=20 > commitment that it will be implemented. > > Russ > > >> On Jul 20, 2017, at 7:37 AM, Dr. Pala > > wrote: >> >> Hi all, >> >> I would like to draw the Sec Area attention on an issue that I think=20 >> is becoming more relevant every day. >> >> It seems quite clear that today there is a lot of work around=20 >> authentication and encryption that make use of PKIX certificates.=20 >> However, there is no place in IETF, today, where problems related to=20 >> PKIX can be effectively tackled. In the following paragraphs I try to = >> summarize the issue and the proposed work and a call for discussion=20 >> around the feasibility of resuming the work in two particular areas:=20 >> revocation and discoverability. >> >> *The Problem >> >> *What I noticed in recent proposals in many working groups (when it=20 >> comes to certificate management) is that more and more people turn=20 >> towards the use of short-lived certificates to avoid checking=20 >> revocation information. Sometimes this choice is motivated by real=20 >> technical considerations, but in many cases the choice is "forced"=20 >> because nobody is currently working on fixing the two main issues=20 >> related to trust infrastructures: efficient revocation and=20 >> discoverability of services. >> >> *The Revocation Situation* >> >> Most of the times, when interacting with PKIs, we are still stuck=20 >> with CRLs, OCSP if we are lucky (including stapling - available in=20 >> TLS connections if really really lucky), and in most cases even these = >> mechanisms are criticized widely by people as being inadequate today. = >> This resulted in applications to use proprietary methods for checking = >> revocation (e.g., CRLSet) or to skip checking all together (or=20 >> mandate for short-lived certificates only as in the case, for=20 >> example, of STIR). >> >> Many people today ignore the fact that, when coupled with small=20 >> devices, the generation of new keys require (a) a lot of resources,=20 >> and (b) a good source of randomness. Requiring apps / devices to=20 >> generate new keys might seem a good idea at first, but is this better = >> than checking revocation ? What about the complexity of key management= ? >> >> /Examples of possible work to address the issues are OCSP over DNS=20 >> and some more efficient ways to verify the validity of a whole chain=20 >> of certificates efficiently./ >> >> *The Discoverability Situation* >> >> As far as I know, there are no standardized mechanisms that would=20 >> provide discoverability of services that would help users and=20 >> applications to discover Public Key Services providers and associated = >> services in a dynamic fashion. When I brought it up during the BoFs=20 >> of possible working groups where the issue could be discussed.. well, = >> the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS= ). >> >> Isn't that curious that still today nobody is working on some sort of = >> infrastructure that would facilitate interacting with PKIs ? After=20 >> all, PKIs are the core Trust mechanism that enables reliable=20 >> authentication and encryption over the Internet today. Such=20 >> infrastructure could really improve the security of the Internet and=20 >> make PKIs more usable from an application (and users) standpoint of vi= ew. >> >> /Examples of possible work to address the issue are a PKI Resource=20 >> Query Protocol (PRQP) and/or the use of P2P systems as distribution=20 >> mechanisms for Public Key related operations (e.g., EST, BRSKI, or=20 >> ACME over P2P - 0-configuration support for PK)./ >> >> *Deployment Trends in the Real World* >> >> Today I am witnessing the deployment of arguably not-well-designed=20 >> PKIs (or, in other terms, what I call Weak PKIs) that do not provide=20 >> support for revocation and that are expected to use CAs and EE=20 >> certificates with validity periods of 30, 35, or 50 years (yes, also=20 >> EE - especially for devices). Besides the fact that it is a common=20 >> assumption that the algorithms (e.g., P-256) used in these=20 >> environments (e.g. IoT) are NOT going to pass the test of time,=20 >> ignoring the revocation could really affect the privacy of millions=20 >> of people - and we are currently not doing anything at the IETF to=20 >> prevent this issue. >> >> /There is the need for simple revocation services, but arguably we do = >> not have what's needed today (requires improvements)./ >> >> *IETF Specific Situation and Issues* >> >> Why are we so unprepared to face these issues ? I would say (still=20 >> personal point of view - based on almost 20 yrs of participation in=20 >> PKI discussions) that these might be some of the main reasons: >> >> * *There are NO venues where to discuss possible solutions to >> existing problems.* The PKIX working group has been closed down >> (very arbitrarily, I might say, since there is still a lot of >> work needed to be done around PKIX as highlighted above) >> >> * *The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very >> narrow scoped Charters and only few items**(mostly quite marginal >> issues, IMO) are actually accepted as working items (w/ reference >> to SPASM and LAMPS in particular).* Solving revocation and >> discoverability issues should be the 1st item and the most >> important on the list (at least revocation) but they are not - >> actually when that was proposed to be included as part of the >> charter(s), the requests were not even acknowledged or rejected >> with no real technical reasons. >> >> * *The constant**nonsense of people saying that PKIs do not work as >> an excuse not to improve them while they (PKIs) are the reason we >> can deploy secure protocols and provide privacy. *It is evident >> that PKIs are here to stay, this is a fact. Their usage has >> increased exponentially in the past years and they have, so far, >> passed the test of time. IoT is one use-case. ANIMA is another. >> ACME is another. Just to cite few of them. >> >> Moreover, things are happening in environments outside IETF (WIFI 2.0 = >> Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on=20 >> these problems is really scary to me. The world moves forward, fast,=20 >> and the IETF is standing still on this topic./*I really do not=20 >> understand why.*/ >> >> *Final Considerations* >> >> In this message I try to summarize the reasons why I think there is=20 >> the need to provide a venue where these problems are discussed and=20 >> the need for key people to not actively block the possibility for=20 >> people that are willing to work on this to have a venue where the=20 >> work can be carried out. >> >> I think that this work is of the utter importance and I would like to = >> understand what the position of the whole security area is around=20 >> these points and the proposed work. >> >> /I hope that the discussion around this message can spark some=20 >> interest and that work in the PKIX area can finally resume at the=20 >> IETF - which was, in the past, thought of as the lighthouse where=20 >> these issues could be addressed./ >> >> A small request, please, try to read this e-mail carefully and=20 >> consider the implications of NOT taking on these tasks when replying=20 >> and/or discussing the topic. Also, since I know this (PKIX) is a=20 >> minefield for "political" reasons (which should not be a drive here), = >> please keep the discussion on the positive / constructive side (thanks= ). >> >> /If you feel like a private response is better than on the mailing=20 >> list, please just reply privately./ >> >> Looking forward to hear your opinions on this hoping that this e-mail = >> can be the beginning of the end of PKIX still-standing issues :D >> [...] > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------55C774AE3E7DB6AD8D34BB65 Content-Type: multipart/related; boundary="------------DC6372BD571B6FE571CD48E6" --------------DC6372BD571B6FE571CD48E6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

    [ Cross Post: Saag, PKIX, and LAMPS ]

    I just wanted to thank everybody for entertaining the idea of resuming the identified work for PKIX - it seems that we have overall support for the work considering the replies across the three MLs, thanks for expressing your opinions.

    The candidate working group for picking up the work items seems LAMPS (thanks Russ for considering the work), so the discussion shall probably continue there. I will send the tentative items for the charter and milestones to the mailing list and see where this will take us.

    Thanks again and looking forward to work on these important topics :D

    Cheers,
    Max


    On 7/20/17 5:43 AM, Russ Housley wrote= :
    Max:

    If you can turn these into separate charter items with a description of the deliverable and milestones, then we can discuss each idea on its own. =A0Of course, in this group we expect that there be a commitment that it will be implemented.

    Russ


    On Jul 20, 2017, at 7:37 AM, Dr. Pala <director@openca.org> wrote:

    Hi all,

    I would like to draw the Sec Area attention= on an issue that I think is becoming more relevant every day.

    It seems quite clear that today there is a lot of work around authentication and encryption that make use of PKIX certificates. However, there is no place in IETF, today, where problems related to PKIX can be effectively tackled. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussion around the feasibility of resuming the work in two particular areas: revocation and discoverability.<= br class=3D"">
    The Problem

    What I noticed in recent proposals in many working groups (when it comes to certificate management) is that more and more people turn towards the use of short-lived certificates to avoid checking revocation information. Sometimes this choice is motivated by real technical considerations, but in many cases the choice is "forced" because nobody is currently working on fixing the two main issues related to trust infrastructures: efficient revocation and discoverability of services.

    The Revocation Situation
    =

    Most of the times, when interacting with PKIs, we are still stuck with CRLs, OCSP if we are lucky (including stapling - available in TLS connections if really really lucky), and in most cases even these mechanisms are criticized widely by people as being inadequate today. This resulted in applications to use proprietary methods for checking revocation (e.g., CRLSet) or to skip checking all together (or mandate for short-lived certificates only as in the case, for example, of STIR).

    Many people today ignore the fact that, whe= n coupled with small devices, the generation of new keys require (a) a lot of resources, and (b) a good source of randomness. Requiring apps / devices to generate new keys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of key management ?

    Examples of possible work to address the issues are OCSP over DNS and some more efficient ways to verify the validity of a whole chain of certificates efficiently.
    =

    The Discoverability Situation=

    As far as I know, there are no standardized= mechanisms that would provide discoverability of services that would help users and applications to discover Public Key Services providers and associated services in a dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be discussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS).

    Isn't that curious that still today nobody is working on some sort of infrastructure that would facilitate interacting with PKIs ? After all, PKIs are the core Trust mechanism that enables reliable authentication and encryption over the Internet today. Such infrastructure could really improve the security of the Internet and make PKIs more usable from an application (and users) standpoint of view.

    Examples of possible work to address the issue are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-configuration support for PK).

    Deployment Trends in the Real= World

    Today I am witnessing the deployment of arguably not-well-designed PKIs (or, in other terms, what I call Weak PKIs) that do not provide support for revocation and that are expected to use CAs and EE certificates with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that it is a common assumption that the algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT going to pass the test of time, ignoring the revocation could really affect the privacy of millions of people - and we are currently not doing anything at the IETF to prevent this issue.

    There is the need for simple revocation services, but arguably we do not have what's needed today (requires improvements).

    IETF Specific Situation and Issues

    Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in PKI discussions) that these might be some of the main reasons:

    • There are NO venues where = to discuss possible solutions to existing problems. The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above)

    • The LAMPS, SPASM, and ACME= WGs have/have had, on purpose, very narrow scoped Charters and only few items (mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular). Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons.

    • The constant nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them.

    Moreover, things are happening in environments outside IETF (WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these problems is really scary to me. The world moves forward, fast, and the IETF is standing still on this topic. I really do not understand why.

    Final Considerations

    In this message I try to summarize the reasons why I think there is the need to provide a venue where these problems are discussed and the need for key people to not actively block the possibility for people that are willing to work on this to have a venue where the work can be carried out.

    I think that this work is of the utter importance and I would like to understand what the position of the whole security area is around these points and the proposed work.

    I hope that the discussion around this message can spark some interest and that work in the PKIX area can finally resume at the IETF - which was, in the past, thought of as the lighthouse where these issues could be addressed.

    A small request, please, try to read this e-mail carefully and consider the implications of NOT taking on these tasks when replying and/or discussing the topic. Also, since I know this (PKIX) is a minefield for "political" reasons (which should not be a drive here), please keep the discussion on the positive / constructive side (thanks).

    If you feel like a private response is better than on the mailing list, please just reply privately.

    Looking forward to hear your opinions on this hoping that this e-mail can be the beginning of the end of PKIX still-standing issues :D
    [...]
    _______________________________________________
Spasm mailing list
Spas=
m@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

    --
    Best Regards,
    Massimiliano Pala, Ph.D.
    OpenCA Labs Director
    3D"OpenCA
    --------------DC6372BD571B6FE571CD48E6 Content-Type: image/png; name="bnnfcbolmdahhkai.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="bnnfcbolmdahhkai.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------DC6372BD571B6FE571CD48E6-- --------------55C774AE3E7DB6AD8D34BB65-- --------------ms060003020108090109000303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfUwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU+MIIEJqADAgECAhEA/bu0LJsAKXVhEpPllE0lYzANBgkq hkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE2MTEzMDAwMDAwMFoXDTE3MTEzMDIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ ARYTZGlyZWN0b3JAb3BlbmNhLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKnGg/GUuTjn0dKCEpRhVd+uiYbCjLQht+dbkvyRLm4aqlL7yHCe+21HQLIcU68ZCHT2ImpF CFFrxQMQh4KijAwkbLc8+xZZSwXeZt58qnPn5c4vcpYU5LFq1q9oDT8MXH33DhVUT/7/IDSi wRWM6FcgM6VrIjBmmvl9dW3gQaEd1bOAhO2X489fChRQYTaB6AEhqb8RSvWW7ZYzfNw8sPxV afMCzWBPpO5RmLqOciZBhAinAM9dXmP5ckg/HjJQYSjvTc7HDcg75mpr5wH8Tk/ChyIYk4CT zqONQV8HKCzZPTVmd2ZuMrliJwMFs3uEg0aBSzHjJTyAmZ89q5Mz3XsCAwEAAaOCAfEwggHt MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTGgh9JWBvcrak1 PhAWBLGrECNAjzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3Bl bmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAdIqtPcvA+g6VTYUpEo0I9Vtnrf9PiZ3OpkRL O7U78EaeUfvOotThqj74XyrIl6eYlg+EdGIIUVB1CI05wPMRlZN3/R/Tj28vWkwckLRIbpL4 A5ZQyKgA9vK15/EEBVFIpCtAI6xJX0zx6TySlIgjcca05L0JgO7nzLGD2MY/dVWEE+QBuNI+ NBci+c+9q6YDPoXOpo0Wwbe0Bq95jNNWmZwhGzc+N5rhOGZmQT4P7TnpzvMik8ugbkqWyyHa DQbLKYzM1RKS/mwcvFqjJCQgORnaCilSbfClwdWGI7vwcTR8eAzduvwG61u46Cgb57K5sMck RicpWRvEYxCCVTwnozGCBEQwggRAAgEBMIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCWCGSAFlAwQC AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA3 MzExNjQxMDJaMC8GCSqGSIb3DQEJBDEiBCAYhqq3MUv6uof29UauLhpxmoK5C/1/DUlgEIIg 4k5eKzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBAAmAmP6sozczX0Sv KagIjfhWqaSlrF2f5+E1VayKzKxOJm8epa6yXSeQ5CtSRqJYT3rDBDP+glVMhOUgRxFjsbZm 3IgW0RinDC9PMu67eRR+VAaOlHLM40cdRmujRBW1Vq1Pj01sXqNcJA5yGz1dQupyqN+NePob MVBwgtoTjQD0IEZH0m5Lbq2Q0johy34U1e6ZFiRMtQtzdELTkDEjE8UxVVCJ0vShAaqS7lWY 3JDVGk4WyVZwI8NPcyTU3oxEw3Ip6ZOdY/rDwAAPSd1AuPzDfluUOUgC++B+j5ofXjv+9RO9 Ab1PqxKlnTQfWBZ40ZPZTIZyQKYj1AZ03fbhM8cAAAAAAAA= --------------ms060003020108090109000303--