From nobody Tue Oct 3 16:42:59 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A82134234; Mon, 2 Oct 2017 18:57:58 -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 MbKjxguHUBjW; Mon, 2 Oct 2017 18:57:56 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 0559E134220; Mon, 2 Oct 2017 18:57:56 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id o52so10439764qtc.9; Mon, 02 Oct 2017 18:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=OLMwhpoM0BDL0RIVIUgFJ9YEjoSExHC+fSeABrCXts4=; b=A4VOBmotYm7+/BLYoAaflfW49i1EkxSS79T+3s81sqH1gf3L8ev/xXHu6ZCUvGza5A ASggYEpgK8zlp7pan4SJd6tLfn7UwYRPzG2ghkAQhmffGgPPFna8xsP37FM6Oc3SqHfz lv9F+l9Ce9543pBFWMj7zqX/QMKvgC5nJXrGhgRxVlez44oUb+UlxJDUlsVdo0vs+Mk9 VvG+gohwmzwjp+tYrQ4hiWlMjdLAids4aiQA73zYckEsQVXp0wOcvVyIpC5Ze/t/n7jS dvRhoemb5uJHDtTglvpbOY+oOc5uAw7KMx0sZjr9Fc91MYWnZXKyyVyN+c0a75DzTHYM /7lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=OLMwhpoM0BDL0RIVIUgFJ9YEjoSExHC+fSeABrCXts4=; b=SiMQ3ZwfZEkhH58IdagstyaPLfnPNqqYCVMuXO/OrXtezlnhmg7sZyXnXXYPxR/TXb 67s08Qvt/se5PCGBBD2WD9g01QNEWWmIPWmUIksGk5LPYIPIayqgp6SxLt3chACrlbIG Mqjh4aceVx0RwxLyv0BKj05azKHmFs750kLzsiC6DiyQ5smY4i//DYNdDaofbnvI8fVO e3vlW+EmQPiz9Ep2alpP3sLT+6KUAfcLGMRxWUYV04mnThZYSoWszeMP8vOFOmWrLKAz KO9urfpRuv4zMiy7W5dwuTG2D/rrnkMm26E44onmfAJwQceRA9/b8+TYcDGdlrPcWzzp +SHA== X-Gm-Message-State: AMCzsaUV3gBHRUXHD4mZ6BPop+twgqGoCKHzjHFdRYfmJsmjOFmXIGzD AW1D0fOLTZexr8eOhrigslk= X-Google-Smtp-Source: AOwi7QAqYrRrhIjSC7uxF/J+LkKgEZCPDpxkHgU7ZbeS1HUn6uu7h2hzDVRsKR/rEjy9EUKRKM3FKA== X-Received: by 10.200.15.218 with SMTP id f26mr1647778qtk.236.1506995875153; Mon, 02 Oct 2017 18:57:55 -0700 (PDT) Received: from SantoshBrain (pool-173-73-191-59.washdc.fios.verizon.net. [173.73.191.59]) by smtp.gmail.com with ESMTPSA id t3sm7848888qtd.8.2017.10.02.18.57.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Oct 2017 18:57:54 -0700 (PDT) From: "Santosh Chokhani" To: "'Liaison Statement Management Tool'" , "'David Waltermire'" , "'Tero Kivinen'" , "'Russ Housley'" Cc: "'Limited Additional Mechanisms for PKIX and SMIME Discussion List'" , "'Eric Rescorla'" , "'Russ Housley'" , "'Tero Kivinen'" , "'Scott Mansfield'" , "'IP Security Maintenance and Extensions Discussion List'" , "'Kathleen Moriarty'" , "'David Waltermire'" , , References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> In-Reply-To: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> Date: Mon, 2 Oct 2017 21:57:56 -0400 Message-ID: <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDus9F8NjCdvUGnLuU9orle20/kKqSaa+8g Content-Language: en-us Archived-At: X-Mailman-Approved-At: Tue, 03 Oct 2017 16:42:57 -0700 Subject: Re: [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 01:57:58 -0000 I am not sure I understand what is being said below. The link to the PDF does not add to the message body. If there is a concern about what signature algorithm is used for what type of subject key, X.509 already has that flexibility. If there is a concern about using multiple signatures on an X.509 certificate, one can use the single signature algorithm identifier to define multiple algorithms, parameters, and signatures. -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Liaison Statement Management Tool Sent: Wednesday, September 13, 2017 11:25 AM To: David Waltermire ; Tero Kivinen ; Russ Housley Cc: Limited Additional Mechanisms for PKIX and SMIME Discussion List ; Eric Rescorla ; Russ Housley ; Tero Kivinen ; Scott Mansfield ; IP Security Maintenance and Extensions Discussion List ; Kathleen Moriarty ; David Waltermire ; itu-t-liaison@iab.org; jean-paul.lemaire@univ-paris-diderot.fr Subject: [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" Title: LS on ITU-T SG17 work on quantum-safe PKI Submission Date: 2017-09-13 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1541/ From: Jean-Paul Lemaire To: David Waltermire ,Tero Kivinen ,Russ Housley Cc: David Waltermire ,IP Security Maintenance and Extensions Discussion List ,itu-t-liaison@iab.org,Limited Additional Mechanisms for PKIX and SMIME Discussion List ,Russ Housley ,Scott Mansfield ,Kathleen Moriarty ,Tero Kivinen ,Eric Rescorla Response Contacts: jean-paul.lemaire@univ-paris-diderot.fr Technical Contacts: Purpose: For information Body: ITU-T Study Group 17 is pleased to inform you that in our August/September 2017 meeting we agreed to start work on the inclusion of a proposal to include optional support for multiple public-key algorithms in Recommendation ITU-T X509 | ISO/IEC 9594-8. The industry is preparing ICT systems to be resistant to attacks by large-scale quantum computers in addition to more sophisticated attacks by conventional computing resources. Proposed was an optional feature to the X.509 certificate that provides a seamless migration capability to existing PKI systems, and is completely backwardly compatible with existing systems. While public-key key establishment algorithms are typically negotiated between peers and are generally fairly simple to update, the authentication systems typically rely on a single digital signature algorithm which are more difficult to update. This is because of the circular dependency between PKI-based identity systems and the dependent communication protocols. In order to update a PKI system, one would typically need to create a duplicate PKI system that utilizes a new digital signature algorithm and then migrate all the dependent systems one by one. This proposal eliminates the need to create such duplicate PKI systems by adding optional extensions to contain alternate public key and alternate signature, and a method for the CA to sign certificates using a layered approach to ensure that every attribute is authenticated by both signatures. The resulting certificate, while containing new quantum safe public key and signature, can still be used by existing systems relying on the classic public key and signature. Attachments: sp16-sg17-oLS-00068 https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-09-13-itu-t-sg-17 -ipsecme-lamps-ls-on-itu-t-sg17-work-on-quantum-safe-pki-attachment-1.pdf _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From Alexander.Truskovsky@isara.com Tue Oct 3 13:38:18 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D282913330C; Tue, 3 Oct 2017 13:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ylgk5km58qP; Tue, 3 Oct 2017 13:38:16 -0700 (PDT) Received: from esa2.isaracorp.com (esa2.isaracorp.com [207.107.152.176]) by ietfa.amsl.com (Postfix) with ESMTP id 10EA91332D5; Tue, 3 Oct 2017 13:38:15 -0700 (PDT) Received: from 172-1-110-12.lightspeed.sntcca.sbcglobal.net (HELO cas.isaracorp.com) ([172.1.110.12]) by ip2.isaracorp.com with ESMTP; 03 Oct 2017 20:37:51 +0000 Received: from mb.isaracorp.com (2002:ac01:6e0b::ac01:6e0b) by mb.isaracorp.com (2002:ac01:6e0b::ac01:6e0b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 3 Oct 2017 16:38:09 -0400 Received: from mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f]) by mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f%12]) with mapi id 15.00.1044.021; Tue, 3 Oct 2017 16:38:09 -0400 From: Alexander Truskovsky To: "santosh.chokhani@gmail.com" , "david.waltermire@nist.gov" , "kivinen@iki.fi" , "housley@vigilsec.com" CC: "spasm@ietf.org" , "ekr@rtfm.com" , "housley@vigilsec.com" , "Scott.Mansfield@Ericsson.com" , "ipsec@ietf.org" , "Kathleen.Moriarty.ietf@gmail.com" , "itu-t-liaison@iab.org" , "jean-paul.lemaire@univ-paris-diderot.fr" Thread-Topic: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" Thread-Index: AQHTO+sV5+bpPT0iyE2onk66kRVilaLSoMOAgAA5gIA= Date: Tue, 3 Oct 2017 20:38:09 +0000 Message-ID: <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> In-Reply-To: <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.25.5.208] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 03 Oct 2017 16:43:20 -0700 Subject: Re: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 20:39:56 -0000 VGhpcyBhbGxvd3MgWC41MDkgY2VydGlmaWNhdGVzIHRvIGNvbnRhaW4gdHdvIChvciBtb3JlKSBw dWJsaWMga2V5cyBhbmQgaXNzdWVyIHNpZ25hdHVyZXMuICBUaGUgZ29hbCB3b3VsZCBiZSB0byBl YXNlIHRoZSBtaWdyYXRpb24gb2YgUEtJIGFuZCBkZXBlbmRlbnQgcHJvdG9jb2xzIHRvIG5ldyBk aWdpdGFsIHNpZ25hdHVyZSBhbGdvcml0aG1zLiAgVGhlIG1vdGl2YXRpb24gd2FzIHRvIG1ha2Ug dGhlIFguNTA5IG1vcmUgY3J5cHRvZ3JhcGhpY2FsbHkgYWdpbGUgYW5kIHNpbXBsaWZ5IHRoZSBt aWdyYXRpb24gdG8gcXVhbnR1bS1zYWZlIGFsZ29yaXRobXMsIGJ1dCBpdCBpcyBhbGdvcml0aG0g YWdub3N0aWMuICBUaGUgbWFpbiBiZW5lZml0IG9mIHRoaXMgcHJvcG9zYWwgaXMgdGhhdCBjdXJy ZW50IHN5c3RlbXMgd2lsbCBiZSBhYmxlIHRvIHVzZSB0aGVzZSBuZXdlciBYLjUwOSBjZXJ0aWZp Y2F0ZXMgYXMgdGhleSBkbyB0b2RheSB3aXRob3V0IGFueSBtb2RpZmljYXRpb25zLCB3aGlsZSBz eXN0ZW1zIHRoYXQgd2VyZSB1cGRhdGVkIHRvIHN1cHBvcnQgcXVhbnR1bS1zYWZlIGFsZ29yaXRo bXMgY2FuIGFsc28gYmUgdXBkYXRlZCB0byB1bmRlcnN0YW5kIHRoZSBuZXdlciBYLjUwOSBmb3Jt YXQgYW5kIHVzZSBxdWFudHVtLXNhZmUgYWxnb3JpdGhtIGluc3RlYWQuDQoNCldlIGFyZSB3b3Jr aW5nIG9uIGEgZHJhZnQgdGhhdCBtaXJyb3JzIHRoZSBJVFUtVOKAmXMgd29yayB3aXRoIGEgZmV3 IHBhcnRuZXJzIGFuZCB3aWxsIHB1Ymxpc2ggaXQgZm9yIHJldmlldyBzb29uLg0KDQpBbGV4DQog ICAgDQogICAgDQogICAgT24gMjAxNy0xMC0wMiwgOTo1OCBQTSwgIklQc2VjIG9uIGJlaGFsZiBv ZiBTYW50b3NoIENob2toYW5pIiA8aXBzZWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg c2FudG9zaC5jaG9raGFuaUBnbWFpbC5jb20+IHdyb3RlOg0KICAgIA0KICAgICAgICBJIGFtIG5v dCBzdXJlIEkgdW5kZXJzdGFuZCB3aGF0IGlzIGJlaW5nIHNhaWQgYmVsb3cuICBUaGUgbGluayB0 byB0aGUgUERGDQogICAgICAgIGRvZXMgbm90IGFkZCB0byB0aGUgbWVzc2FnZSBib2R5Lg0KICAg ICAgICANCiAgICAgICAgSWYgdGhlcmUgaXMgYSBjb25jZXJuIGFib3V0IHdoYXQgc2lnbmF0dXJl IGFsZ29yaXRobSBpcyB1c2VkIGZvciB3aGF0IHR5cGUNCiAgICAgICAgb2Ygc3ViamVjdCBrZXks IFguNTA5IGFscmVhZHkgaGFzIHRoYXQgZmxleGliaWxpdHkuDQogICAgICAgIA0KICAgICAgICBJ ZiB0aGVyZSBpcyBhIGNvbmNlcm4gYWJvdXQgdXNpbmcgbXVsdGlwbGUgc2lnbmF0dXJlcyBvbiBh biBYLjUwOQ0KICAgICAgICBjZXJ0aWZpY2F0ZSwgb25lIGNhbiB1c2UgdGhlIHNpbmdsZSBzaWdu YXR1cmUgYWxnb3JpdGhtIGlkZW50aWZpZXIgdG8gZGVmaW5lDQogICAgICAgIG11bHRpcGxlIGFs Z29yaXRobXMsIHBhcmFtZXRlcnMsIGFuZCBzaWduYXR1cmVzLg0KICAgICAgICANCiAgICAgICAg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICAgICAgRnJvbTogU3Bhc20gW21haWx0bzpz cGFzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGlhaXNvbiBTdGF0ZW1lbnQNCiAg ICAgICAgTWFuYWdlbWVudCBUb29sDQogICAgICAgIFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVy IDEzLCAyMDE3IDExOjI1IEFNDQogICAgICAgIFRvOiBEYXZpZCBXYWx0ZXJtaXJlIDxkYXZpZC53 YWx0ZXJtaXJlQG5pc3QuZ292PjsgVGVybyBLaXZpbmVuDQogICAgICAgIDxraXZpbmVuQGlraS5m aT47IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+DQogICAgICAgIENjOiBMaW1p dGVkIEFkZGl0aW9uYWwgTWVjaGFuaXNtcyBmb3IgUEtJWCBhbmQgU01JTUUgRGlzY3Vzc2lvbiBM aXN0DQogICAgICAgIDxzcGFzbUBpZXRmLm9yZz47IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNv bT47IFJ1c3MgSG91c2xleQ0KICAgICAgICA8aG91c2xleUB2aWdpbHNlYy5jb20+OyBUZXJvIEtp dmluZW4gPGtpdmluZW5AaWtpLmZpPjsgU2NvdHQgTWFuc2ZpZWxkDQogICAgICAgIDxTY290dC5N YW5zZmllbGRARXJpY3Nzb24uY29tPjsgSVAgU2VjdXJpdHkgTWFpbnRlbmFuY2UgYW5kIEV4dGVu c2lvbnMNCiAgICAgICAgRGlzY3Vzc2lvbiBMaXN0IDxpcHNlY0BpZXRmLm9yZz47IEthdGhsZWVu IE1vcmlhcnR5DQogICAgICAgIDxLYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT47IERh dmlkIFdhbHRlcm1pcmUNCiAgICAgICAgPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+OyBpdHUt dC1saWFpc29uQGlhYi5vcmc7DQogICAgICAgIGplYW4tcGF1bC5sZW1haXJlQHVuaXYtcGFyaXMt ZGlkZXJvdC5mcg0KICAgICAgICBTdWJqZWN0OiBbbGFtcHNdIE5ldyBMaWFpc29uIFN0YXRlbWVu dCwgIkxTIG9uIElUVS1UIFNHMTcgd29yayBvbg0KICAgICAgICBxdWFudHVtLXNhZmUgUEtJIg0K ICAgICAgICANCiAgICAgICAgVGl0bGU6IExTIG9uIElUVS1UIFNHMTcgd29yayBvbiBxdWFudHVt LXNhZmUgUEtJIFN1Ym1pc3Npb24gRGF0ZTogMjAxNy0wOS0xMw0KICAgICAgICBVUkwgb2YgdGhl IElFVEYgV2ViIHBhZ2U6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xNTQx Lw0KICAgICAgICANCiAgICAgICAgRnJvbTogSmVhbi1QYXVsIExlbWFpcmUgPGplYW4tcGF1bC5s ZW1haXJlQHVuaXYtcGFyaXMtZGlkZXJvdC5mcj4NCiAgICAgICAgVG86IERhdmlkIFdhbHRlcm1p cmUgPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+LFRlcm8gS2l2aW5lbg0KICAgICAgICA8a2l2 aW5lbkBpa2kuZmk+LFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+DQogICAgICAg IENjOiBEYXZpZCBXYWx0ZXJtaXJlIDxkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292PixJUCBTZWN1 cml0eSBNYWludGVuYW5jZSBhbmQNCiAgICAgICAgRXh0ZW5zaW9ucyBEaXNjdXNzaW9uIExpc3Qg PGlwc2VjQGlldGYub3JnPixpdHUtdC1saWFpc29uQGlhYi5vcmcsTGltaXRlZA0KICAgICAgICBB ZGRpdGlvbmFsIE1lY2hhbmlzbXMgZm9yIFBLSVggYW5kIFNNSU1FIERpc2N1c3Npb24gTGlzdA0K ICAgICAgICA8c3Bhc21AaWV0Zi5vcmc+LFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5j b20+LFNjb3R0IE1hbnNmaWVsZA0KICAgICAgICA8U2NvdHQuTWFuc2ZpZWxkQEVyaWNzc29uLmNv bT4sS2F0aGxlZW4gTW9yaWFydHkNCiAgICAgICAgPEthdGhsZWVuLk1vcmlhcnR5LmlldGZAZ21h aWwuY29tPixUZXJvIEtpdmluZW4gPGtpdmluZW5AaWtpLmZpPixFcmljDQogICAgICAgIFJlc2Nv cmxhIDxla3JAcnRmbS5jb20+IFJlc3BvbnNlIENvbnRhY3RzOg0KICAgICAgICBqZWFuLXBhdWwu bGVtYWlyZUB1bml2LXBhcmlzLWRpZGVyb3QuZnINCiAgICAgICAgVGVjaG5pY2FsIENvbnRhY3Rz OiANCiAgICAgICAgUHVycG9zZTogRm9yIGluZm9ybWF0aW9uDQogICAgICAgIA0KICAgICAgICBC b2R5OiBJVFUtVCBTdHVkeSBHcm91cCAxNyBpcyBwbGVhc2VkIHRvIGluZm9ybSB5b3UgdGhhdCBp biBvdXINCiAgICAgICAgQXVndXN0L1NlcHRlbWJlciAyMDE3IG1lZXRpbmcgd2UgYWdyZWVkIHRv IHN0YXJ0IHdvcmsgb24gdGhlIGluY2x1c2lvbiBvZiBhDQogICAgICAgIHByb3Bvc2FsIHRvIGlu Y2x1ZGUgb3B0aW9uYWwgc3VwcG9ydCBmb3IgbXVsdGlwbGUgcHVibGljLWtleSBhbGdvcml0aG1z IGluDQogICAgICAgIFJlY29tbWVuZGF0aW9uIElUVS1UIFg1MDkgfCBJU08vSUVDIDk1OTQtOC4N CiAgICAgICAgDQogICAgICAgIFRoZSBpbmR1c3RyeSBpcyBwcmVwYXJpbmcgSUNUIHN5c3RlbXMg dG8gYmUgcmVzaXN0YW50IHRvIGF0dGFja3MgYnkNCiAgICAgICAgbGFyZ2Utc2NhbGUgcXVhbnR1 bSBjb21wdXRlcnMgaW4gYWRkaXRpb24gdG8gbW9yZSBzb3BoaXN0aWNhdGVkIGF0dGFja3MgYnkN CiAgICAgICAgY29udmVudGlvbmFsIGNvbXB1dGluZyByZXNvdXJjZXMuIFByb3Bvc2VkIHdhcyBh biBvcHRpb25hbCBmZWF0dXJlIHRvIHRoZQ0KICAgICAgICBYLjUwOSBjZXJ0aWZpY2F0ZSB0aGF0 IHByb3ZpZGVzIGEgc2VhbWxlc3MgbWlncmF0aW9uIGNhcGFiaWxpdHkgdG8gZXhpc3RpbmcNCiAg ICAgICAgUEtJIHN5c3RlbXMsIGFuZCBpcyBjb21wbGV0ZWx5IGJhY2t3YXJkbHkgY29tcGF0aWJs ZSB3aXRoIGV4aXN0aW5nIHN5c3RlbXMuDQogICAgICAgIA0KICAgICAgICBXaGlsZSBwdWJsaWMt a2V5IGtleSBlc3RhYmxpc2htZW50IGFsZ29yaXRobXMgYXJlIHR5cGljYWxseSBuZWdvdGlhdGVk DQogICAgICAgIGJldHdlZW4gcGVlcnMgYW5kIGFyZSBnZW5lcmFsbHkgZmFpcmx5IHNpbXBsZSB0 byB1cGRhdGUsIHRoZSBhdXRoZW50aWNhdGlvbg0KICAgICAgICBzeXN0ZW1zIHR5cGljYWxseSBy ZWx5IG9uIGEgc2luZ2xlIGRpZ2l0YWwgc2lnbmF0dXJlIGFsZ29yaXRobSB3aGljaCBhcmUNCiAg ICAgICAgbW9yZSBkaWZmaWN1bHQgdG8gdXBkYXRlLiBUaGlzIGlzIGJlY2F1c2Ugb2YgdGhlIGNp cmN1bGFyIGRlcGVuZGVuY3kgYmV0d2Vlbg0KICAgICAgICBQS0ktYmFzZWQgaWRlbnRpdHkgc3lz dGVtcyBhbmQgdGhlIGRlcGVuZGVudCBjb21tdW5pY2F0aW9uIHByb3RvY29scy4gSW4NCiAgICAg ICAgb3JkZXIgdG8gdXBkYXRlIGEgUEtJIHN5c3RlbSwgb25lIHdvdWxkIHR5cGljYWxseSBuZWVk IHRvIGNyZWF0ZSBhIGR1cGxpY2F0ZQ0KICAgICAgICBQS0kgc3lzdGVtIHRoYXQgdXRpbGl6ZXMg YSBuZXcgZGlnaXRhbCBzaWduYXR1cmUgYWxnb3JpdGhtIGFuZCB0aGVuIG1pZ3JhdGUNCiAgICAg ICAgYWxsIHRoZSBkZXBlbmRlbnQgc3lzdGVtcyBvbmUgYnkgb25lLg0KICAgICAgICANCiAgICAg ICAgVGhpcyBwcm9wb3NhbCBlbGltaW5hdGVzIHRoZSBuZWVkIHRvIGNyZWF0ZSBzdWNoIGR1cGxp Y2F0ZSBQS0kgc3lzdGVtcyBieQ0KICAgICAgICBhZGRpbmcgb3B0aW9uYWwgZXh0ZW5zaW9ucyB0 byBjb250YWluIGFsdGVybmF0ZSBwdWJsaWMga2V5IGFuZCBhbHRlcm5hdGUNCiAgICAgICAgc2ln bmF0dXJlLCBhbmQgYSBtZXRob2QgZm9yIHRoZSBDQSB0byBzaWduIGNlcnRpZmljYXRlcyB1c2lu ZyBhIGxheWVyZWQNCiAgICAgICAgYXBwcm9hY2ggdG8gZW5zdXJlIHRoYXQgZXZlcnkgYXR0cmli dXRlIGlzIGF1dGhlbnRpY2F0ZWQgYnkgYm90aCBzaWduYXR1cmVzLg0KICAgICAgICBUaGUgcmVz dWx0aW5nIGNlcnRpZmljYXRlLCB3aGlsZSBjb250YWluaW5nIG5ldyBxdWFudHVtIHNhZmUgcHVi bGljIGtleSBhbmQNCiAgICAgICAgc2lnbmF0dXJlLCBjYW4gc3RpbGwgYmUgdXNlZCBieSBleGlz dGluZyBzeXN0ZW1zIHJlbHlpbmcgb24gdGhlIGNsYXNzaWMNCiAgICAgICAgcHVibGljIGtleSBh bmQgc2lnbmF0dXJlLg0KICAgICAgICBBdHRhY2htZW50czoNCiAgICAgICAgDQogICAgICAgICAg ICBzcDE2LXNnMTctb0xTLTAwMDY4DQogICAgICAgICANCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbGliL2R0L2RvY3VtZW50cy9MSUFJU09OL2xpYWlzb24tMjAxNy0wOS0xMy1pdHUtdC1z Zy0xNw0KICAgICAgICAtaXBzZWNtZS1sYW1wcy1scy1vbi1pdHUtdC1zZzE3LXdvcmstb24tcXVh bnR1bS1zYWZlLXBraS1hdHRhY2htZW50LTEucGRmDQogICAgICAgIA0KICAgICAgICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICBTcGFzbSBt YWlsaW5nIGxpc3QNCiAgICAgICAgU3Bhc21AaWV0Zi5vcmcNCiAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcGFzbQ0KICAgICAgICANCiAgICAgICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgSVBzZWMg bWFpbGluZyBsaXN0DQogICAgICAgIElQc2VjQGlldGYub3JnDQogICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCiAgICAgICAgDQogICAgDQogICAgDQoN Cg== From nobody Tue Oct 3 16:43:28 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A15134212; Tue, 3 Oct 2017 13:48:37 -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 n8OT959wCdl8; Tue, 3 Oct 2017 13:48:35 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB203133073; Tue, 3 Oct 2017 13:48:34 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id d67so6171491qkg.5; Tue, 03 Oct 2017 13:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=oxvyfpIYVsvKNGw3dY43IsIQw9gG1Ghxsu1Qxu6oGkc=; b=Ks0RQRz+xbWEvUYJyeiEVItYa9GWPP+HggW9+gUiKKGJ+yNRhIYYIl7CtzbiyUrilI WIrIM0pvemx7ncs4FKjDr5Cph4zei8r2oOM+eLquPEhWqldw9hcsD9Tv+IUfxbZju5Dk 4jCBXO98LqGAnM30N5YEGrr/RumC/oJW4T/J47wFd0PZvMY+kOYFgrhPGBOEPiekhp77 +iVoStLBQp71kjCk9Kz4NbGHsEmmeBk7tmu/CCcBkYDKW8gQJfGdVbkctRmFeJ2d4uwz ssvykPCyOyqGOiU3wekjBWZ1Ncj8P8HXBWcOmbZLeSWl92k4VNlos3QUoQUhYrJERz6E dCNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=oxvyfpIYVsvKNGw3dY43IsIQw9gG1Ghxsu1Qxu6oGkc=; b=r36YJlukQyuAQExLoXD8zMwN/FPt8Mahm7+RdXYjgCrc74rqu5uJaGQyJMdru7n4e6 g01PvQKw3zADW+RJGc8zVxexbv59sePuWtHK6dOoS4G1KWYdzAL4KKNfO3SxEaYn15ZD xD3h5FnCGvkj2btl72WCOdNyLGRyOBCIGEb5s6F5PRQ7WwPBY+Q1iN/6ZGveFU12jRJS BuInWx8CusFo8NyJglAQlP7LlgZ4vpOKGHrZy+eAskaL7ww6Qd7UjQK8OZxBCY4Tk2DB bbz1K1kO1jB3jXt4d1svYM5P9ovfrXmzWclj01PDOfDNuvGj2mf2dqrEx45GCWdPUSgY FJMw== X-Gm-Message-State: AMCzsaWuoT8eDBp4yTVV8SFxx7ZNbSyyAZcN+qhUpAzn23shKFWU3R05 8qTybjV/wURZHFY857rfvIw= X-Google-Smtp-Source: AOwi7QDllFl4Jn4EVEIZ0cQr+OGLfpiMT3oaGgWJToLVJErI/lKuTVy4EpZLtAmcAq+OWz1eVGPGMg== X-Received: by 10.55.21.30 with SMTP id f30mr23097809qkh.335.1507063713412; Tue, 03 Oct 2017 13:48:33 -0700 (PDT) Received: from SantoshBrain (pool-173-73-191-59.washdc.fios.verizon.net. [173.73.191.59]) by smtp.gmail.com with ESMTPSA id 49sm9414815qtq.1.2017.10.03.13.48.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Oct 2017 13:48:32 -0700 (PDT) From: "Santosh Chokhani" To: "'Alexander Truskovsky'" , , , Cc: , , , , , , , References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> In-Reply-To: <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> Date: Tue, 3 Oct 2017 16:48:33 -0400 Message-ID: <079001d33c88$fab856c0$f0290440$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDus9F8NjCdvUGnLuU9orle20/kKgI84QjmAbyZK6EBM7nHTKRyPsZA Content-Language: en-us Archived-At: X-Mailman-Approved-At: Tue, 03 Oct 2017 16:43:20 -0700 Subject: Re: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 20:48:37 -0000 Multiple public keys as well as signatures can be accommodated using the = respective algorithm OIDs in Signature and SPKI fields. Have you considered that in place of using an extension. -----Original Message----- From: Alexander Truskovsky [mailto:Alexander.Truskovsky@isara.com]=20 Sent: Tuesday, October 3, 2017 4:38 PM To: santosh.chokhani@gmail.com; david.waltermire@nist.gov; = kivinen@iki.fi; housley@vigilsec.com Cc: spasm@ietf.org; ekr@rtfm.com; housley@vigilsec.com; = Scott.Mansfield@Ericsson.com; ipsec@ietf.org; = Kathleen.Moriarty.ietf@gmail.com; itu-t-liaison@iab.org; = jean-paul.lemaire@univ-paris-diderot.fr Subject: Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 = work on quantum-safe PKI" This allows X.509 certificates to contain two (or more) public keys and = issuer signatures. The goal would be to ease the migration of PKI and = dependent protocols to new digital signature algorithms. The motivation = was to make the X.509 more cryptographically agile and simplify the = migration to quantum-safe algorithms, but it is algorithm agnostic. The = main benefit of this proposal is that current systems will be able to = use these newer X.509 certificates as they do today without any = modifications, while systems that were updated to support quantum-safe = algorithms can also be updated to understand the newer X.509 format and = use quantum-safe algorithm instead. We are working on a draft that mirrors the ITU-T=E2=80=99s work with a = few partners and will publish it for review soon. Alex =20 =20 On 2017-10-02, 9:58 PM, "IPsec on behalf of Santosh Chokhani" = wrote: =20 I am not sure I understand what is being said below. The link = to the PDF does not add to the message body. =20 If there is a concern about what signature algorithm is used for = what type of subject key, X.509 already has that flexibility. =20 If there is a concern about using multiple signatures on an = X.509 certificate, one can use the single signature algorithm = identifier to define multiple algorithms, parameters, and signatures. =20 -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Liaison = Statement Management Tool Sent: Wednesday, September 13, 2017 11:25 AM To: David Waltermire ; Tero Kivinen ; Russ Housley Cc: Limited Additional Mechanisms for PKIX and SMIME Discussion = List ; Eric Rescorla ; Russ Housley ; Tero Kivinen ; Scott = Mansfield ; IP Security Maintenance and = Extensions Discussion List ; Kathleen Moriarty ; David Waltermire ; itu-t-liaison@iab.org; jean-paul.lemaire@univ-paris-diderot.fr Subject: [lamps] New Liaison Statement, "LS on ITU-T SG17 work = on quantum-safe PKI" =20 Title: LS on ITU-T SG17 work on quantum-safe PKI Submission = Date: 2017-09-13 URL of the IETF Web page: = https://datatracker.ietf.org/liaison/1541/ =20 From: Jean-Paul Lemaire = To: David Waltermire ,Tero Kivinen ,Russ Housley Cc: David Waltermire ,IP Security = Maintenance and Extensions Discussion List = ,itu-t-liaison@iab.org,Limited Additional Mechanisms for PKIX and SMIME Discussion List ,Russ Housley ,Scott = Mansfield ,Kathleen Moriarty ,Tero Kivinen = ,Eric Rescorla Response Contacts: jean-paul.lemaire@univ-paris-diderot.fr Technical Contacts:=20 Purpose: For information =20 Body: ITU-T Study Group 17 is pleased to inform you that in our August/September 2017 meeting we agreed to start work on the = inclusion of a proposal to include optional support for multiple public-key = algorithms in Recommendation ITU-T X509 | ISO/IEC 9594-8. =20 The industry is preparing ICT systems to be resistant to attacks = by large-scale quantum computers in addition to more sophisticated = attacks by conventional computing resources. Proposed was an optional = feature to the X.509 certificate that provides a seamless migration capability = to existing PKI systems, and is completely backwardly compatible with = existing systems. =20 While public-key key establishment algorithms are typically = negotiated between peers and are generally fairly simple to update, the = authentication systems typically rely on a single digital signature algorithm = which are more difficult to update. This is because of the circular = dependency between PKI-based identity systems and the dependent communication = protocols. In order to update a PKI system, one would typically need to create = a duplicate PKI system that utilizes a new digital signature algorithm and = then migrate all the dependent systems one by one. =20 This proposal eliminates the need to create such duplicate PKI = systems by adding optional extensions to contain alternate public key and = alternate signature, and a method for the CA to sign certificates using a = layered approach to ensure that every attribute is authenticated by both = signatures. The resulting certificate, while containing new quantum safe = public key and signature, can still be used by existing systems relying on the = classic public key and signature. Attachments: =20 sp16-sg17-oLS-00068 =20 = https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-09-13-itu-t-sg= -17 = -ipsecme-lamps-ls-on-itu-t-sg17-work-on-quantum-safe-pki-attachment-1.pdf= =20 _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 =20 From nobody Tue Oct 3 16:43:33 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523C013219B; Tue, 3 Oct 2017 14:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wl1ew-kmftw; Tue, 3 Oct 2017 14:35:12 -0700 (PDT) Received: from esa1.isaracorp.com (esa1.isaracorp.com [207.107.152.166]) by ietfa.amsl.com (Postfix) with ESMTP id DA7FA1331DC; Tue, 3 Oct 2017 14:35:11 -0700 (PDT) Received: from 172-1-110-12.lightspeed.sntcca.sbcglobal.net (HELO cas.isaracorp.com) ([172.1.110.12]) by ip1.isaracorp.com with ESMTP; 03 Oct 2017 21:40:49 +0000 Received: from mb.isaracorp.com (2002:ac01:6e0b::ac01:6e0b) by mb.isaracorp.com (2002:ac01:6e0b::ac01:6e0b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 3 Oct 2017 17:35:04 -0400 Received: from mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f]) by mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f%12]) with mapi id 15.00.1044.021; Tue, 3 Oct 2017 17:35:04 -0400 From: Alexander Truskovsky To: Santosh Chokhani , "david.waltermire@nist.gov" , "kivinen@iki.fi" , "housley@vigilsec.com" CC: "spasm@ietf.org" , "ekr@rtfm.com" , "Scott.Mansfield@Ericsson.com" , "ipsec@ietf.org" , "Kathleen.Moriarty.ietf@gmail.com" , "itu-t-liaison@iab.org" , "jean-paul.lemaire@univ-paris-diderot.fr" Thread-Topic: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" Thread-Index: AQHTO+sV5+bpPT0iyE2onk66kRVilaLSoMOAgAA5gICAAALogIAADP8A Date: Tue, 3 Oct 2017 21:35:04 +0000 Message-ID: <070920B4-ED3D-44F1-BC72-60FDB74D78EA@isara.com> References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> <079001d33c88$fab856c0$f0290440$@gmail.com> In-Reply-To: <079001d33c88$fab856c0$f0290440$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.25.5.208] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 03 Oct 2017 16:43:20 -0700 Subject: Re: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 21:35:15 -0000 VGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnQuDQoNCldlIHdhbnQgdG8gZW5zdXJlIHRoZSBleGlz dGluZyBzeXN0ZW1zIGNhbiB1c2UgdGhlc2UgbmV3ZXIgY2VydGlmaWNhdGVzIGFzIGlmIG5vdGhp bmcgY2hhbmdlZC4gIFRoYXTigJlzIHRoZSBrZXkgcmVxdWlyZW1lbnQuICBJZiB0aGUgU2lnbmF0 dXJlIGZpZWxkIGlzIG1vZGlmaWVkLCB0aGUgc3lzdGVtcyB0aGF0IGhhdmUgbm90IGJlZW4gdXBk YXRlZCB3aWxsIG5vdCBiZSBhYmxlIHRvIHVzZSBjbGFzc2ljIGFsZ29yaXRobXMgYXMgdGhleSBk byB0b2RheS4gIFBsYWNpbmcgc2lnbmF0dXJlcyBpbiB0aGUgbm9uLWNyaXRpY2FsIGV4dGVuc2lv bnMgbGVhdmVzIHRoZSBTaWduYXR1cmUgZmllbGQgdW50b3VjaGVkLg0KDQpBbGV4DQoNCk9uIDIw MTctMTAtMDMsIDQ6NDggUE0sICJTYW50b3NoIENob2toYW5pIiA8c2FudG9zaC5jaG9raGFuaUBn bWFpbC5jb20+IHdyb3RlOg0KDQogICAgTXVsdGlwbGUgcHVibGljIGtleXMgYXMgd2VsbCBhcyBz aWduYXR1cmVzIGNhbiBiZSBhY2NvbW1vZGF0ZWQgdXNpbmcgdGhlIHJlc3BlY3RpdmUgYWxnb3Jp dGhtIE9JRHMgaW4gU2lnbmF0dXJlIGFuZCBTUEtJIGZpZWxkcy4NCiAgICANCiAgICBIYXZlIHlv dSBjb25zaWRlcmVkIHRoYXQgaW4gcGxhY2Ugb2YgdXNpbmcgYW4gZXh0ZW5zaW9uLg0KICAgIA0K ICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTogQWxleGFuZGVyIFRydXNr b3Zza3kgW21haWx0bzpBbGV4YW5kZXIuVHJ1c2tvdnNreUBpc2FyYS5jb21dIA0KICAgIFNlbnQ6 IFR1ZXNkYXksIE9jdG9iZXIgMywgMjAxNyA0OjM4IFBNDQogICAgVG86IHNhbnRvc2guY2hva2hh bmlAZ21haWwuY29tOyBkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292OyBraXZpbmVuQGlraS5maTsg aG91c2xleUB2aWdpbHNlYy5jb20NCiAgICBDYzogc3Bhc21AaWV0Zi5vcmc7IGVrckBydGZtLmNv bTsgaG91c2xleUB2aWdpbHNlYy5jb207IFNjb3R0Lk1hbnNmaWVsZEBFcmljc3Nvbi5jb207IGlw c2VjQGlldGYub3JnOyBLYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTsgaXR1LXQtbGlh aXNvbkBpYWIub3JnOyBqZWFuLXBhdWwubGVtYWlyZUB1bml2LXBhcmlzLWRpZGVyb3QuZnINCiAg ICBTdWJqZWN0OiBSZTogW0lQc2VjXSBbbGFtcHNdIE5ldyBMaWFpc29uIFN0YXRlbWVudCwgIkxT IG9uIElUVS1UIFNHMTcgd29yayBvbiBxdWFudHVtLXNhZmUgUEtJIg0KICAgIA0KICAgIFRoaXMg YWxsb3dzIFguNTA5IGNlcnRpZmljYXRlcyB0byBjb250YWluIHR3byAob3IgbW9yZSkgcHVibGlj IGtleXMgYW5kIGlzc3VlciBzaWduYXR1cmVzLiAgVGhlIGdvYWwgd291bGQgYmUgdG8gZWFzZSB0 aGUgbWlncmF0aW9uIG9mIFBLSSBhbmQgZGVwZW5kZW50IHByb3RvY29scyB0byBuZXcgZGlnaXRh bCBzaWduYXR1cmUgYWxnb3JpdGhtcy4gIFRoZSBtb3RpdmF0aW9uIHdhcyB0byBtYWtlIHRoZSBY LjUwOSBtb3JlIGNyeXB0b2dyYXBoaWNhbGx5IGFnaWxlIGFuZCBzaW1wbGlmeSB0aGUgbWlncmF0 aW9uIHRvIHF1YW50dW0tc2FmZSBhbGdvcml0aG1zLCBidXQgaXQgaXMgYWxnb3JpdGhtIGFnbm9z dGljLiAgVGhlIG1haW4gYmVuZWZpdCBvZiB0aGlzIHByb3Bvc2FsIGlzIHRoYXQgY3VycmVudCBz eXN0ZW1zIHdpbGwgYmUgYWJsZSB0byB1c2UgdGhlc2UgbmV3ZXIgWC41MDkgY2VydGlmaWNhdGVz IGFzIHRoZXkgZG8gdG9kYXkgd2l0aG91dCBhbnkgbW9kaWZpY2F0aW9ucywgd2hpbGUgc3lzdGVt cyB0aGF0IHdlcmUgdXBkYXRlZCB0byBzdXBwb3J0IHF1YW50dW0tc2FmZSBhbGdvcml0aG1zIGNh biBhbHNvIGJlIHVwZGF0ZWQgdG8gdW5kZXJzdGFuZCB0aGUgbmV3ZXIgWC41MDkgZm9ybWF0IGFu ZCB1c2UgcXVhbnR1bS1zYWZlIGFsZ29yaXRobSBpbnN0ZWFkLg0KICAgIA0KICAgIFdlIGFyZSB3 b3JraW5nIG9uIGEgZHJhZnQgdGhhdCBtaXJyb3JzIHRoZSBJVFUtVOKAmXMgd29yayB3aXRoIGEg ZmV3IHBhcnRuZXJzIGFuZCB3aWxsIHB1Ymxpc2ggaXQgZm9yIHJldmlldyBzb29uLg0KICAgIA0K ICAgIEFsZXgNCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICBPbiAyMDE3LTEwLTAyLCA5OjU4 IFBNLCAiSVBzZWMgb24gYmVoYWxmIG9mIFNhbnRvc2ggQ2hva2hhbmkiIDxpcHNlYy1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBzYW50b3NoLmNob2toYW5pQGdtYWlsLmNvbT4gd3JvdGU6 DQogICAgICAgIA0KICAgICAgICAgICAgSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hhdCBp cyBiZWluZyBzYWlkIGJlbG93LiAgVGhlIGxpbmsgdG8gdGhlIFBERg0KICAgICAgICAgICAgZG9l cyBub3QgYWRkIHRvIHRoZSBtZXNzYWdlIGJvZHkuDQogICAgICAgICAgICANCiAgICAgICAgICAg IElmIHRoZXJlIGlzIGEgY29uY2VybiBhYm91dCB3aGF0IHNpZ25hdHVyZSBhbGdvcml0aG0gaXMg dXNlZCBmb3Igd2hhdCB0eXBlDQogICAgICAgICAgICBvZiBzdWJqZWN0IGtleSwgWC41MDkgYWxy ZWFkeSBoYXMgdGhhdCBmbGV4aWJpbGl0eS4NCiAgICAgICAgICAgIA0KICAgICAgICAgICAgSWYg dGhlcmUgaXMgYSBjb25jZXJuIGFib3V0IHVzaW5nIG11bHRpcGxlIHNpZ25hdHVyZXMgb24gYW4g WC41MDkNCiAgICAgICAgICAgIGNlcnRpZmljYXRlLCBvbmUgY2FuIHVzZSB0aGUgc2luZ2xlIHNp Z25hdHVyZSBhbGdvcml0aG0gaWRlbnRpZmllciB0byBkZWZpbmUNCiAgICAgICAgICAgIG11bHRp cGxlIGFsZ29yaXRobXMsIHBhcmFtZXRlcnMsIGFuZCBzaWduYXR1cmVzLg0KICAgICAgICAgICAg DQogICAgICAgICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgICAgICAgICAgRnJv bTogU3Bhc20gW21haWx0bzpzcGFzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGlh aXNvbiBTdGF0ZW1lbnQNCiAgICAgICAgICAgIE1hbmFnZW1lbnQgVG9vbA0KICAgICAgICAgICAg U2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTcgMTE6MjUgQU0NCiAgICAgICAgICAg IFRvOiBEYXZpZCBXYWx0ZXJtaXJlIDxkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292PjsgVGVybyBL aXZpbmVuDQogICAgICAgICAgICA8a2l2aW5lbkBpa2kuZmk+OyBSdXNzIEhvdXNsZXkgPGhvdXNs ZXlAdmlnaWxzZWMuY29tPg0KICAgICAgICAgICAgQ2M6IExpbWl0ZWQgQWRkaXRpb25hbCBNZWNo YW5pc21zIGZvciBQS0lYIGFuZCBTTUlNRSBEaXNjdXNzaW9uIExpc3QNCiAgICAgICAgICAgIDxz cGFzbUBpZXRmLm9yZz47IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT47IFJ1c3MgSG91c2xl eQ0KICAgICAgICAgICAgPGhvdXNsZXlAdmlnaWxzZWMuY29tPjsgVGVybyBLaXZpbmVuIDxraXZp bmVuQGlraS5maT47IFNjb3R0IE1hbnNmaWVsZA0KICAgICAgICAgICAgPFNjb3R0Lk1hbnNmaWVs ZEBFcmljc3Nvbi5jb20+OyBJUCBTZWN1cml0eSBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9ucw0K ICAgICAgICAgICAgRGlzY3Vzc2lvbiBMaXN0IDxpcHNlY0BpZXRmLm9yZz47IEthdGhsZWVuIE1v cmlhcnR5DQogICAgICAgICAgICA8S2F0aGxlZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+OyBE YXZpZCBXYWx0ZXJtaXJlDQogICAgICAgICAgICA8ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdj47 IGl0dS10LWxpYWlzb25AaWFiLm9yZzsNCiAgICAgICAgICAgIGplYW4tcGF1bC5sZW1haXJlQHVu aXYtcGFyaXMtZGlkZXJvdC5mcg0KICAgICAgICAgICAgU3ViamVjdDogW2xhbXBzXSBOZXcgTGlh aXNvbiBTdGF0ZW1lbnQsICJMUyBvbiBJVFUtVCBTRzE3IHdvcmsgb24NCiAgICAgICAgICAgIHF1 YW50dW0tc2FmZSBQS0kiDQogICAgICAgICAgICANCiAgICAgICAgICAgIFRpdGxlOiBMUyBvbiBJ VFUtVCBTRzE3IHdvcmsgb24gcXVhbnR1bS1zYWZlIFBLSSBTdWJtaXNzaW9uIERhdGU6IDIwMTct MDktMTMNCiAgICAgICAgICAgIFVSTCBvZiB0aGUgSUVURiBXZWIgcGFnZTogaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzE1NDEvDQogICAgICAgICAgICANCiAgICAgICAgICAg IEZyb206IEplYW4tUGF1bCBMZW1haXJlIDxqZWFuLXBhdWwubGVtYWlyZUB1bml2LXBhcmlzLWRp ZGVyb3QuZnI+DQogICAgICAgICAgICBUbzogRGF2aWQgV2FsdGVybWlyZSA8ZGF2aWQud2FsdGVy bWlyZUBuaXN0Lmdvdj4sVGVybyBLaXZpbmVuDQogICAgICAgICAgICA8a2l2aW5lbkBpa2kuZmk+ LFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+DQogICAgICAgICAgICBDYzogRGF2 aWQgV2FsdGVybWlyZSA8ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdj4sSVAgU2VjdXJpdHkgTWFp bnRlbmFuY2UgYW5kDQogICAgICAgICAgICBFeHRlbnNpb25zIERpc2N1c3Npb24gTGlzdCA8aXBz ZWNAaWV0Zi5vcmc+LGl0dS10LWxpYWlzb25AaWFiLm9yZyxMaW1pdGVkDQogICAgICAgICAgICBB ZGRpdGlvbmFsIE1lY2hhbmlzbXMgZm9yIFBLSVggYW5kIFNNSU1FIERpc2N1c3Npb24gTGlzdA0K ICAgICAgICAgICAgPHNwYXNtQGlldGYub3JnPixSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxz ZWMuY29tPixTY290dCBNYW5zZmllbGQNCiAgICAgICAgICAgIDxTY290dC5NYW5zZmllbGRARXJp Y3Nzb24uY29tPixLYXRobGVlbiBNb3JpYXJ0eQ0KICAgICAgICAgICAgPEthdGhsZWVuLk1vcmlh cnR5LmlldGZAZ21haWwuY29tPixUZXJvIEtpdmluZW4gPGtpdmluZW5AaWtpLmZpPixFcmljDQog ICAgICAgICAgICBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPiBSZXNwb25zZSBDb250YWN0czoNCiAg ICAgICAgICAgIGplYW4tcGF1bC5sZW1haXJlQHVuaXYtcGFyaXMtZGlkZXJvdC5mcg0KICAgICAg ICAgICAgVGVjaG5pY2FsIENvbnRhY3RzOiANCiAgICAgICAgICAgIFB1cnBvc2U6IEZvciBpbmZv cm1hdGlvbg0KICAgICAgICAgICAgDQogICAgICAgICAgICBCb2R5OiBJVFUtVCBTdHVkeSBHcm91 cCAxNyBpcyBwbGVhc2VkIHRvIGluZm9ybSB5b3UgdGhhdCBpbiBvdXINCiAgICAgICAgICAgIEF1 Z3VzdC9TZXB0ZW1iZXIgMjAxNyBtZWV0aW5nIHdlIGFncmVlZCB0byBzdGFydCB3b3JrIG9uIHRo ZSBpbmNsdXNpb24gb2YgYQ0KICAgICAgICAgICAgcHJvcG9zYWwgdG8gaW5jbHVkZSBvcHRpb25h bCBzdXBwb3J0IGZvciBtdWx0aXBsZSBwdWJsaWMta2V5IGFsZ29yaXRobXMgaW4NCiAgICAgICAg ICAgIFJlY29tbWVuZGF0aW9uIElUVS1UIFg1MDkgfCBJU08vSUVDIDk1OTQtOC4NCiAgICAgICAg ICAgIA0KICAgICAgICAgICAgVGhlIGluZHVzdHJ5IGlzIHByZXBhcmluZyBJQ1Qgc3lzdGVtcyB0 byBiZSByZXNpc3RhbnQgdG8gYXR0YWNrcyBieQ0KICAgICAgICAgICAgbGFyZ2Utc2NhbGUgcXVh bnR1bSBjb21wdXRlcnMgaW4gYWRkaXRpb24gdG8gbW9yZSBzb3BoaXN0aWNhdGVkIGF0dGFja3Mg YnkNCiAgICAgICAgICAgIGNvbnZlbnRpb25hbCBjb21wdXRpbmcgcmVzb3VyY2VzLiBQcm9wb3Nl ZCB3YXMgYW4gb3B0aW9uYWwgZmVhdHVyZSB0byB0aGUNCiAgICAgICAgICAgIFguNTA5IGNlcnRp ZmljYXRlIHRoYXQgcHJvdmlkZXMgYSBzZWFtbGVzcyBtaWdyYXRpb24gY2FwYWJpbGl0eSB0byBl eGlzdGluZw0KICAgICAgICAgICAgUEtJIHN5c3RlbXMsIGFuZCBpcyBjb21wbGV0ZWx5IGJhY2t3 YXJkbHkgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIHN5c3RlbXMuDQogICAgICAgICAgICANCiAg ICAgICAgICAgIFdoaWxlIHB1YmxpYy1rZXkga2V5IGVzdGFibGlzaG1lbnQgYWxnb3JpdGhtcyBh cmUgdHlwaWNhbGx5IG5lZ290aWF0ZWQNCiAgICAgICAgICAgIGJldHdlZW4gcGVlcnMgYW5kIGFy ZSBnZW5lcmFsbHkgZmFpcmx5IHNpbXBsZSB0byB1cGRhdGUsIHRoZSBhdXRoZW50aWNhdGlvbg0K ICAgICAgICAgICAgc3lzdGVtcyB0eXBpY2FsbHkgcmVseSBvbiBhIHNpbmdsZSBkaWdpdGFsIHNp Z25hdHVyZSBhbGdvcml0aG0gd2hpY2ggYXJlDQogICAgICAgICAgICBtb3JlIGRpZmZpY3VsdCB0 byB1cGRhdGUuIFRoaXMgaXMgYmVjYXVzZSBvZiB0aGUgY2lyY3VsYXIgZGVwZW5kZW5jeSBiZXR3 ZWVuDQogICAgICAgICAgICBQS0ktYmFzZWQgaWRlbnRpdHkgc3lzdGVtcyBhbmQgdGhlIGRlcGVu ZGVudCBjb21tdW5pY2F0aW9uIHByb3RvY29scy4gSW4NCiAgICAgICAgICAgIG9yZGVyIHRvIHVw ZGF0ZSBhIFBLSSBzeXN0ZW0sIG9uZSB3b3VsZCB0eXBpY2FsbHkgbmVlZCB0byBjcmVhdGUgYSBk dXBsaWNhdGUNCiAgICAgICAgICAgIFBLSSBzeXN0ZW0gdGhhdCB1dGlsaXplcyBhIG5ldyBkaWdp dGFsIHNpZ25hdHVyZSBhbGdvcml0aG0gYW5kIHRoZW4gbWlncmF0ZQ0KICAgICAgICAgICAgYWxs IHRoZSBkZXBlbmRlbnQgc3lzdGVtcyBvbmUgYnkgb25lLg0KICAgICAgICAgICAgDQogICAgICAg ICAgICBUaGlzIHByb3Bvc2FsIGVsaW1pbmF0ZXMgdGhlIG5lZWQgdG8gY3JlYXRlIHN1Y2ggZHVw bGljYXRlIFBLSSBzeXN0ZW1zIGJ5DQogICAgICAgICAgICBhZGRpbmcgb3B0aW9uYWwgZXh0ZW5z aW9ucyB0byBjb250YWluIGFsdGVybmF0ZSBwdWJsaWMga2V5IGFuZCBhbHRlcm5hdGUNCiAgICAg ICAgICAgIHNpZ25hdHVyZSwgYW5kIGEgbWV0aG9kIGZvciB0aGUgQ0EgdG8gc2lnbiBjZXJ0aWZp Y2F0ZXMgdXNpbmcgYSBsYXllcmVkDQogICAgICAgICAgICBhcHByb2FjaCB0byBlbnN1cmUgdGhh dCBldmVyeSBhdHRyaWJ1dGUgaXMgYXV0aGVudGljYXRlZCBieSBib3RoIHNpZ25hdHVyZXMuDQog ICAgICAgICAgICBUaGUgcmVzdWx0aW5nIGNlcnRpZmljYXRlLCB3aGlsZSBjb250YWluaW5nIG5l dyBxdWFudHVtIHNhZmUgcHVibGljIGtleSBhbmQNCiAgICAgICAgICAgIHNpZ25hdHVyZSwgY2Fu IHN0aWxsIGJlIHVzZWQgYnkgZXhpc3Rpbmcgc3lzdGVtcyByZWx5aW5nIG9uIHRoZSBjbGFzc2lj DQogICAgICAgICAgICBwdWJsaWMga2V5IGFuZCBzaWduYXR1cmUuDQogICAgICAgICAgICBBdHRh Y2htZW50czoNCiAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgIHNwMTYtc2cxNy1vTFMtMDAw NjgNCiAgICAgICAgICAgICANCiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2xpYi9k dC9kb2N1bWVudHMvTElBSVNPTi9saWFpc29uLTIwMTctMDktMTMtaXR1LXQtc2ctMTcNCiAgICAg ICAgICAgIC1pcHNlY21lLWxhbXBzLWxzLW9uLWl0dS10LXNnMTctd29yay1vbi1xdWFudHVtLXNh ZmUtcGtpLWF0dGFjaG1lbnQtMS5wZGYNCiAgICAgICAgICAgIA0KICAgICAgICAgICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgICAgIFNw YXNtIG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgU3Bhc21AaWV0Zi5vcmcNCiAgICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Bhc20NCiAgICAgICAgICAg IA0KICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICAgICAgICAgIElQc2VjIG1haWxpbmcgbGlzdA0KICAgICAgICAgICAgSVBzZWNA aWV0Zi5vcmcNCiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXBzZWMNCiAgICAgICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgDQogICAgDQog ICAgDQoNCg== From nobody Wed Oct 4 07:15:44 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB81132332 for ; Wed, 4 Oct 2017 07:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 (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 mROfYKI-ZMCL for ; Wed, 4 Oct 2017 07:15:35 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 4EF561326DF for ; Wed, 4 Oct 2017 07:15:32 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id u130so19751599oib.11 for ; Wed, 04 Oct 2017 07:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=YlK5RMipdznos3IzVHbo8rOG2CPESNuGd4oldPz+iKg=; b=CSxI0gS0Aa8U4lA7JsOPFXC2O28dcB2m6u5D1npDX287xEJM2D/rJinp7fh318y5hE ubOVXQkQVMPFrx8Y9zuNHVyTZ3/QwMUb/9bk6YFL6XCSvN7Sy0E07FiNRTTW6kh0ZDNa RpJy1aRBvF013VmcbVEcFWoMcfKyKAbkBNEH5cWDi/ScLu26M5/TQDA+MRpTa22Fs0e4 KW8cLti5arNlu8e8zYM5ZvQfRF2zxaYyNAB9XL0HbUyrSEvITGltct2g5t1rW2moHi6I FzttdhxAMtTNgg2BySaOYFgjCLWxshp8ttIYTsLtTLtQx1d0lpdQ0EjTIob4faFTQNHJ 8AmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=YlK5RMipdznos3IzVHbo8rOG2CPESNuGd4oldPz+iKg=; b=ELdehk4hAYd5uC4b/Ki8J2Jv349hFaKbNNNdeajP70a7FjkDvmEdwz5jnnrWDsYf8B oGhwz8XcrzLBQOu8oEF43xVrveq1hfCo18tEWHFqTGA2iYxTmHkw2smE9YRDAd/K/eYq oL6TDP+T0jZEn9SlIRYuhGU2ENpJTS46omdLJcPLTAidYLW99Mx3KIl8TepRM3TgisdV zmKi8pBwQjaUbEnRoZ4ynXZ9XmghBx2tXz0jAyGjMkDIZ65K54JhYDcajyRp4VF3VTli 9dNTBog57cLWCacVP6xFbWZmp8inp/EqJIYWFDFY7zTHNasNa5PrxTuMKsON3g4pxazI eqEw== X-Gm-Message-State: AMCzsaUhL9PpMGBxTyb0tolGOl/ti0hjqIMxzDww6kZQuqpNu6M2n1Ev fzHTh6/DxoJ3D/0X/Ntps2mwOyBjMpLcZ+tgdqMfLA== X-Google-Smtp-Source: AOwi7QC2X0IveRdyCseoxAITZEdoZ1luHKQA9EwT5z/UHbCGrMBgY/gQvgA4KziK6uep2WT1rYUVJLYDjzaTq8Ruuz8= X-Received: by 10.157.17.72 with SMTP id p8mr3848102otp.269.1507126531104; Wed, 04 Oct 2017 07:15:31 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.95.12 with HTTP; Wed, 4 Oct 2017 07:15:30 -0700 (PDT) From: Phillip Hallam-Baker Date: Wed, 4 Oct 2017 10:15:30 -0400 X-Google-Sender-Auth: FjmCMlYo24_011tjCwdTYJkp3oE Message-ID: To: SPASM Content-Type: multipart/alternative; boundary="001a113e243c86d091055ab93d09" Archived-At: Subject: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 14:15:42 -0000 --001a113e243c86d091055ab93d09 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Before writing any text, I would like us to decide what the text should say. There is no point in wordsmithing until we know what we want to say. =E2=80=8BThere is a lot of traffic on the CABForum mailing lists with peopl= e raising deployment issues. I see the following, which may not be exhaustive= . * Issues to do with DNAME implementation. * Issues to do with DNSSEC interactions. * Issues to do with when a CA must perform a retry.=E2=80=8B Looking at these, I think we need to consider two separate changes to the document 1. A fix to the specification part describing the new discovery algorithm 2. An appendix that sets out worked examples for the following * Site publishes CAA records without DNSSEC * Site publishes CAA record with DNSSEC These need to expose all the relevant logic paths: * CNAME * DNAME * lookup fails * DNSSEC fails * loops * any more ? We are in an unusual situation for IETF as we are defining a document which will be used for compliance purposes. This is not unique but I can't recall an example where I was working on a document which I knew would be used for compliance by a specific group. On the design decisions side, I can only see one actual decision point. There are many points where the issue is what do the DNS specs say, but the only part where I can see us having a choice is on whether to support recursive tree climbing on a prefixed name. Consider the case that www.example.net is CNAME to www.example.com. This may be because 1) The name www.example.net is owned by the same party as www.example.com and wants the two to be precisely equivalent. 2) www.example.com is a CDN that is hosting www.example.net. The DNS does not provide the ability to distinguish between the two. The only information in the DNS describes WHAT and to distinguish them, we need WHY. The reason we would want to distinguish is if there is a CAA record at example.net. 1) The CNAME is there to make the names equivalent so the CAA record at example.net should aply 2) The CNAME is only there to make the CDN work and the CAA record at example.net should be ignored. These issues were discussed when CAA was originally proposed but CDNs were somewhat niche at the time and so we decided on the first approach. By the time CABForum mandated implementation, CDNs were on their way to being ubiquitous and hence the errata changing this to the second. One of the issues that makes this problematic is that the DNS spec says that a node that has a CNAME entry MUST NOT have any other records. So it is not legal to simply tell people to put a CAA record next to the CNAME record. At the Chicago IETF, someone proposed we use prefixed records to get around the limitation. This seems the best approach to me. There are a few ways that we could do this but the simplest one as far as I am concerned is * Ignore ALL CNAME records in CAA discovery entirely * Search for CAA records at www.example.com and _prefix.example.com The obvious choice for the prefix is _caa but my gut tells me that what we are defining here is rather more general and the prefix should be generic as well. _attr perhaps. One issue with the simplest approach is that we have legacy deployment and even though we can tell CAs to change what they will do and expect them to respond within 6 months, this is not the case for sites. It seems to me that we have three choices A) Stick with CNAME as currently defined in the errata B) Use the simple approach C) CAs process using the simple approach first, ignoring CNAMEs until the root domain is reached and then process CNAMEs. So to illustrate, consider the following www.example.net CNAME -> www.example.com The checking for CAA records is as follows: A) www.example.net, www.example.com, example.net, .net B) www.example.net, _prefix.www.example.net, example.net, _ prefix.example.net, .net, _prefix.net C) www.example.net, _prefix.www.example.net, example.net, _ prefix.example.net, .net, _prefix.net, www.example.com --001a113e243c86d091055ab93d09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bef= ore writing any text, I would like us to decide what the text should say. T= here is no point in wordsmithing until we know what we want to say.


=E2=80=8BThere is a lot of traffic on th= e CABForum mailing lists with people raising deployment issues. I see the f= ollowing, which may not be exhaustive.

* Issues to do with DNAME implementation.

* Issues to do with DNSSEC interactions.

* Issues to do with when a C= A must perform a retry.=E2=80=8B


Lo= oking at these, I think we need to consider two separate changes to the doc= ument

1. A fix to the spe= cification part describing the new discovery algorithm

2. An appendix that sets out worked examples = for the following

* Site = publishes CAA records without DNSSEC

* Site publishes CAA record with DNSSEC

These need to expose all the relevant logic path= s:

* CNAME
* DNAME
* lookup fails
* DNSSEC fails
* loops
* any more ?


We are in an unusual situation for IETF as we are defining a doc= ument which will be used for compliance purposes. This is not unique but I = can't recall an example where I was working on a document which I knew = would be used for compliance by a specific group.


On the design decisions side, I can only see one actual deci= sion point. There are many points where the issue is what do the DNS specs = say, but the only part where I can see us having a choice is on whether to = support recursive tree climbing on a prefixed name.

Consider the case that www.example.net is CNAME to www.example.com. This may be because

1) The name www.exampl= e.net is owned by the same party as = www.example.com and wants the two to be precisely equivalent.

2) www.example.com is a CDN that is hosting www.example.net.

The DNS does not provide the ability to distinguish between the two. T= he only information in the DNS describes WHAT and to distinguish them, we n= eed WHY.

The reason we wo= uld want to distinguish is if there is a CAA record at example.net.=C2=A0

1) The CNAME is there to make the names equivalent so the CAA re= cord at example.net should aply

2) The CNAME is only there to mak= e the CDN work and the CAA record at example= .net should be ignored.


These i= ssues were discussed when CAA was originally proposed but CDNs were somewha= t niche at the time and so we decided on the first approach. By the time CA= BForum mandated implementation, CDNs were on their way to being ubiquitous = and hence the errata changing this to the second.

One of the issues that makes this problematic is t= hat the DNS spec says that a node that has a CNAME entry MUST NOT have any = other records. So it is not legal to simply tell people to put a CAA record= next to the CNAME record.

At the Chicago IETF, someone proposed we use prefixed records to get arou= nd the limitation. This seems the best approach to me. There are a few ways= that we could do this but the simplest one as far as I am concerned is

* Ignore ALL CNAME records i= n CAA discovery entirely

= * Search for CAA records at www.example.= com and _prefix.example.com

The obvious choice for the= prefix is _caa but my gut tells me that what we are defining here is rathe= r more general and the prefix should be generic as well. _attr perhaps.


One issue with the simplest approach i= s that we have legacy deployment and even though we can tell CAs to change = what they will do and expect them to respond within 6 months, this is not t= he case for sites.

It see= ms to me that we have three choices

A) Stick with CNAME as currently defined in the errata

B) Use the simple approach

C) CAs process using the simpl= e approach first, ignoring CNAMEs until the root domain is reached and then= process CNAMEs.

So to il= lustrate, consider the following

www.example.net CNAME -> = www.example.com


The checking for CAA records is as follows:
<= div class=3D"gmail_default" style=3D"font-size:small">
A) www.example.net, www.example= .com, example.net, .net

B) www.example.net, _prefix.www= .example.net, example.net, _prefix.example.net, .net, _prefix.net

C) www.example.net, _prefix.www.example.net, example.net, _= prefix.example.net,=C2=A0.net, _prefix.ne= t, www.example.com










--001a113e243c86d091055ab93d09-- From nobody Wed Oct 4 11:04:02 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B64134317 for ; Wed, 4 Oct 2017 11:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=eff.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 yh3_9s-8SWRH for ; Wed, 4 Oct 2017 11:03:58 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00F2133245 for ; Wed, 4 Oct 2017 11:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=VVnnuW6fVwBirFuLvYRKsO1RYd44FFEtNtu+eLgeCj4=; b=P8sKzaC9VXco/iIiX0z88F34lBqTF8FWNssexnWBGHfX93ZuwBYF/TejbonQ49/Tgnygg13/hm/UzaTzHm9QdhvJY85v3j/OfIZqTwt6gmVJ9kPNKBK5hzJmEziLipoLQFCUPdyZkezEgyMQAT2YsgCgsr+ZIyC5f+QR07+nTtw=; Received: ; Wed, 04 Oct 2017 11:03:55 -0700 To: spasm@ietf.org References: From: Jacob Hoffman-Andrews Message-ID: <358e44b4-5b50-03bd-9d6f-d0b5575a0833@eff.org> Date: Wed, 4 Oct 2017 11:03:57 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: skipped for local relay Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 18:04:00 -0000 On 10/04/2017 07:15 AM, Phillip Hallam-Baker wrote: > Before writing any text, I would like us to decide what the text should > say. There is no point in wordsmithing until we know what we want to say. I've published an individual draft on it, and gotten some feedback: https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-01.txt. I'm fairly sure the revised algorithm there, which is equivalent to erratum 5065 plus some clarification about DNAMEs, is what we want to say. I'd like to start our wordsmithing on that basis, since we've already done some discussion. > 1. A fix to the specification part describing the new discovery algorithm Yep, +1. > 2. An appendix that sets out worked examples for the following > > * Site publishes CAA records without DNSSEC > * Site publishes CAA record with DNSSEC There have been problems with CAA processing on DNSSEC-signed domains, but they are not typically due to incorrect publishing of CAA records. They are implementation problems in authoritative resolvers, typically when the resolver incorrectly signs an empty response. In other words, the problems crop up when DNSSEC is present, but no CAA records are present. Examples of signed records wouldn't help here, but describing the class of DNSSEC implementation errors that are commonly surfaced by CAA lookups would. I'm happy to produce a paragraph to that effect. > On the design decisions side, I can only see one actual decision point. > There are many points where the issue is what do the DNS specs say, but > the only part where I can see us having a choice is on whether to > support recursive tree climbing on a prefixed name. IETF makes decisions based on "rough consensus and running code." Erratum 5065-style CAA is the epitome of running code; all publicly trusted CAs are required to implement it. We should formalize that into an RFC before we consider new, incompatible alternatives. > These issues were discussed when CAA was originally proposed I went back and reviewed *all* the discussion on the PKIX mailing list from when CAA was first proposed: https://mailarchive.ietf.org/arch/search/?email_list=pkix&q=caa. Between draft 11 and draft 12 we went from no tree climbing at all, to tree climbing on the issuance domain, plus tree climbing on all aliases: https://tools.ietf.org/html/draft-ietf-pkix-caa-11#section-3 https://tools.ietf.org/html/draft-ietf-pkix-caa-12#section-4 The discussion at the time was between querying only the leaf node, vs leaf node + delegation point, vs tree climbing on the issuance domain. There was no constituency asking for tree climbing on the issuance domain *plus* tree climbing on the aliases. When tree climbing was drafted, the example text stood as it stands today; describing erratum 5065-style processing, in contradiction to the formal algorithm drafted at the same time. It seems like the spirit of the room was to only do tree climbing on the issuance domain. Tree climbing on CNAMEs was introduced as a byproduct of trying to re-specify CNAME processing instead of relying on RFC 1034's definition of CNAME processing. I think https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-01.txt is the ideal approach, and solves immediate problems we have without introducing new complexity. From nobody Wed Oct 4 14:58:53 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630321323B4 for ; Wed, 4 Oct 2017 14:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=eff.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 D_yusDeb5gFm for ; Wed, 4 Oct 2017 14:58:49 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712CF1344D8 for ; Wed, 4 Oct 2017 14:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=U2NDYmcgpSA/B9FQf8w2OAz2AuLUFE934ua7umquh7s=; b=YrL1JT9EgHPMwh6l6GLVR5zzvhcrHyYztfNVzF5bPYH9heXQ8lkN6lDtt565cAk+nuCj0DtZten/UMw1PFCzad75yezTeoeWhkI+v1sy+eGhsNvf2+7s/zNYAnIqwmH+yoWLi+M+ikFsAPeqRfayFUFk7sYPLXwHdJu6F7Vj73Y=; Received: ; Wed, 04 Oct 2017 14:58:46 -0700 To: SPASM From: Jacob Hoffman-Andrews Message-ID: <88d3d10b-5634-60a8-f4e6-26c03445dd91@eff.org> Date: Wed, 4 Oct 2017 14:58:49 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: [lamps] caa-simplification draft 02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 21:58:51 -0000 I've added a deployment considerations section documenting issues that CAs have seen with middleboxes and invalid live-signed DNSSEC responses. I've also tidied up the indentation and fixed the line-wrapping issue that Kazunori Fujiwara pointed out. https://www.ietf.org/id/draft-hoffman-andrews-caa-simplification-02.txt View the changes at: https://github.com/jsha/caa-simplification/commit/87e22b3d00bb038da77030b3d09461861e2b8046?w=1 From nobody Wed Oct 4 15:14:43 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92AE132F3F for ; Wed, 4 Oct 2017 15:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 5yFxr0-F6IF9 for ; Wed, 4 Oct 2017 15:14:39 -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 369AD1320D8 for ; Wed, 4 Oct 2017 15:14:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 928F73005AD for ; Wed, 4 Oct 2017 18:14:38 -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 K6yXUqI5Kp0I for ; Wed, 4 Oct 2017 18:14:37 -0400 (EDT) Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BE18F3002AD; Wed, 4 Oct 2017 18:14:36 -0400 (EDT) From: Russ Housley Message-Id: <4FDC1A25-9CC4-4E79-B46B-93BFD36E01DA@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C8BE117E-F7F2-4335-A27B-18A52B2E485F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 4 Oct 2017 18:14:35 -0400 In-Reply-To: Cc: SPASM To: Phillip Hallam-Baker References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 22:14:41 -0000 --Apple-Mail=_C8BE117E-F7F2-4335-A27B-18A52B2E485F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 4, 2017, at 10:15 AM, Phillip Hallam-Baker = wrote: >=20 > Consider the case that www.example.net is = CNAME to www.example.com . This may be because >=20 > 1) The name www.example.net is owned by the = same party as www.example.com and wants the = two to be precisely equivalent. >=20 > 2) www.example.com is a CDN that is hosting = www.example.net . >=20 > The DNS does not provide the ability to distinguish between the two. = The only information in the DNS describes WHAT and to distinguish them, = we need WHY. >=20 > The reason we would want to distinguish is if there is a CAA record at = example.net .=20 >=20 > 1) The CNAME is there to make the names equivalent so the CAA record = at example.net should aply >=20 > 2) The CNAME is only there to make the CDN work and the CAA record at = example.net should be ignored. If one looks in the DNS for www.ietf.org, one will see: www.ietf.org. 607 IN CNAME = www.ietf.org.cdn.cloudflare.net. I'm not sure how you would expect to distinguish the two cases. Russ --Apple-Mail=_C8BE117E-F7F2-4335-A27B-18A52B2E485F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 4, 2017, at 10:15 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

Consider the case that www.example.net is CNAME to www.example.com. This = may be because

1) The name www.example.net is owned by the same party = as www.example.com and wants the two to be = precisely equivalent.

2) www.example.com is a CDN that is = hosting www.example.net.

The DNS does not provide the ability to distinguish between the = two. The only information in the DNS describes WHAT and to distinguish = them, we need WHY.

The reason we would = want to distinguish is if there is a CAA record at example.net. 

1) = The CNAME is there to make the names equivalent so the CAA record = at example.net should aply

2) = The CNAME is only there to make the CDN work and the CAA record at example.net should be = ignored.

If = one looks in the DNS for www.ietf.org, one will see:

www.ietf.org. = 607 = IN = CNAME = www.ietf.org.cdn.cloudflare.net.

I'm not sure how you = would expect to distinguish the two cases.

Russ

= --Apple-Mail=_C8BE117E-F7F2-4335-A27B-18A52B2E485F-- From nobody Wed Oct 4 15:44:15 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E797A120724 for ; Wed, 4 Oct 2017 15:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 HK4eac0pJ6zR for ; Wed, 4 Oct 2017 15:44:13 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 4E9C91331DC for ; Wed, 4 Oct 2017 15:44:13 -0700 (PDT) Received: (qmail 79729 invoked from network); 4 Oct 2017 22:44:11 -0000 Received: from unknown (64.57.183.53) by gal.iecc.com with QMQP; 4 Oct 2017 22:44:11 -0000 Date: 4 Oct 2017 22:43:49 -0000 Message-ID: <20171004224349.3094.qmail@ary.lan> From: "John Levine" To: spasm@ietf.org Cc: housley@vigilsec.com In-Reply-To: <4FDC1A25-9CC4-4E79-B46B-93BFD36E01DA@vigilsec.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 22:44:15 -0000 In article <4FDC1A25-9CC4-4E79-B46B-93BFD36E01DA@vigilsec.com> you write: >> 1) The CNAME is there to make the names equivalent so the CAA record at example.net should aply >> >> 2) The CNAME is only there to make the CDN work and the CAA record at example.net should be ignored. > >If one looks in the DNS for www.ietf.org, one will see: > > www.ietf.org. 607 IN CNAME www.ietf.org.cdn.cloudflare.net. > >I'm not sure how you would expect to distinguish the two cases. If your CDN tries to lock you in with a rogue CAA record, that's a business issue, not a technical one. R's, John From nobody Wed Oct 4 15:49:47 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007A313336A for ; Wed, 4 Oct 2017 15:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=eff.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 sVtrJah16bhH for ; Wed, 4 Oct 2017 15:49:44 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3ACF120724 for ; Wed, 4 Oct 2017 15:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:To:Subject:From; bh=kv+c+iTp1Yr2m39ANt90OAlODFQHMiQUxUDlx4weSaE=; b=h0O5dD8Maj0IhQWwhlD8bekjVL58qYDY/55y4v01Jc9pjrZDgEsDWyiqgwxqyEeCUAxlP/NNaY071gmkNhWEXfTSVQ7vvTZbCK5tpcvv5QNJxPuxcYTxwZ954wABj5FiPNq1dLznoiU4r8GJYc6iUKPgNKFpla+DwROu3aEBSb4=; Received: ; Wed, 04 Oct 2017 15:43:37 -0700 From: Jacob Hoffman-Andrews To: Russ Housley , SPASM Message-ID: Date: Wed, 4 Oct 2017 15:43:39 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: [lamps] Call for consensus on CAA DNAME erratum X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 22:49:46 -0000 In August, Andrew Ayer posted a small erratum regarding DNAME: https://www.rfc-editor.org/errata/eid5097. Note that this is entirely independent from erratum 5065. Both errata are fixed in my caa-simplification draft. However, given that it takes significant time for drafts to become RFCs, I think it is useful to come to consensus on erratum 5097 and set it to "held for document update," so that the CA/Browser Forum can clearly see the intent of this standards-setting body is to treat DNAMEs the same way they are treated elsewhere -- as generators of CNAME aliases rather than as aliases themselves. That will remove some uncertainty while we resolve the issue more thoroughly with a new RFC. Russ, as chair, would you mind calling for consensus on this? Thanks, Jacob From nobody Thu Oct 5 13:31:14 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA64132EC4; Tue, 3 Oct 2017 17:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, 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 hpPG2IxATimV; Tue, 3 Oct 2017 17:58:42 -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 1A8B513321F; Tue, 3 Oct 2017 17:58:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EE8C1BEC3; Wed, 4 Oct 2017 01:58:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 LNnCjuny-IVc; Wed, 4 Oct 2017 01:58:35 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C8F70BEBB; Wed, 4 Oct 2017 01:58:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507078715; bh=VjmvQIbLooq3i7B2aINor9IfW/RvgUTOxCH87LSh7Nw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=HxAZHb6RryHvZk2BMHAAqaW7lRFdvZ8JDprkbfd7sPfG8j2+3JGnXsHSiFZhuao8X h1AFY1D9TrM+vutygMROLHiEND723gedUMpiPWFqEZ/03haa6fqlqVdJykOCNrk9Rt ht6RhMOYoBRfJsqbeF/AhgaYsiTPUuop5CDhsiOI= To: Alexander Truskovsky , "santosh.chokhani@gmail.com" , "david.waltermire@nist.gov" , "kivinen@iki.fi" , "housley@vigilsec.com" Cc: "ipsec@ietf.org" , "ekr@rtfm.com" , "Scott.Mansfield@Ericsson.com" , "spasm@ietf.org" , "Kathleen.Moriarty.ietf@gmail.com" , "itu-t-liaison@iab.org" , "jean-paul.lemaire@univ-paris-diderot.fr" References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 4 Oct 2017 01:58:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ODOjdUHNBLwp07uTAcdCIwUdcPEkt5CE7" Archived-At: X-Mailman-Approved-At: Thu, 05 Oct 2017 13:31:13 -0700 Subject: Re: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 00:58:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ODOjdUHNBLwp07uTAcdCIwUdcPEkt5CE7 Content-Type: multipart/mixed; boundary="guJvfXQfx2dWRPA7xDWnBkvH3Ti7VwlsS"; protected-headers="v1" From: Stephen Farrell To: Alexander Truskovsky , "santosh.chokhani@gmail.com" , "david.waltermire@nist.gov" , "kivinen@iki.fi" , "housley@vigilsec.com" Cc: "ipsec@ietf.org" , "ekr@rtfm.com" , "Scott.Mansfield@Ericsson.com" , "spasm@ietf.org" , "Kathleen.Moriarty.ietf@gmail.com" , "itu-t-liaison@iab.org" , "jean-paul.lemaire@univ-paris-diderot.fr" Message-ID: Subject: Re: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> In-Reply-To: <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> --guJvfXQfx2dWRPA7xDWnBkvH3Ti7VwlsS Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 03/10/17 21:38, Alexander Truskovsky wrote: > This allows X.509 certificates to contain two (or more) public keys > and issuer signatures. The goal would be to ease the migration of > PKI and dependent protocols to new digital signature algorithms. The > motivation was to make the X.509 more cryptographically agile and > simplify the migration to quantum-safe algorithms, but it is > algorithm agnostic. The main benefit of this proposal is that > current systems will be able to use these newer X.509 certificates as > they do today without any modifications, while systems that were > updated to support quantum-safe algorithms can also be updated to > understand the newer X.509 format and use quantum-safe algorithm > instead. I don't believe the "without any modifications" claim. If that were true, then the additional (hopefully) quantum-safe keys or signatures would be mere chaff. I do wonder though if it could be that the advent of a desire for post-quantum signatures is the straw that breaks the X.509 camel's back. For example, with a view to making X.509-based PKI evolution end up sufficiently more expensive compared to displacing X.509 entirely. It'll be fun to see what happens as things pan out. One reason that that might be the case is that the S. >=20 > We are working on a draft that mirrors the ITU-T=E2=80=99s work with a = few > partners and will publish it for review soon. >=20 > Alex >=20 >=20 > On 2017-10-02, 9:58 PM, "IPsec on behalf of Santosh Chokhani" > > wrote: >=20 > I am not sure I understand what is being said below. The link to the > PDF does not add to the message body. >=20 > If there is a concern about what signature algorithm is used for what > type of subject key, X.509 already has that flexibility. >=20 > If there is a concern about using multiple signatures on an X.509=20 > certificate, one can use the single signature algorithm identifier to > define multiple algorithms, parameters, and signatures. >=20 > -----Original Message----- From: Spasm > [mailto:spasm-bounces@ietf.org] On Behalf Of Liaison Statement=20 > Management Tool Sent: Wednesday, September 13, 2017 11:25 AM To: > David Waltermire ; Tero Kivinen=20 > ; Russ Housley Cc: Limited > Additional Mechanisms for PKIX and SMIME Discussion List=20 > ; Eric Rescorla ; Russ Housley=20 > ; Tero Kivinen ; Scott > Mansfield ; IP Security Maintenance and > Extensions Discussion List ; Kathleen Moriarty=20 > ; David Waltermire=20 > ; itu-t-liaison@iab.org;=20 > jean-paul.lemaire@univ-paris-diderot.fr Subject: [lamps] New Liaison > Statement, "LS on ITU-T SG17 work on quantum-safe PKI" >=20 > Title: LS on ITU-T SG17 work on quantum-safe PKI Submission Date: > 2017-09-13 URL of the IETF Web page: > https://datatracker.ietf.org/liaison/1541/ >=20 > From: Jean-Paul Lemaire To: > David Waltermire ,Tero Kivinen=20 > ,Russ Housley Cc: David > Waltermire ,IP Security Maintenance and=20 > Extensions Discussion List > ,itu-t-liaison@iab.org,Limited Additional Mechanisms > for PKIX and SMIME Discussion List ,Russ Housley > ,Scott Mansfield=20 > ,Kathleen Moriarty=20 > ,Tero Kivinen > ,Eric Rescorla Response Contacts:=20 > jean-paul.lemaire@univ-paris-diderot.fr Technical Contacts: Purpose: > For information >=20 > Body: ITU-T Study Group 17 is pleased to inform you that in our=20 > August/September 2017 meeting we agreed to start work on the > inclusion of a proposal to include optional support for multiple > public-key algorithms in Recommendation ITU-T X509 | ISO/IEC 9594-8. >=20 > The industry is preparing ICT systems to be resistant to attacks by=20 > large-scale quantum computers in addition to more sophisticated > attacks by conventional computing resources. Proposed was an optional > feature to the X.509 certificate that provides a seamless migration > capability to existing PKI systems, and is completely backwardly > compatible with existing systems. >=20 > While public-key key establishment algorithms are typically > negotiated between peers and are generally fairly simple to update, > the authentication systems typically rely on a single digital > signature algorithm which are more difficult to update. This is > because of the circular dependency between PKI-based identity systems > and the dependent communication protocols. In order to update a PKI > system, one would typically need to create a duplicate PKI system > that utilizes a new digital signature algorithm and then migrate all > the dependent systems one by one. >=20 > This proposal eliminates the need to create such duplicate PKI > systems by adding optional extensions to contain alternate public key > and alternate signature, and a method for the CA to sign certificates > using a layered approach to ensure that every attribute is > authenticated by both signatures. The resulting certificate, while > containing new quantum safe public key and signature, can still be > used by existing systems relying on the classic public key and > signature. Attachments: >=20 > sp16-sg17-oLS-00068 >=20 > https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-09-13-itu-t-= sg-17 > >=20 -ipsecme-lamps-ls-on-itu-t-sg17-work-on-quantum-safe-pki-attachment-1.pdf= >=20 > _______________________________________________ Spasm mailing list=20 > Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ IPsec mailing list=20 > IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 >=20 >=20 > _______________________________________________ Spasm mailing list=20 > Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm >=20 --guJvfXQfx2dWRPA7xDWnBkvH3Ti7VwlsS-- --ODOjdUHNBLwp07uTAcdCIwUdcPEkt5CE7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ1DI6AAoJEC88hzaAX42iL9gH/R/aYEHSmUoQLMmvh/lV1HUU mwPMzXad/e83gwoXcD5jGevr/FSCtKirlcf/4k/MNsThOn9bUr4VBLRcGrNbfFbj tKEJPvRCKXQcMaLfRT8R8fRdFwwfQdxD6wYR8DlX89ZzB7VC8cgXinOVlYpjUjL4 Ufr6+EFyXgAZW27+yt4lvrZzGRKJzFiKVqnZb52v8xPBhiHPPUhbBib61ePqyqtS evY/OcX4FDK6G5zIaGnvwFIgFI9CDXAv6uGaNOcPCNRIeDTv7A0Fp5Vf51NkuEhl YSzad3TVrUHUcx6EudY3UHozvPTlV88lQDm9f5ztC7KpUbnnxZVsKBAlgcscjDM= =uvKt -----END PGP SIGNATURE----- --ODOjdUHNBLwp07uTAcdCIwUdcPEkt5CE7-- From nobody Thu Oct 5 13:31:20 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B7F132332; Wed, 4 Oct 2017 07:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIGLZWJbPHNc; Wed, 4 Oct 2017 07:17:09 -0700 (PDT) Received: from esa1.isaracorp.com (esa1.isaracorp.com [207.107.152.166]) by ietfa.amsl.com (Postfix) with ESMTP id D516F132403; Wed, 4 Oct 2017 07:17:08 -0700 (PDT) Received: from 172-1-110-12.lightspeed.sntcca.sbcglobal.net (HELO cas.isaracorp.com) ([172.1.110.12]) by ip1.isaracorp.com with ESMTP; 04 Oct 2017 14:22:47 +0000 Received: from mb.isaracorp.com (2002:ac01:6e0b::ac01:6e0b) by mb.isaracorp.com (2002:ac01:6e0b::ac01:6e0b) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 4 Oct 2017 10:17:02 -0400 Received: from mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f]) by mb.isaracorp.com ([fe80::9056:5d62:46d0:fe1f%12]) with mapi id 15.00.1044.021; Wed, 4 Oct 2017 10:17:02 -0400 From: Alexander Truskovsky To: Stephen Farrell , "santosh.chokhani@gmail.com" , "david.waltermire@nist.gov" , "kivinen@iki.fi" , "housley@vigilsec.com" CC: "ipsec@ietf.org" , "ekr@rtfm.com" , "Scott.Mansfield@Ericsson.com" , "spasm@ietf.org" , "Kathleen.Moriarty.ietf@gmail.com" , "itu-t-liaison@iab.org" , "jean-paul.lemaire@univ-paris-diderot.fr" Thread-Topic: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" Thread-Index: AQHTPKv1s08bHgbKA0itrmKJRnAPCqLUAJqA Date: Wed, 4 Oct 2017 14:17:02 +0000 Message-ID: <679DF703-35EF-4D67-A0FD-EFA75F755A8C@isara.com> References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.25.5.208] Content-Type: text/plain; charset="utf-8" Content-ID: <445D1031F11C694C9C28A4941F1A37F2@isaracorp.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 05 Oct 2017 13:31:12 -0700 Subject: Re: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 14:17:12 -0000 VGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnQuIA0KDQpXZSB0cmllZCBpdCBvbiB1bm1vZGlmaWVk IEZpcmVmb3gvQ2hyb21lL1NhZmFyaSBvbiB0aGUgZnJvbnQgZW5kIGFuZCB1bm1vZGlmaWVkIEFw YWNoZSAoT3BlblNTTC9OU1MpIG9uIHRoZSBiYWNrIGVuZCB1c2luZyBhIGNlcnRpZmljYXRlIGNo YWluIGNvbnRhaW5pbmcgUlNBK0xNUyBrZXlzL3NpZ25hdHVyZXMuICBJbiBhbGwgY2FzZXMgYSBj aXBoZXJzdWl0ZWQgdXNpbmcgUlNBIGZvciBhdXRoZW50aWNhdGlvbiB3YXMgbmVnb3RpYXRlZCBh bmQgdGhlIGNvbm5lY3Rpb24gd2FzIHN1Y2Nlc3NmdWxseSBlc3RhYmxpc2hlZCwgZXZlbiBpbiB0 aGUgY2FzZSBvZiBDaHJvbWUvU2FmYXJpIHdoZXJlIHdlIGhhZCB0byBpbmplY3QgdGhlIHJvb3Qg Y2VydGlmaWNhdGUgaW4gdG8gdGhlIE9T4oCZcyB0cnVzdGVkIGtleSBzdG9yZSAoQXBwbGUgS2V5 Y2hhaW4gaW4gdGhpcyBjYXNlKS4gIEluIHRoZSBjbGFzc2ljIHVzZSBjYXNlLCB0aGUgZXh0cmEg a2V5IGFuZCBzaWduYXR1cmUgaXMgbm90IHVzZWQuDQoNCkluIHRoZSB1cGRhdGVkIHNlcnZlciBj YXNlLCB1cG9uIHN0YXJ0dXAgdGhlIHNlcnZlciBjaGVja3MgdGhlIGNlcnRpZmljYXRlIGFuZCBl bmFibGVzIHh4X1JTQV94eCBhbmQgeHhfTE1TX3h4IGNpcGhlciBzdWl0ZXMuICBJdCBuZWdvdGlh dGVzIHh4X1JTQV94eCBjaXBoZXIgc3VpdGUgd2l0aCBhbiB1bm1vZGlmaWVkIGNsaWVudCBhbmQg cHJvY2VlZHMganVzdCBsaWtlIGluIHRoZSB1bm1vZGlmaWVkIGNhc2UgYWJvdmUuICBXaXRoIGEg bW9kaWZpZWQgY2xpZW50LCBpdCBuZWdvdGlhdGVzIHh4X0xNU194eCBjaXBoZXIgc3VpdGUsIHNl bmRzIHRoZSBzYW1lIGNlcnRpZmljYXRlIGNoYWluIGJ1dCBzaWducyB0aGUgREgga2V5cyB1c2lu ZyBMTVMgcHJpdmF0ZSBrZXkgaW5zdGVhZCBvZiBSU0EuICBUaGUgbW9kaWZpZWQgY2xpZW50IOKA nHBlZWxzIHRoZSBvdXRlciBjbGFzc2ljIHNpZ25hdHVyZSBvZmbigJ0gYW5kIHZlcmlmaWVkIHRo ZSBpbm5lciBxdWFudHVtLXNhZmUgc2lnbmF0dXJlIChvbiBhbGwgdGhlIGNlcnRpZmljYXRlIGZp ZWxkcyBtaW51cyB0aGUgY2xhc3NpYyBzaWduYXR1cmUgZmllbGQpIGFsbCB0aGUgd2F5IHVwIHRo ZSBjaGFpbi4gIEl0IHRoZW4gdXNlcyB0aGUgcXVhbnR1bS1zYWZlIHB1YmxpYyBrZXkgdG8gdmVy aWZ5IHRoZSBzaWduYXR1cmUgb24gdGhlIERIIGtleXMuDQoNCkFsZXgNCg0KDQpPbiAyMDE3LTEw LTAzLCA4OjU4IFBNLCAiU3RlcGhlbiBGYXJyZWxsIiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5p ZT4gd3JvdGU6DQoNCiAgICANCiAgICBIaXlhLA0KICAgIA0KICAgIE9uIDAzLzEwLzE3IDIxOjM4 LCBBbGV4YW5kZXIgVHJ1c2tvdnNreSB3cm90ZToNCiAgICA+IFRoaXMgYWxsb3dzIFguNTA5IGNl cnRpZmljYXRlcyB0byBjb250YWluIHR3byAob3IgbW9yZSkgcHVibGljIGtleXMNCiAgICA+IGFu ZCBpc3N1ZXIgc2lnbmF0dXJlcy4gIFRoZSBnb2FsIHdvdWxkIGJlIHRvIGVhc2UgdGhlIG1pZ3Jh dGlvbiBvZg0KICAgID4gUEtJIGFuZCBkZXBlbmRlbnQgcHJvdG9jb2xzIHRvIG5ldyBkaWdpdGFs IHNpZ25hdHVyZSBhbGdvcml0aG1zLiAgVGhlDQogICAgPiBtb3RpdmF0aW9uIHdhcyB0byBtYWtl IHRoZSBYLjUwOSBtb3JlIGNyeXB0b2dyYXBoaWNhbGx5IGFnaWxlIGFuZA0KICAgID4gc2ltcGxp ZnkgdGhlIG1pZ3JhdGlvbiB0byBxdWFudHVtLXNhZmUgYWxnb3JpdGhtcywgYnV0IGl0IGlzDQog ICAgPiBhbGdvcml0aG0gYWdub3N0aWMuICBUaGUgbWFpbiBiZW5lZml0IG9mIHRoaXMgcHJvcG9z YWwgaXMgdGhhdA0KICAgID4gY3VycmVudCBzeXN0ZW1zIHdpbGwgYmUgYWJsZSB0byB1c2UgdGhl c2UgbmV3ZXIgWC41MDkgY2VydGlmaWNhdGVzIGFzDQogICAgPiB0aGV5IGRvIHRvZGF5IHdpdGhv dXQgYW55IG1vZGlmaWNhdGlvbnMsIHdoaWxlIHN5c3RlbXMgdGhhdCB3ZXJlDQogICAgPiB1cGRh dGVkIHRvIHN1cHBvcnQgcXVhbnR1bS1zYWZlIGFsZ29yaXRobXMgY2FuIGFsc28gYmUgdXBkYXRl ZCB0bw0KICAgID4gdW5kZXJzdGFuZCB0aGUgbmV3ZXIgWC41MDkgZm9ybWF0IGFuZCB1c2UgcXVh bnR1bS1zYWZlIGFsZ29yaXRobQ0KICAgID4gaW5zdGVhZC4NCiAgICANCiAgICBJIGRvbid0IGJl bGlldmUgdGhlICJ3aXRob3V0IGFueSBtb2RpZmljYXRpb25zIiBjbGFpbS4gSWYgdGhhdA0KICAg IHdlcmUgdHJ1ZSwgdGhlbiB0aGUgYWRkaXRpb25hbCAoaG9wZWZ1bGx5KSBxdWFudHVtLXNhZmUg a2V5cyBvcg0KICAgIHNpZ25hdHVyZXMgd291bGQgYmUgbWVyZSBjaGFmZi4NCiAgICANCiAgICBJ IGRvIHdvbmRlciB0aG91Z2ggaWYgaXQgY291bGQgYmUgdGhhdCB0aGUgYWR2ZW50IG9mIGEgZGVz aXJlDQogICAgZm9yIHBvc3QtcXVhbnR1bSBzaWduYXR1cmVzIGlzIHRoZSBzdHJhdyB0aGF0IGJy ZWFrcyB0aGUgWC41MDkNCiAgICBjYW1lbCdzIGJhY2suIEZvciBleGFtcGxlLCB3aXRoIGEgdmll dyB0byBtYWtpbmcgWC41MDktYmFzZWQNCiAgICBQS0kgZXZvbHV0aW9uIGVuZCB1cCBzdWZmaWNp ZW50bHkgbW9yZSBleHBlbnNpdmUgY29tcGFyZWQgdG8NCiAgICBkaXNwbGFjaW5nIFguNTA5IGVu dGlyZWx5LiBJdCdsbCBiZSBmdW4gdG8gc2VlIHdoYXQgaGFwcGVucw0KICAgIGFzIHRoaW5ncyBw YW4gb3V0Lg0KICAgIA0KICAgIE9uZSByZWFzb24gdGhhdCB0aGF0IG1pZ2h0IGJlIHRoZSBjYXNl IGlzIHRoYXQgdGhlDQogICAgDQogICAgUy4NCiAgICANCiAgICANCiAgICA+IA0KICAgID4gV2Ug YXJlIHdvcmtpbmcgb24gYSBkcmFmdCB0aGF0IG1pcnJvcnMgdGhlIElUVS1U4oCZcyB3b3JrIHdp dGggYSBmZXcNCiAgICA+IHBhcnRuZXJzIGFuZCB3aWxsIHB1Ymxpc2ggaXQgZm9yIHJldmlldyBz b29uLg0KICAgID4gDQogICAgPiBBbGV4DQogICAgPiANCiAgICA+IA0KICAgID4gT24gMjAxNy0x MC0wMiwgOTo1OCBQTSwgIklQc2VjIG9uIGJlaGFsZiBvZiBTYW50b3NoIENob2toYW5pIg0KICAg ID4gPGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHNhbnRvc2guY2hva2hhbmlA Z21haWwuY29tPg0KICAgID4gd3JvdGU6DQogICAgPiANCiAgICA+IEkgYW0gbm90IHN1cmUgSSB1 bmRlcnN0YW5kIHdoYXQgaXMgYmVpbmcgc2FpZCBiZWxvdy4gIFRoZSBsaW5rIHRvIHRoZQ0KICAg ID4gUERGIGRvZXMgbm90IGFkZCB0byB0aGUgbWVzc2FnZSBib2R5Lg0KICAgID4gDQogICAgPiBJ ZiB0aGVyZSBpcyBhIGNvbmNlcm4gYWJvdXQgd2hhdCBzaWduYXR1cmUgYWxnb3JpdGhtIGlzIHVz ZWQgZm9yIHdoYXQNCiAgICA+IHR5cGUgb2Ygc3ViamVjdCBrZXksIFguNTA5IGFscmVhZHkgaGFz IHRoYXQgZmxleGliaWxpdHkuDQogICAgPiANCiAgICA+IElmIHRoZXJlIGlzIGEgY29uY2VybiBh Ym91dCB1c2luZyBtdWx0aXBsZSBzaWduYXR1cmVzIG9uIGFuIFguNTA5IA0KICAgID4gY2VydGlm aWNhdGUsIG9uZSBjYW4gdXNlIHRoZSBzaW5nbGUgc2lnbmF0dXJlIGFsZ29yaXRobSBpZGVudGlm aWVyIHRvDQogICAgPiBkZWZpbmUgbXVsdGlwbGUgYWxnb3JpdGhtcywgcGFyYW1ldGVycywgYW5k IHNpZ25hdHVyZXMuDQogICAgPiANCiAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZy b206IFNwYXNtDQogICAgPiBbbWFpbHRvOnNwYXNtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBMaWFpc29uIFN0YXRlbWVudCANCiAgICA+IE1hbmFnZW1lbnQgVG9vbCBTZW50OiBXZWRu ZXNkYXksIFNlcHRlbWJlciAxMywgMjAxNyAxMToyNSBBTSBUbzoNCiAgICA+IERhdmlkIFdhbHRl cm1pcmUgPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+OyBUZXJvIEtpdmluZW4gDQogICAgPiA8 a2l2aW5lbkBpa2kuZmk+OyBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMuY29tPiBDYzog TGltaXRlZA0KICAgID4gQWRkaXRpb25hbCBNZWNoYW5pc21zIGZvciBQS0lYIGFuZCBTTUlNRSBE aXNjdXNzaW9uIExpc3QgDQogICAgPiA8c3Bhc21AaWV0Zi5vcmc+OyBFcmljIFJlc2NvcmxhIDxl a3JAcnRmbS5jb20+OyBSdXNzIEhvdXNsZXkgDQogICAgPiA8aG91c2xleUB2aWdpbHNlYy5jb20+ OyBUZXJvIEtpdmluZW4gPGtpdmluZW5AaWtpLmZpPjsgU2NvdHQNCiAgICA+IE1hbnNmaWVsZCA8 U2NvdHQuTWFuc2ZpZWxkQEVyaWNzc29uLmNvbT47IElQIFNlY3VyaXR5IE1haW50ZW5hbmNlIGFu ZA0KICAgID4gRXh0ZW5zaW9ucyBEaXNjdXNzaW9uIExpc3QgPGlwc2VjQGlldGYub3JnPjsgS2F0 aGxlZW4gTW9yaWFydHkgDQogICAgPiA8S2F0aGxlZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+ OyBEYXZpZCBXYWx0ZXJtaXJlIA0KICAgID4gPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+OyBp dHUtdC1saWFpc29uQGlhYi5vcmc7IA0KICAgID4gamVhbi1wYXVsLmxlbWFpcmVAdW5pdi1wYXJp cy1kaWRlcm90LmZyIFN1YmplY3Q6IFtsYW1wc10gTmV3IExpYWlzb24NCiAgICA+IFN0YXRlbWVu dCwgIkxTIG9uIElUVS1UIFNHMTcgd29yayBvbiBxdWFudHVtLXNhZmUgUEtJIg0KICAgID4gDQog ICAgPiBUaXRsZTogTFMgb24gSVRVLVQgU0cxNyB3b3JrIG9uIHF1YW50dW0tc2FmZSBQS0kgU3Vi bWlzc2lvbiBEYXRlOg0KICAgID4gMjAxNy0wOS0xMyBVUkwgb2YgdGhlIElFVEYgV2ViIHBhZ2U6 DQogICAgPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTU0MS8NCiAgICA+ IA0KICAgID4gRnJvbTogSmVhbi1QYXVsIExlbWFpcmUgPGplYW4tcGF1bC5sZW1haXJlQHVuaXYt cGFyaXMtZGlkZXJvdC5mcj4gVG86DQogICAgPiBEYXZpZCBXYWx0ZXJtaXJlIDxkYXZpZC53YWx0 ZXJtaXJlQG5pc3QuZ292PixUZXJvIEtpdmluZW4gDQogICAgPiA8a2l2aW5lbkBpa2kuZmk+LFJ1 c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+IENjOiBEYXZpZA0KICAgID4gV2FsdGVy bWlyZSA8ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdj4sSVAgU2VjdXJpdHkgTWFpbnRlbmFuY2Ug YW5kIA0KICAgID4gRXh0ZW5zaW9ucyBEaXNjdXNzaW9uIExpc3QNCiAgICA+IDxpcHNlY0BpZXRm Lm9yZz4saXR1LXQtbGlhaXNvbkBpYWIub3JnLExpbWl0ZWQgQWRkaXRpb25hbCBNZWNoYW5pc21z DQogICAgPiBmb3IgUEtJWCBhbmQgU01JTUUgRGlzY3Vzc2lvbiBMaXN0IDxzcGFzbUBpZXRmLm9y Zz4sUnVzcyBIb3VzbGV5DQogICAgPiA8aG91c2xleUB2aWdpbHNlYy5jb20+LFNjb3R0IE1hbnNm aWVsZCANCiAgICA+IDxTY290dC5NYW5zZmllbGRARXJpY3Nzb24uY29tPixLYXRobGVlbiBNb3Jp YXJ0eSANCiAgICA+IDxLYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4sVGVybyBLaXZp bmVuDQogICAgPiA8a2l2aW5lbkBpa2kuZmk+LEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4g UmVzcG9uc2UgQ29udGFjdHM6IA0KICAgID4gamVhbi1wYXVsLmxlbWFpcmVAdW5pdi1wYXJpcy1k aWRlcm90LmZyIFRlY2huaWNhbCBDb250YWN0czogUHVycG9zZToNCiAgICA+IEZvciBpbmZvcm1h dGlvbg0KICAgID4gDQogICAgPiBCb2R5OiBJVFUtVCBTdHVkeSBHcm91cCAxNyBpcyBwbGVhc2Vk IHRvIGluZm9ybSB5b3UgdGhhdCBpbiBvdXIgDQogICAgPiBBdWd1c3QvU2VwdGVtYmVyIDIwMTcg bWVldGluZyB3ZSBhZ3JlZWQgdG8gc3RhcnQgd29yayBvbiB0aGUNCiAgICA+IGluY2x1c2lvbiBv ZiBhIHByb3Bvc2FsIHRvIGluY2x1ZGUgb3B0aW9uYWwgc3VwcG9ydCBmb3IgbXVsdGlwbGUNCiAg ICA+IHB1YmxpYy1rZXkgYWxnb3JpdGhtcyBpbiBSZWNvbW1lbmRhdGlvbiBJVFUtVCBYNTA5IHwg SVNPL0lFQyA5NTk0LTguDQogICAgPiANCiAgICA+IFRoZSBpbmR1c3RyeSBpcyBwcmVwYXJpbmcg SUNUIHN5c3RlbXMgdG8gYmUgcmVzaXN0YW50IHRvIGF0dGFja3MgYnkgDQogICAgPiBsYXJnZS1z Y2FsZSBxdWFudHVtIGNvbXB1dGVycyBpbiBhZGRpdGlvbiB0byBtb3JlIHNvcGhpc3RpY2F0ZWQN CiAgICA+IGF0dGFja3MgYnkgY29udmVudGlvbmFsIGNvbXB1dGluZyByZXNvdXJjZXMuIFByb3Bv c2VkIHdhcyBhbiBvcHRpb25hbA0KICAgID4gZmVhdHVyZSB0byB0aGUgWC41MDkgY2VydGlmaWNh dGUgdGhhdCBwcm92aWRlcyBhIHNlYW1sZXNzIG1pZ3JhdGlvbg0KICAgID4gY2FwYWJpbGl0eSB0 byBleGlzdGluZyBQS0kgc3lzdGVtcywgYW5kIGlzIGNvbXBsZXRlbHkgYmFja3dhcmRseQ0KICAg ID4gY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIHN5c3RlbXMuDQogICAgPiANCiAgICA+IFdoaWxl IHB1YmxpYy1rZXkga2V5IGVzdGFibGlzaG1lbnQgYWxnb3JpdGhtcyBhcmUgdHlwaWNhbGx5DQog ICAgPiBuZWdvdGlhdGVkIGJldHdlZW4gcGVlcnMgYW5kIGFyZSBnZW5lcmFsbHkgZmFpcmx5IHNp bXBsZSB0byB1cGRhdGUsDQogICAgPiB0aGUgYXV0aGVudGljYXRpb24gc3lzdGVtcyB0eXBpY2Fs bHkgcmVseSBvbiBhIHNpbmdsZSBkaWdpdGFsDQogICAgPiBzaWduYXR1cmUgYWxnb3JpdGhtIHdo aWNoIGFyZSBtb3JlIGRpZmZpY3VsdCB0byB1cGRhdGUuIFRoaXMgaXMNCiAgICA+IGJlY2F1c2Ug b2YgdGhlIGNpcmN1bGFyIGRlcGVuZGVuY3kgYmV0d2VlbiBQS0ktYmFzZWQgaWRlbnRpdHkgc3lz dGVtcw0KICAgID4gYW5kIHRoZSBkZXBlbmRlbnQgY29tbXVuaWNhdGlvbiBwcm90b2NvbHMuIElu IG9yZGVyIHRvIHVwZGF0ZSBhIFBLSQ0KICAgID4gc3lzdGVtLCBvbmUgd291bGQgdHlwaWNhbGx5 IG5lZWQgdG8gY3JlYXRlIGEgZHVwbGljYXRlIFBLSSBzeXN0ZW0NCiAgICA+IHRoYXQgdXRpbGl6 ZXMgYSBuZXcgZGlnaXRhbCBzaWduYXR1cmUgYWxnb3JpdGhtIGFuZCB0aGVuIG1pZ3JhdGUgYWxs DQogICAgPiB0aGUgZGVwZW5kZW50IHN5c3RlbXMgb25lIGJ5IG9uZS4NCiAgICA+IA0KICAgID4g VGhpcyBwcm9wb3NhbCBlbGltaW5hdGVzIHRoZSBuZWVkIHRvIGNyZWF0ZSBzdWNoIGR1cGxpY2F0 ZSBQS0kNCiAgICA+IHN5c3RlbXMgYnkgYWRkaW5nIG9wdGlvbmFsIGV4dGVuc2lvbnMgdG8gY29u dGFpbiBhbHRlcm5hdGUgcHVibGljIGtleQ0KICAgID4gYW5kIGFsdGVybmF0ZSBzaWduYXR1cmUs IGFuZCBhIG1ldGhvZCBmb3IgdGhlIENBIHRvIHNpZ24gY2VydGlmaWNhdGVzDQogICAgPiB1c2lu ZyBhIGxheWVyZWQgYXBwcm9hY2ggdG8gZW5zdXJlIHRoYXQgZXZlcnkgYXR0cmlidXRlIGlzDQog ICAgPiBhdXRoZW50aWNhdGVkIGJ5IGJvdGggc2lnbmF0dXJlcy4gVGhlIHJlc3VsdGluZyBjZXJ0 aWZpY2F0ZSwgd2hpbGUNCiAgICA+IGNvbnRhaW5pbmcgbmV3IHF1YW50dW0gc2FmZSBwdWJsaWMg a2V5IGFuZCBzaWduYXR1cmUsIGNhbiBzdGlsbCBiZQ0KICAgID4gdXNlZCBieSBleGlzdGluZyBz eXN0ZW1zIHJlbHlpbmcgb24gdGhlIGNsYXNzaWMgcHVibGljIGtleSBhbmQNCiAgICA+IHNpZ25h dHVyZS4gQXR0YWNobWVudHM6DQogICAgPiANCiAgICA+IHNwMTYtc2cxNy1vTFMtMDAwNjgNCiAg ICA+IA0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbGliL2R0L2RvY3VtZW50cy9MSUFJU09O L2xpYWlzb24tMjAxNy0wOS0xMy1pdHUtdC1zZy0xNw0KICAgID4NCiAgICA+IA0KICAgIC1pcHNl Y21lLWxhbXBzLWxzLW9uLWl0dS10LXNnMTctd29yay1vbi1xdWFudHVtLXNhZmUtcGtpLWF0dGFj aG1lbnQtMS5wZGYNCiAgICA+IA0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18gU3Bhc20gbWFpbGluZyBsaXN0IA0KICAgID4gU3Bhc21AaWV0Zi5v cmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcGFzbQ0KICAgID4gDQog ICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBJUHNl YyBtYWlsaW5nIGxpc3QgDQogICAgPiBJUHNlY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiAN CiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIFNw YXNtIG1haWxpbmcgbGlzdCANCiAgICA+IFNwYXNtQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3Bhc20NCiAgICA+IA0KICAgIA0KICAgIA0KDQo= From nobody Thu Oct 5 13:31:25 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254CE120724 for ; Wed, 4 Oct 2017 15:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=1.5, 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 WeZbXJj4ziw4 for ; Wed, 4 Oct 2017 15:19:53 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) (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 369C113334E for ; Wed, 4 Oct 2017 15:19:51 -0700 (PDT) Received: from Morten ([192.174.57.204]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id 2201710050019445429; Thu, 05 Oct 2017 00:19:44 +0200 From: "Erik Andersen" To: "'Santosh Chokhani'" , "'Alexander Truskovsky'" , , , Cc: , , , , , , , References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> <079001d33c88$fab856c0$f0290440$@gmail.com> In-Reply-To: <079001d33c88$fab856c0$f0290440$@gmail.com> Date: Thu, 5 Oct 2017 00:19:41 +0200 Message-ID: <000001d33d5e$e1ad7da0$a50878e0$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDus9F8NjCdvUGnLuU9orle20/kKgI84QjmAbyZK6EBM7nHTAHWhZmZpGU2+AA= Content-Language: en-gb Archived-At: X-Mailman-Approved-At: Thu, 05 Oct 2017 13:31:12 -0700 Subject: Re: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 22:19:55 -0000 Hi Santosh, I do not understand your claim that you can have multiple public keys = and signatures within the base structure of a certificate. Erik -----Oprindelig meddelelse----- Fra: Spasm [mailto:spasm-bounces@ietf.org] P=C3=A5 vegne af Santosh = Chokhani Sendt: 03 October 2017 22:49 Til: 'Alexander Truskovsky' ; = david.waltermire@nist.gov; kivinen@iki.fi; housley@vigilsec.com Cc: ipsec@ietf.org; ekr@rtfm.com; housley@vigilsec.com; = Scott.Mansfield@Ericsson.com; spasm@ietf.org; = Kathleen.Moriarty.ietf@gmail.com; itu-t-liaison@iab.org; = jean-paul.lemaire@univ-paris-diderot.fr Emne: Re: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work = on quantum-safe PKI" Multiple public keys as well as signatures can be accommodated using the = respective algorithm OIDs in Signature and SPKI fields. Have you considered that in place of using an extension. -----Original Message----- From: Alexander Truskovsky [mailto:Alexander.Truskovsky@isara.com]=20 Sent: Tuesday, October 3, 2017 4:38 PM To: santosh.chokhani@gmail.com; david.waltermire@nist.gov; = kivinen@iki.fi; housley@vigilsec.com Cc: spasm@ietf.org; ekr@rtfm.com; housley@vigilsec.com; = Scott.Mansfield@Ericsson.com; ipsec@ietf.org; = Kathleen.Moriarty.ietf@gmail.com; itu-t-liaison@iab.org; = jean-paul.lemaire@univ-paris-diderot.fr Subject: Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 = work on quantum-safe PKI" This allows X.509 certificates to contain two (or more) public keys and = issuer signatures. The goal would be to ease the migration of PKI and = dependent protocols to new digital signature algorithms. The motivation = was to make the X.509 more cryptographically agile and simplify the = migration to quantum-safe algorithms, but it is algorithm agnostic. The = main benefit of this proposal is that current systems will be able to = use these newer X.509 certificates as they do today without any = modifications, while systems that were updated to support quantum-safe = algorithms can also be updated to understand the newer X.509 format and = use quantum-safe algorithm instead. We are working on a draft that mirrors the ITU-T=E2=80=99s work with a = few partners and will publish it for review soon. Alex =20 =20 On 2017-10-02, 9:58 PM, "IPsec on behalf of Santosh Chokhani" = wrote: =20 I am not sure I understand what is being said below. The link = to the PDF does not add to the message body. =20 If there is a concern about what signature algorithm is used for = what type of subject key, X.509 already has that flexibility. =20 If there is a concern about using multiple signatures on an = X.509 certificate, one can use the single signature algorithm = identifier to define multiple algorithms, parameters, and signatures. =20 -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Liaison = Statement Management Tool Sent: Wednesday, September 13, 2017 11:25 AM To: David Waltermire ; Tero Kivinen ; Russ Housley Cc: Limited Additional Mechanisms for PKIX and SMIME Discussion = List ; Eric Rescorla ; Russ Housley ; Tero Kivinen ; Scott = Mansfield ; IP Security Maintenance and = Extensions Discussion List ; Kathleen Moriarty ; David Waltermire ; itu-t-liaison@iab.org; jean-paul.lemaire@univ-paris-diderot.fr Subject: [lamps] New Liaison Statement, "LS on ITU-T SG17 work = on quantum-safe PKI" =20 Title: LS on ITU-T SG17 work on quantum-safe PKI Submission = Date: 2017-09-13 URL of the IETF Web page: = https://datatracker.ietf.org/liaison/1541/ =20 From: Jean-Paul Lemaire = To: David Waltermire ,Tero Kivinen ,Russ Housley Cc: David Waltermire ,IP Security = Maintenance and Extensions Discussion List = ,itu-t-liaison@iab.org,Limited Additional Mechanisms for PKIX and SMIME Discussion List ,Russ Housley ,Scott = Mansfield ,Kathleen Moriarty ,Tero Kivinen = ,Eric Rescorla Response Contacts: jean-paul.lemaire@univ-paris-diderot.fr Technical Contacts:=20 Purpose: For information =20 Body: ITU-T Study Group 17 is pleased to inform you that in our August/September 2017 meeting we agreed to start work on the = inclusion of a proposal to include optional support for multiple public-key = algorithms in Recommendation ITU-T X509 | ISO/IEC 9594-8. =20 The industry is preparing ICT systems to be resistant to attacks = by large-scale quantum computers in addition to more sophisticated = attacks by conventional computing resources. Proposed was an optional = feature to the X.509 certificate that provides a seamless migration capability = to existing PKI systems, and is completely backwardly compatible with = existing systems. =20 While public-key key establishment algorithms are typically = negotiated between peers and are generally fairly simple to update, the = authentication systems typically rely on a single digital signature algorithm = which are more difficult to update. This is because of the circular = dependency between PKI-based identity systems and the dependent communication = protocols. In order to update a PKI system, one would typically need to create = a duplicate PKI system that utilizes a new digital signature algorithm and = then migrate all the dependent systems one by one. =20 This proposal eliminates the need to create such duplicate PKI = systems by adding optional extensions to contain alternate public key and = alternate signature, and a method for the CA to sign certificates using a = layered approach to ensure that every attribute is authenticated by both = signatures. The resulting certificate, while containing new quantum safe = public key and signature, can still be used by existing systems relying on the = classic public key and signature. Attachments: =20 sp16-sg17-oLS-00068 =20 = https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-09-13-itu-t-sg= -17 = -ipsecme-lamps-ls-on-itu-t-sg17-work-on-quantum-safe-pki-attachment-1.pdf= =20 _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 =20 _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Oct 5 13:31:29 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60076134317; Thu, 5 Oct 2017 11:21: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 4nxPQ9UtryKY; Thu, 5 Oct 2017 11:21:43 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F57513433C; Thu, 5 Oct 2017 11:21:43 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id r64so15365297qkc.1; Thu, 05 Oct 2017 11:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=RGveqHok1dBhk8/aN3gCEbk8bggqFEpkh16Qu7tw8dY=; b=vdE7qlZ0jlopezac69IbEnU434MlrfW1L5DYFkOHBr22Fvtj8V794ZFPTAPGeM3dpg 8uIzdpNufuxLoGHwJTQMUeifWYhc17cY82LCb787MdUS9qaLz/FWaaNyR5agzzku/Tt8 r6BVaN+8HUz7nBXtzqp5ka6e9AT3hLutDOhZtPSWndNNn2kEEcWNh6v7jR+uZWBMGmxt 6XgrA42xwZ2DmI34W+6FKJGiXtDZiFJYvSseeKS2G3+2t1JHbP5Xt5F0dOvLcHdUzXJ3 rIyIH3SuqeQnO38XEXd0A1YDSyMBbzGoJw9wPzmnl7c/ehvW+tuchMN6f7cdmZbTJY1G MbCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=RGveqHok1dBhk8/aN3gCEbk8bggqFEpkh16Qu7tw8dY=; b=GyHNofSbRu/KbQj8mZ/IDV4GR3yo/b3rR5nADz/30Q1weBdd1uPZVpD7NciLDqjtjh +2kHiJnWiBb1E9cqqfoDmiujOlZWZzgCwfZMuG+MM0kfb8TEP9Ga6sWo5gssoi2fD0zR ZSDiBkkN98bJaVLxCqu6WwSlj8OQ4799nOHuhvDTZ1Snf/AonDTINp+PmoYZyR/E8RqO 88AgXS4rGkzkgWY3+XRlgvYOFhMichB6ShgOYm7RpoXSGAHCZYMEmjW5qsurenO3eUTR UtYdTzLMOjTI7SxFPgmZy99yFv1YXMoQBqJcNYw4Ozq8cQcdBiqrcH0eYc1lv4XzA6IH gtNg== X-Gm-Message-State: AMCzsaWWLfbnRMbh9FBH/2gQLD0qm3i9H/+Ebqmi8yhYhC9vPfdmJOYt 8tGcY8PRajsabY5CS1Uqld8= X-Google-Smtp-Source: AOwi7QCmCo2mTOBX52uAlcecYfK285sQere07XJZf79zqAG3/0dBlul9bTKCY+WD0Nazi3lmzAhR1w== X-Received: by 10.55.22.146 with SMTP id 18mr31857385qkw.281.1507227702239; Thu, 05 Oct 2017 11:21:42 -0700 (PDT) Received: from SantoshBrain (pool-173-73-191-59.washdc.fios.verizon.net. [173.73.191.59]) by smtp.gmail.com with ESMTPSA id f64sm11884233qka.6.2017.10.05.11.21.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Oct 2017 11:21:41 -0700 (PDT) From: "Santosh Chokhani" To: "'Erik Andersen'" , "'Alexander Truskovsky'" , , , Cc: , , , , , , , References: <150531630127.30557.5933470261200873062.idtracker@ietfa.amsl.com> <055701d33beb$08b3f0c0$1a1bd240$@gmail.com> <524F46CC-8BBB-41ED-8089-6BFE0776F660@isara.com> <1471E3E6-35F2-4D2E-9085-B6B82BC8536D@isara.com> <079001d33c88$fab856c0$f0290440$@gmail.com> <000001d33d5e$e1ad7da0$a50878e0$@x500.eu> In-Reply-To: <000001d33d5e$e1ad7da0$a50878e0$@x500.eu> Date: Thu, 5 Oct 2017 14:21:43 -0400 Message-ID: <0e9001d33e06$cc837710$658a6530$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDus9F8NjCdvUGnLuU9orle20/kKgI84QjmAbyZK6EBM7nHTAHWhZmZAneO7UukUsiEIA== Content-Language: en-us Archived-At: X-Mailman-Approved-At: Thu, 05 Oct 2017 13:31:12 -0700 Subject: Re: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI" X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 18:21:46 -0000 Hello Erik, Since the parameters syntax and semantics for the AlgorithmIdentifier = are defined by the OID, that flexibility can be used to encode multiple = SPKI and signatures. There are several ways to do it. One example is for the parameters to = be SEQUENCE OF AlgorithmIdentifier for the various algorithms covered by = the SPKI and/or signature where you want multiple values. There is more = to it of course. -----Original Message----- From: Erik Andersen [mailto:era@x500.eu]=20 Sent: Wednesday, October 4, 2017 6:20 PM To: 'Santosh Chokhani' ; 'Alexander = Truskovsky' ; david.waltermire@nist.gov; = kivinen@iki.fi; housley@vigilsec.com Cc: ipsec@ietf.org; ekr@rtfm.com; housley@vigilsec.com; = Scott.Mansfield@Ericsson.com; spasm@ietf.org; = Kathleen.Moriarty.ietf@gmail.com; itu-t-liaison@iab.org; = jean-paul.lemaire@univ-paris-diderot.fr Subject: SV: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 = work on quantum-safe PKI" Hi Santosh, I do not understand your claim that you can have multiple public keys = and signatures within the base structure of a certificate. Erik -----Oprindelig meddelelse----- Fra: Spasm [mailto:spasm-bounces@ietf.org] P=C3=A5 vegne af Santosh = Chokhani Sendt: 03 October 2017 22:49 Til: 'Alexander Truskovsky' ; = david.waltermire@nist.gov; kivinen@iki.fi; housley@vigilsec.com Cc: ipsec@ietf.org; ekr@rtfm.com; housley@vigilsec.com; = Scott.Mansfield@Ericsson.com; spasm@ietf.org; = Kathleen.Moriarty.ietf@gmail.com; itu-t-liaison@iab.org; = jean-paul.lemaire@univ-paris-diderot.fr Emne: Re: [lamps] [IPsec] New Liaison Statement, "LS on ITU-T SG17 work = on quantum-safe PKI" Multiple public keys as well as signatures can be accommodated using the = respective algorithm OIDs in Signature and SPKI fields. Have you considered that in place of using an extension. -----Original Message----- From: Alexander Truskovsky [mailto:Alexander.Truskovsky@isara.com]=20 Sent: Tuesday, October 3, 2017 4:38 PM To: santosh.chokhani@gmail.com; david.waltermire@nist.gov; = kivinen@iki.fi; housley@vigilsec.com Cc: spasm@ietf.org; ekr@rtfm.com; housley@vigilsec.com; = Scott.Mansfield@Ericsson.com; ipsec@ietf.org; = Kathleen.Moriarty.ietf@gmail.com; itu-t-liaison@iab.org; = jean-paul.lemaire@univ-paris-diderot.fr Subject: Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 = work on quantum-safe PKI" This allows X.509 certificates to contain two (or more) public keys and = issuer signatures. The goal would be to ease the migration of PKI and = dependent protocols to new digital signature algorithms. The motivation = was to make the X.509 more cryptographically agile and simplify the = migration to quantum-safe algorithms, but it is algorithm agnostic. The = main benefit of this proposal is that current systems will be able to = use these newer X.509 certificates as they do today without any = modifications, while systems that were updated to support quantum-safe = algorithms can also be updated to understand the newer X.509 format and = use quantum-safe algorithm instead. We are working on a draft that mirrors the ITU-T=E2=80=99s work with a = few partners and will publish it for review soon. Alex =20 =20 On 2017-10-02, 9:58 PM, "IPsec on behalf of Santosh Chokhani" = wrote: =20 I am not sure I understand what is being said below. The link = to the PDF does not add to the message body. =20 If there is a concern about what signature algorithm is used for = what type of subject key, X.509 already has that flexibility. =20 If there is a concern about using multiple signatures on an = X.509 certificate, one can use the single signature algorithm = identifier to define multiple algorithms, parameters, and signatures. =20 -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Liaison = Statement Management Tool Sent: Wednesday, September 13, 2017 11:25 AM To: David Waltermire ; Tero Kivinen ; Russ Housley Cc: Limited Additional Mechanisms for PKIX and SMIME Discussion = List ; Eric Rescorla ; Russ Housley ; Tero Kivinen ; Scott = Mansfield ; IP Security Maintenance and = Extensions Discussion List ; Kathleen Moriarty ; David Waltermire ; itu-t-liaison@iab.org; jean-paul.lemaire@univ-paris-diderot.fr Subject: [lamps] New Liaison Statement, "LS on ITU-T SG17 work = on quantum-safe PKI" =20 Title: LS on ITU-T SG17 work on quantum-safe PKI Submission = Date: 2017-09-13 URL of the IETF Web page: = https://datatracker.ietf.org/liaison/1541/ =20 From: Jean-Paul Lemaire = To: David Waltermire ,Tero Kivinen ,Russ Housley Cc: David Waltermire ,IP Security = Maintenance and Extensions Discussion List = ,itu-t-liaison@iab.org,Limited Additional Mechanisms for PKIX and SMIME Discussion List ,Russ Housley ,Scott = Mansfield ,Kathleen Moriarty ,Tero Kivinen = ,Eric Rescorla Response Contacts: jean-paul.lemaire@univ-paris-diderot.fr Technical Contacts:=20 Purpose: For information =20 Body: ITU-T Study Group 17 is pleased to inform you that in our August/September 2017 meeting we agreed to start work on the = inclusion of a proposal to include optional support for multiple public-key = algorithms in Recommendation ITU-T X509 | ISO/IEC 9594-8. =20 The industry is preparing ICT systems to be resistant to attacks = by large-scale quantum computers in addition to more sophisticated = attacks by conventional computing resources. Proposed was an optional = feature to the X.509 certificate that provides a seamless migration capability = to existing PKI systems, and is completely backwardly compatible with = existing systems. =20 While public-key key establishment algorithms are typically = negotiated between peers and are generally fairly simple to update, the = authentication systems typically rely on a single digital signature algorithm = which are more difficult to update. This is because of the circular = dependency between PKI-based identity systems and the dependent communication = protocols. In order to update a PKI system, one would typically need to create = a duplicate PKI system that utilizes a new digital signature algorithm and = then migrate all the dependent systems one by one. =20 This proposal eliminates the need to create such duplicate PKI = systems by adding optional extensions to contain alternate public key and = alternate signature, and a method for the CA to sign certificates using a = layered approach to ensure that every attribute is authenticated by both = signatures. The resulting certificate, while containing new quantum safe = public key and signature, can still be used by existing systems relying on the = classic public key and signature. Attachments: =20 sp16-sg17-oLS-00068 =20 = https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-09-13-itu-t-sg= -17 = -ipsecme-lamps-ls-on-itu-t-sg17-work-on-quantum-safe-pki-attachment-1.pdf= =20 _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 =20 _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Oct 5 15:07:42 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E961330B1 for ; Thu, 5 Oct 2017 15:07:40 -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, 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 (1024-bit key) header.d=cloudflare.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 R_izzOeLoa85 for ; Thu, 5 Oct 2017 15:07:38 -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 7E735126B7E for ; Thu, 5 Oct 2017 15:07:38 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id k123so12724338qke.3 for ; Thu, 05 Oct 2017 15:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=EefYpVl6C28UCeVysuhmMKXjwA+IFrAGZQjJyrgHw20=; b=eSkljYiM+uw3h/MQcI3IKQtOfd48mMGLZ0l8QKCMahB9b3ZMAtdL2MyEhcMFrU/Gg6 RHomU0NmZSUZOr3xvXBRieqHu/GS+CBO6PLKvNgJRlzphyo5zz5qQTEAQJVmaQzM6YqE dqnGDEiztss2M0weU+cIXzfSGxejFkQbOPS0Q= 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=EefYpVl6C28UCeVysuhmMKXjwA+IFrAGZQjJyrgHw20=; b=NkmHlEGpvfMVIKxmBOoJ63rYTpET2ebTPVt32IpQ+g7j7E3MLjvDgeHj/eVaXqVnQ8 IpMR8UXO0yzATtNta47G7oBBh7A1GeuchgqruXoLHnwSKJYgRl25CnrWasRNin1QD0lT B2ZY/L7w5p/kVQe7si7GLdPTpQwyjpjILfz5b0qzxHd5nYwUA4aF6Q4rcbpD9VFslu34 MWt37VCl9jE4QiqQ1hJkpO6lC18X5a7jfPW0lKF6MlMUetDzaHlDZVq5k7iuJBGKGvUq uhihIKk4DUHVV6v23tpNqzw58YViu9nlIaL6HyKR7Z1BuARV4Yvkv2Qv/4uqdUYLnutB +Jxg== X-Gm-Message-State: AMCzsaULC2gphHJeuME5aPzzcM3q5DDgTBL4Bpj6uHQtupDurc3wuDxi xtQxLpcdKrbNzurPJ7HJTJvfDbSWYL4zI44biayXOaBi X-Google-Smtp-Source: AOwi7QDeAwr73vFu9qj2BzcNl7wRd1hEBJB5sW3oiNEEM8V9RqphsgfXV3lDSIkM7RL2WZ94imdjStrhwenG6IjvqNw= X-Received: by 10.55.102.215 with SMTP id a206mr20742073qkc.269.1507241257489; Thu, 05 Oct 2017 15:07:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.82.111 with HTTP; Thu, 5 Oct 2017 15:07:36 -0700 (PDT) From: Patrick Donahue Date: Thu, 5 Oct 2017 15:07:36 -0700 Message-ID: To: johnl@taugh.com Cc: SPASM Content-Type: multipart/alternative; boundary="94eb2c05986ebe6fb6055ad3f3d4" Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 22:07:40 -0000 --94eb2c05986ebe6fb6055ad3f3d4 Content-Type: text/plain; charset="UTF-8" I've provided a real-world counter example below that illustrates why climbing the CNAME tree will cause significant real-world breakages for companies like Cloudflare who provide free SSL certificate issuance and termination. While we believe that erratum 5065 fixes this, we are very much in support of seeing straightforward RFC confirmed that will make it clear to CAs that CNAME tree climbing is no longer required. *Example:* Cloudflare customers have, collectively, over 400,000 CNAMEs to ghs.google.com. This CNAME value is what Google instructs[1] their Blogger customers to use to serve their blog on their own custom domain. Were a CA have to check for a CAA record at google.com (in addition to ghs.google.com) they'd see this: $ dig CAA +short ghs.google.com $ dig CAA +short google.com *0 issue "pki.goog"* 1 - https://support.google.com/blogger/answer/58317?hl=en In article <4FDC1A25-9CC4-4E79-B46B-93BFD36E01DA@vigilsec.com>; you write: > >> 1) The CNAME is there to make the names equivalent so the CAA record at > example.net should aply > >> > >> 2) The CNAME is only there to make the CDN work and the CAA record at > example.net should be ignored. > > > >If one looks in the DNS for www.ietf.org, one will see: > > > > www.ietf.org. 607 IN CNAME www.ietf.org.cdn.cloudflare.net. > > > >I'm not sure how you would expect to distinguish the two cases. > If your CDN tries to lock you in with a rogue CAA record, that's a > business issue, not a technical one. > R's, > John -- Patrick R. Donahue pat@cloudflare.com PGP Fingerprint: 2E8D 5A38 682E EC00 C0F3 E7F2 D9BE 68D2 ABF3 6B24 --94eb2c05986ebe6fb6055ad3f3d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've provided a real-world counter example below = that illustrates why climbing the CNAME tree will cause significant real-wo= rld breakages for companies like Cloudflare who provide free SSL certificat= e issuance and termination.

While we believe that = erratum 5065 fixes this, we are very much in support of seeing straightforw= ard RFC confirmed that will make it clear to CAs that CNAME tree climbing i= s no longer required.

Example:
Cl= oudflare customers have, collectively, over 400,000 CNAMEs to ghs.google.com. This CNAME value= is what Google instructs[1] their Blogger customers to use to serve their = blog on their own custom domain.

Were a CA have to= check for a CAA record at = google.com (in addition to ghs.google.com) they'd see this:

<= div>$ dig CAA +short gh= s.google.com
$ dig CAA +short google.com
0 issue "pki.goog&q= uot;
=C2=A0

In article <4FDC1A2= 5-9CC4-4E79-B46B-93BFD36E01DA@vigilsec.com>; you write:
>= > 1) The CNAME is there to make the names equivalent so the CAA record a= t example.net <http://example.net/> s= hould aply
>>=C2=A0
>> 2) The CNAME is only there to make= the CDN work and the CAA record at example.net <http://example.net/> should be ignored.
>
>If one= looks in the DNS for www= .ietf.org, one will see:
>
> www.ietf.or= g. 607 IN CNA= ME www.ietf.org.cdn.cloudflare.net.
>
>I'm not sure how you would expect to distinguish= the two cases.
If your CDN tries to lock you in with a rogue CAA record= , that's a
business issue, not a technical one.
R's,
John<= /blockquote>


--
P= atrick R. Donahue

PG= P Fingerprint: 2E8D 5A38 682E EC00 C0F3 =C2=A0E7F2 D9BE 68D2 ABF3 6B24
<= /div>
--94eb2c05986ebe6fb6055ad3f3d4-- From nobody Thu Oct 5 18:46:24 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A32D1326FE; Thu, 5 Oct 2017 18:46:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-lamps-rfc5280-i18n-update@ietf.org, Phillip Hallam-Baker , Russ Housley , lamps-chairs@ietf.org, phill@hallambaker.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150725438252.5833.1845084525614926868.idtracker@ietfa.amsl.com> Date: Thu, 05 Oct 2017 18:46:22 -0700 Archived-At: Subject: [lamps] Spencer Dawkins' No Objection on draft-ietf-lamps-rfc5280-i18n-update-03: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 01:46:22 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-lamps-rfc5280-i18n-update-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- You folks would know best what's actually clear to your intended audience, but the use of "provide clarity on the handling of" in the Abstract, These updates to RFC 5280 provide clarity on the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates. and in the first paragraph of the Introduction, This document updates RFC 5280 [RFC5280]. The Introduction in Section 1, the Name Constraints certificate extension discussion in Section 4.2.1.10, and the Processing Rules for Internationalized Names in Section 7 are updated to provide clarity on the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates. wasn't particularly helpful to me. Are there a few words that would describe (at a high level) what the problem with RFC 5280 was, that required this document (I'm suggesting saying "so if you implemented RFC 5280, you can expect problems A and B, so you probably want to implement this specification as well", but in different words)? From nobody Fri Oct 6 07:11:18 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E411349D6 for ; Fri, 6 Oct 2017 07:11:16 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njNw-HrRtUOR for ; Fri, 6 Oct 2017 07:11:15 -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 0DBC41349D3 for ; Fri, 6 Oct 2017 07:11:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BD3593005AD for ; Fri, 6 Oct 2017 10:02:31 -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 BNRR0H386bOM for ; Fri, 6 Oct 2017 10:02:24 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 921C530026A; Fri, 6 Oct 2017 10:02:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <150725438252.5833.1845084525614926868.idtracker@ietfa.amsl.com> Date: Fri, 6 Oct 2017 10:02:23 -0400 Cc: IESG , draft-ietf-lamps-rfc5280-i18n-update@ietf.org, Phillip Hallam-Baker , lamps-chairs@ietf.org, spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150725438252.5833.1845084525614926868.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Spencer Dawkins' No Objection on draft-ietf-lamps-rfc5280-i18n-update-03: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 14:11:17 -0000 Spencer: Two things are going on in this document: (1) This update aligns with IDNA2008. (2) Add support for EAI. So, it might be better to say: These updates to RFC 5280 provide alignment with the 2008 = specification for Internationalized Domain Names (IDNs) and add support for Internationalized Email Addresses in X.509 Certificates. Russ > On Oct 5, 2017, at 9:46 PM, Spencer Dawkins = wrote: >=20 > Spencer Dawkins has entered the following ballot position for > draft-ietf-lamps-rfc5280-i18n-update-03: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > You folks would know best what's actually clear to your intended = audience, but > the use of "provide clarity on the handling of" in the Abstract, >=20 > These updates to RFC 5280 provide clarity on the handling of > Internationalized Domain Names (IDNs) and Internationalized Email > Addresses in X.509 Certificates. >=20 > and in the first paragraph of the Introduction, >=20 > This document updates RFC 5280 [RFC5280]. The Introduction in > Section 1, the Name Constraints certificate extension discussion in > Section 4.2.1.10, and the Processing Rules for Internationalized > Names in Section 7 are updated to provide clarity on the handling of > Internationalized Domain Names (IDNs) and Internationalized Email > Addresses in X.509 Certificates. >=20 > wasn't particularly helpful to me. Are there a few words that would = describe > (at a high level) what the problem with RFC 5280 was, that required = this > document (I'm suggesting saying "so if you implemented RFC 5280, you = can expect > problems A and B, so you probably want to implement this specification = as > well", but in different words)? >=20 >=20 From nobody Fri Oct 6 10:57:28 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266F0134BB7; Fri, 6 Oct 2017 10:57:26 -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 yTfPiCO_cv5C; Fri, 6 Oct 2017 10:57:24 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 10E1D134A01; Fri, 6 Oct 2017 10:57:18 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id o52so32880867qtc.9; Fri, 06 Oct 2017 10:57:18 -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=lxlZcmvr1emZYIAqlcBaYs0UmDnREUOJ2nBe2DUVj50=; b=GxifLY24N5tPaTxV3BOBh7r6ZuYmB/TxpgPe6QNuIsksoqjU3EyKWHnoFpImdaQwmz Vrid1RQ6BwGcOmx0yq5DnGn91b0xFy8PEUTdlQ7SOxRVOzEZ+hnZLINGaJbfG7f/auAs moSF+1VG6jaUeWpqGXhz4Kf8UflO4bsijzCXfxDXjnucR4Qcd85lI2JFJmSs0L6mR/Dh K53HYDhlkEIh0uIwIDSGOjrElI2jcVZFxVHVYVA2pRdEsG0vhpgI6l3QsTQzrl5M0JWa eI9/+x3pd414BsB59pQweDtsJnXVjZQlmr1IwtJrU90nugTkgxvKmlVDF+Y1xG2t968+ 2rYA== 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=lxlZcmvr1emZYIAqlcBaYs0UmDnREUOJ2nBe2DUVj50=; b=Nos9gfyGsC8IPPA9eBUzNzYPbAmxqU5ifshV8EAtd4INnxB080BwJ9WouHmmIJ2q9K p/LiHEbnLgUaWT7moBOQLdbE65UzARV0NqJof7Ci18Q6hnIdgItSeKKQ1xaQMEzsBQr9 yDzInYr4NjS7eHkUsyFCqIxSstnUFEbPdfDdyUfO5bWldK/ZKoQmvDdekcCrfLyGPr+X vHPs3gER0nglmeqvRslo80TUDDuVPVOdtsi/khUGeMEZnEMGAMV70r/PKxm94c4LNDVH OMsMELhkAHOvlcuWUqOTaRCPx8Cy0d6jutV7wbeqUN595DMjVn6EKZEUfNwY3tZrFKam BFrw== X-Gm-Message-State: AMCzsaV+8+ZLnspBO+Bq2imrz3h143VeZZfQF+H0pRzVFTU9r/VnXKym zk0srqwBi3JZh0u2rkGb5tHebbGlk/Y8Q3telI3ipg== X-Google-Smtp-Source: AOwi7QBooDP9Znqwd1MD/Tj6Uiw4K3RzUhlx+Ato1YfYhjlNaWfJxJEYqfF6ztZici1uana4bd+buRm6j3BYwznCv1E= X-Received: by 10.37.162.68 with SMTP id b62mr2226256ybi.195.1507312637013; Fri, 06 Oct 2017 10:57:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.79.86 with HTTP; Fri, 6 Oct 2017 10:57:16 -0700 (PDT) In-Reply-To: References: <150725438252.5833.1845084525614926868.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Fri, 6 Oct 2017 10:57:16 -0700 Message-ID: To: Russ Housley Cc: IESG , draft-ietf-lamps-rfc5280-i18n-update@ietf.org, Phillip Hallam-Baker , lamps-chairs@ietf.org, spasm@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1a01804b7339055ae49208" Archived-At: Subject: Re: [lamps] Spencer Dawkins' No Objection on draft-ietf-lamps-rfc5280-i18n-update-03: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 17:57:26 -0000 --94eb2c1a01804b7339055ae49208 Content-Type: text/plain; charset="UTF-8" Hi, Russ, On Fri, Oct 6, 2017 at 7:02 AM, Russ Housley wrote: > Spencer: > > Two things are going on in this document: > > (1) This update aligns with IDNA2008. > > (2) Add support for EAI. > > So, it might be better to say: > > These updates to RFC 5280 provide alignment with the 2008 specification > for Internationalized Domain Names (IDNs) and add support for > Internationalized Email Addresses in X.509 Certificates. > That's exactly what I was hoping for. Thanks. Spencer > > Russ > > > > On Oct 5, 2017, at 9:46 PM, Spencer Dawkins < > spencerdawkins.ietf@gmail.com> wrote: > > > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-lamps-rfc5280-i18n-update-03: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > You folks would know best what's actually clear to your intended > audience, but > > the use of "provide clarity on the handling of" in the Abstract, > > > > These updates to RFC 5280 provide clarity on the handling of > > Internationalized Domain Names (IDNs) and Internationalized Email > > Addresses in X.509 Certificates. > > > > and in the first paragraph of the Introduction, > > > > This document updates RFC 5280 [RFC5280]. The Introduction in > > Section 1, the Name Constraints certificate extension discussion in > > Section 4.2.1.10, and the Processing Rules for Internationalized > > Names in Section 7 are updated to provide clarity on the handling of > > Internationalized Domain Names (IDNs) and Internationalized Email > > Addresses in X.509 Certificates. > > > > wasn't particularly helpful to me. Are there a few words that would > describe > > (at a high level) what the problem with RFC 5280 was, that required this > > document (I'm suggesting saying "so if you implemented RFC 5280, you can > expect > > problems A and B, so you probably want to implement this specification as > > well", but in different words)? > > > > > > --94eb2c1a01804b7339055ae49208 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Russ,

On Fri, Oct 6, 2017 at 7:02 AM, Russ Housley <= ;housley@vigilsec= .com> wrote:
Spencer:

Two things are going on in this document:

(1)=C2=A0 This update aligns with IDNA2008.

(2)=C2=A0 Add support for EAI.

So, it might be better to say:

=C2=A0 =C2=A0These updates to RFC 5280 provide alignment with the 2008 spec= ification
=C2=A0 =C2=A0for Internationalized Domain Names (IDNs) and add support for<= br> =C2=A0 =C2=A0Internationalized Email Addresses in= X.509 Certificates.

That's = exactly what I was hoping for. Thanks.

Spencer
=C2=A0

Russ


> On Oct 5, 2017, at 9:46 PM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote= :
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-lamps-rfc5280-i18n-update-03: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.= org/doc/draft-ietf-lamps-rfc5280-i18n-update/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> You folks would know best what's actually clear to your intended a= udience, but
> the use of=C2=A0 "provide clarity on the handling of" in the= Abstract,
>
>=C2=A0 =C2=A0These updates to RFC 5280 provide clarity on the handling = of
>=C2=A0 =C2=A0Internationalized Domain Names (IDNs) and Internationalize= d Email
>=C2=A0 =C2=A0Addresses in X.509 Certificates.
>
> and in the first paragraph of the Introduction,
>
>=C2=A0 =C2=A0This document updates RFC 5280 [RFC5280].=C2=A0 The Introd= uction in
>=C2=A0 =C2=A0Section 1, the Name Constraints certificate extension disc= ussion in
>=C2=A0 =C2=A0Section 4.2.1.10, and the Processing Rules for Internation= alized
>=C2=A0 =C2=A0Names in Section 7 are updated to provide clarity on the h= andling of
>=C2=A0 =C2=A0Internationalized Domain Names (IDNs) and Internationalize= d Email
>=C2=A0 =C2=A0Addresses in X.509 Certificates.
>
> wasn't particularly helpful to me.=C2=A0 Are there a few words tha= t would describe
> (at a high level) what the problem with RFC 5280 was, that required th= is
> document (I'm suggesting saying "so if you implemented RFC 52= 80, you can expect
> problems A and B, so you probably want to implement this specification= as
> well", but in different words)?
>
>


--94eb2c1a01804b7339055ae49208-- From nobody Fri Oct 6 14:04:26 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8389E13304A for ; Fri, 6 Oct 2017 14:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=fTst+MJ3; dkim=pass (1536-bit key) header.d=taugh.com header.b=DFteVNzb 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 Z1aWWO6JUg2X for ; Fri, 6 Oct 2017 14:04:23 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 AA703132D89 for ; Fri, 6 Oct 2017 14:04:22 -0700 (PDT) Received: (qmail 10685 invoked from network); 6 Oct 2017 21:04:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=29b8.59d7efd5.k1710; bh=YKPq5F00k+KbTdzf+sflS2oB+nbplPtB5AEYhwnBNPc=; b=fTst+MJ3cikrCbzjmd+R2IhneEfb1Ha60KL+d4Ahuhzwz9ZrMrEmV8uOIy88LeCkZC1j4Im3ySFb7JnelENr5tWwyu6Eo3OzoLsZwsuF625408apf2jHLI3WVI4eAbvO9ZFrPlr0f/NLOuBqXBzjYn0bM5Ib3Ayx+0vdiIVYFjF9BYqZFbRGr4H3mDnPkVWuvCsa80coJiTz90E5QRyKmFxEfoPhbMJPy4JzOmHSZ+X7p0hOdtY9WpfFFwiR0QfC DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=29b8.59d7efd5.k1710; bh=YKPq5F00k+KbTdzf+sflS2oB+nbplPtB5AEYhwnBNPc=; b=DFteVNzbUHnZk/DjtCAPWbNeTMZ2xErO6J4FtLWgDAEPF0y2rKf1+PRhnJgvzTJOdc/ERfs00Svg1GnaDr6ipPFhXr4vrzZb2to28G7RAO7WAaddTlSDLfTwRrkjYCBuTQJD52SFzws/iDDV+O0aYIaoAxFPazV3mcyxuu7/BKQ+1cYrkBmBPkT35UccFz005ecw6MK/J6bHfaqVK/UgVrKZGI4tjcxXIJ8r9mGY9wCOGRetNhv16ELz999nn+eA Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 06 Oct 2017 21:04:20 -0000 Date: 6 Oct 2017 17:04:20 -0400 Message-ID: From: "John R Levine" To: "Patrick Donahue" Cc: "SPASM" In-Reply-To: References: User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 21:04:24 -0000 > I've provided a real-world counter example below that illustrates why > climbing the CNAME tree ... Oh, sorry, I misread some previous messages and misunderstood the problem. I agree, the domain owner needs to be able to publish CAA independent of where it might be hosted. Since I am not a fan of tree climibing or of the PSL, here's my suggestion: www.mysite.example. CNAME something.smogflare.example. ; indirect to web host 1. first look for CAA here, works whether name is CNAME'd _caa.www.mysite.example. CAA 128 issue "letsencrypt.org" 2. failing that look for it here, backward compatible www.mysite.example. CAA 128 issue "letsencrypt.org" 3. Failing that, stop. This doesn't deal with DNAMEs but I don't see any reasonable solution to DNAMEs since I don't see any reasonble way to construct a non-DNAME'd name from a DNAME'd one. R's, John From nobody Fri Oct 6 14:35:23 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB7C13307F for ; Fri, 6 Oct 2017 14:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 (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 5CWRq80K8DgB for ; Fri, 6 Oct 2017 14:35:20 -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 4C0D41320C9 for ; Fri, 6 Oct 2017 14:35:20 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id v9so19480493oif.13 for ; Fri, 06 Oct 2017 14:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kcerB2uyNt7QHNcshjusRwLdCbkk48iPNJt0AcyOMWA=; b=rqqXmGyUfiTSa/Y8NY2vy3EmGxFYd1PTx5+bqREbDJvYsgz8eK1nOjr/ZnxQqDWc0v fL1uqZg5VNdaPvSSqsR0EUT9MM7WsTGiKzlbqr6JjXNyKK/iUAtPCRkIwVGJpMZaAskE TmMeKCs6xOtDG9prja9viHq6OCyWWjWESJC6xANtQwUVVz2EbvZIs9z0QN/BUYje+HmJ iI+npjNOG86yUSoeNQZAHa+PeLUEcRv0YUooSwDWiUX4+IS2MkdrcBnpfRLGizaZ1pb/ 84DdnVc9SuGA4INlSl3JcducZI3MXShRDbUWm476KSW2gp7/a5tpof08m5QJd8V11Vam YvXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kcerB2uyNt7QHNcshjusRwLdCbkk48iPNJt0AcyOMWA=; b=WfJpf8+CBXDZkQpkI28IRU5DUhKmTi4CQ59t4+dG4QCYP2BwlihL+P7u8+iilvvS8Y wOUnAh4UYJz07lvdlhkR6uj165jGVs1UcqKfxbQGdxJNIKoXkXEPSNrVAvcK2ElKGNU4 fu34agSeS2JdMgOt1pQNmNiDTzYATycbNqe3qVerz0/kF06XmfKF1VA0bmK1lWNBJ4ZX fdTJAGuqbnlWyAf2cA2iDtn+XOAOmqJx3d6jGvqCq/iVO0+b6ycmMFGGWO5McvKzmlFC r6wQ0vhGug0qNu6mJxZ5EFKua4rpcGYKWeh+offJNS+D0KRHmhHKMz2gJUuIgH/MewsE EoiA== X-Gm-Message-State: AMCzsaW1WJLWDY/ouwx8/KiAWPzMsbCi9nMBa2e4w+kIs/+/FmzqK7f5 8EnkuWmdeJ6x9Jarby+HNnjdgeonWMUih+g6MB0= X-Google-Smtp-Source: AOwi7QDutunNS9IS+wYjX6BSKRcgVtK/pneb4p9upeCQX26NwS5xC1XcXkkOHEkAJVrNz6+ClButMKu0mnwOzJxxXv0= X-Received: by 10.157.17.6 with SMTP id g6mr2092348ote.305.1507325719532; Fri, 06 Oct 2017 14:35:19 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.95.12 with HTTP; Fri, 6 Oct 2017 14:35:19 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Fri, 6 Oct 2017 17:35:19 -0400 X-Google-Sender-Auth: pvgMIGXsY6Ex6LdtmcZpEJbPFG4 Message-ID: To: John R Levine Cc: Patrick Donahue , SPASM Content-Type: multipart/alternative; boundary="001a1146208612dd03055ae79e88" Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 21:35:22 -0000 --001a1146208612dd03055ae79e88 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 6, 2017 at 5:04 PM, John R Levine wrote: > I've provided a real-world counter example below that illustrates why >> climbing the CNAME tree ... >> > > Oh, sorry, I misread some previous messages and misunderstood the problem= . > I agree, the domain owner needs to be able to publish CAA independent of > where it might be hosted. > > Since I am not a fan of tree climibing or of the PSL, here's my suggestio= n: > > www.mysite.example. CNAME something.smogflare.example. ; indirect to we= b > host > > 1. first look for CAA here, works whether name is CNAME'd > > _caa.www.mysite.example. CAA 128 issue "letsencrypt.org" > > 2. failing that look for it here, backward compatible > > www.mysite.example. CAA 128 issue "letsencrypt.org" > > 3. Failing that, stop. > > This doesn't deal with DNAMEs but I don't see any reasonable solution to > DNAMEs since I don't see any reasonble way to construct a non-DNAME'd nam= e > from a DNAME'd one. =E2=80=8BTree climbing is necessary in the primary domain because of the wi= despread use of split DNS. Many certificates are issued for machines that are not and will not ever be visible on the public network. This is absolutely as intended. Wildcard certificates are not an acceptable solution because they are not available for Extended Validation for good reasons.=E2=80=8B --001a1146208612dd03055ae79e88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Oc= t 6, 2017 at 5:04 PM, John R Levine <johnl@taugh.com> wrote:
I've provided a real-world counter example below that illustrates why climbing the CNAME tree ...

Oh, sorry, I misread some previous messages and misunderstood the problem. = I agree, the domain owner needs to be able to publish CAA independent of wh= ere it might be hosted.

Since I am not a fan of tree climibing or of the PSL, here's my suggest= ion:

www.mysite.example. CNAME something.smogflare.example.=C2=A0 =C2=A0; indire= ct to web host

1. first look for CAA here, works whether name is CNAME'd

_caa.www.mysite.example. CAA=C2=A0 128 issue "letsencrypt.org"
2. failing that look for it here, backward compatible

www.mysite.example. CAA=C2=A0 128 issue "letsencrypt.org"

3. Failing that, stop.

This doesn't deal with DNAMEs but I don't see any reasonable soluti= on to DNAMEs since I don't see any reasonble way to construct a non-DNA= ME'd name from a DNAME'd one.

=E2=80=8BTree climbing is= necessary in the primary domain because of the widespread use of split DNS= . Many certificates are issued for machines that are not and will not ever = be visible on the public network. This is absolutely as intended.

Wildcard certificates are not an a= cceptable solution because they are not available for Extended Validation f= or good reasons.=E2=80=8B


=C2=A0
--001a1146208612dd03055ae79e88-- From nobody Fri Oct 6 14:42:40 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C58113319E for ; Fri, 6 Oct 2017 14:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.102 X-Spam-Level: X-Spam-Status: No, score=-5.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.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 b2pTWvc_Ejdl for ; Fri, 6 Oct 2017 14:42:38 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73ABE13307F for ; Fri, 6 Oct 2017 14:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=1O1nJu7x5Y3QYBSilFYORFeAvdJEHvqYaaHymTs3yjs=; b=fwWRlr4Yog2v5K/LO+W7eNYnjWmkLaojkxJwGubuVCEiXUh2nhdGNrMmOJpmjzQ8CjIkGiT5vLI+eDod9J3nPZUNPs6g1RUmjHS9zxPyvgzIw6xXWdlmVV7MJic05y8vgsIJUyxLRJ51/pkCs1cDiXtOeccwkjew9mSqGAQ7A5k=; Received: ; Fri, 06 Oct 2017 14:42:35 -0700 To: John R Levine , Patrick Donahue Cc: SPASM References: From: Jacob Hoffman-Andrews Message-ID: <7b98f765-4fea-5b71-e860-e46c11d6617e@eff.org> Date: Fri, 6 Oct 2017 14:42:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 21:42:39 -0000 On 10/06/2017 02:04 PM, John R Levine wrote: > This doesn't deal with DNAMEs but I don't see any reasonable solution > to DNAMEs since I don't see any reasonble way to construct a > non-DNAME'd name from a DNAME'd one. Note that there is no need to deal explicitly with DNAMEs (or CNAMEs). They are handled for us by the DNS spec, and are resolved transparently by any recursive resolver. This is the main issue fixed in the caa-simplification draft. From nobody Fri Oct 6 15:14:43 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40777124207 for ; Fri, 6 Oct 2017 15:14:41 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=EqKTRKFS; dkim=pass (1536-bit key) header.d=taugh.com header.b=cMbjmX3g 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 SmrXO3B_DmcX for ; Fri, 6 Oct 2017 15:14:39 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 08D25133090 for ; Fri, 6 Oct 2017 15:14:38 -0700 (PDT) Received: (qmail 23977 invoked from network); 6 Oct 2017 22:14:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5da7.59d8004d.k1710; bh=2qgc5mB4BCR/qS4miC7A6ShTcsi9cdP6Ex7pdYWrguc=; b=EqKTRKFSohbHftICvHHSXZB2qvFmRCDZ36EkKoCQl3jErcrVqTfvgauRuWzLuA9TNo6bQ7Dlg2TWZFGG5u4NrgS219TVhDqhwenEwXc1EcepGKUk5eM5Kkahf7Lg6iOBD747UcPDBcQEZaN5EdvUIaf98dX9xnR42D92vdsfVWXoolHve1UMu6OteWdeaXC0uMM6TRI3khMJNKfMxYLICZK5UyzRV2AhGnTBiF6ytIC4XUDH2ykY7AXs754hPzxp DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5da7.59d8004d.k1710; bh=2qgc5mB4BCR/qS4miC7A6ShTcsi9cdP6Ex7pdYWrguc=; b=cMbjmX3gtsZOVPhGG4ig1XVdMC6RI8AeVByFX5fZSOtGz4qnaT8t9jPXG+WbRBMLM5biiOJhknFXD8kwJvWsAOjAYd7p/J0wxmXfAZdl9F5bsjkFOOFChFG3PF0sbEI8O0LMEWkbhIUfSaG3x9lw94RwQPgZcibg8E7dUgsTaPqOrFfNZAvEQ5VeZ+qVec7tohFKPYnKdN4pu028Yi/9uP+6ogyTN2qYVzviWWnwdvuolqb6gRmInuIU3LwnAeIM Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 06 Oct 2017 22:14:37 -0000 Date: 6 Oct 2017 18:14:37 -0400 Message-ID: From: "John R Levine" To: "Jacob Hoffman-Andrews" Cc: "SPASM" In-Reply-To: <7b98f765-4fea-5b71-e860-e46c11d6617e@eff.org> References: <7b98f765-4fea-5b71-e860-e46c11d6617e@eff.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 22:14:41 -0000 On Fri, 6 Oct 2017, Jacob Hoffman-Andrews wrote: > On 10/06/2017 02:04 PM, John R Levine wrote: >> This doesn't deal with DNAMEs but I don't see any reasonable solution >> to DNAMEs since I don't see any reasonble way to construct a >> non-DNAME'd name from a DNAME'd one. > Note that there is no need to deal explicitly with DNAMEs (or CNAMEs). > They are handled for us by the DNS spec, and are resolved transparently > by any recursive resolver. This is the main issue fixed in the > caa-simplification draft. If you'll review the messages you're responding to, you'll see that the problem is that we want a CNAME'd web server and a non-CNAME'd CAA. There are some cases where tree climbing might fix that, but a lot where it won't, e.g.: mydom.example. CAA issue "nope" ; no web server here www.mydom.example. CNAME somehost.example. ; web server here Where does the CAA go? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Oct 6 15:20:24 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B01D133090 for ; Fri, 6 Oct 2017 15:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.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 pEPJyCl-BmA8 for ; Fri, 6 Oct 2017 15:20:21 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049B5133064 for ; Fri, 6 Oct 2017 15:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=SAgeeBpNFI8jRriAt36Rtnx0Qb0hFvwzla/tSHVAgxs=; b=ikKCPqCAwxV5MPBIoAoDHSy0RLK+tc8FeF8avexrH1l8TZoHS7MjU592az6Q26Q8YPMFTYNOX7X9/4B0qkCrDdUtnMWuDE/n0BSxWSNiPWMCGAXfs78Rr1YqBScQanW3hN1AdKto6QOyisdsEyp6bT3hPQtxpQsKWj/jZmc35U0=; Received: ; Fri, 06 Oct 2017 15:20:18 -0700 To: John R Levine Cc: SPASM References: <7b98f765-4fea-5b71-e860-e46c11d6617e@eff.org> From: Jacob Hoffman-Andrews Message-ID: <61e71386-fb35-0c00-e473-03f2a100c32c@eff.org> Date: Fri, 6 Oct 2017 15:20:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 22:20:23 -0000 On 10/06/2017 03:14 PM, John R Levine wrote: > If you'll review the messages you're responding to, you'll see that > the problem is that we want a CNAME'd web server and a non-CNAME'd > CAA.  There are some cases where tree climbing might fix that, but a > lot where it won't, e.g.: > > mydom.example.  CAA issue "nope"   ; no web server here > www.mydom.example. CNAME somehost.example. ; web server here > > Where does the CAA go? Three options:  - Remove the record on mydom.example  - Adjust the record for mydom.example to allow issuance by preferred CAs  - Ask the maintainer of somehost.example to install an appropriate CAA record From nobody Fri Oct 6 15:25:44 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C43124207 for ; Fri, 6 Oct 2017 15:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=isp0cYIL; dkim=pass (1536-bit key) header.d=taugh.com header.b=GjMDCkjk 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 YK4Pf9cBoLRL for ; Fri, 6 Oct 2017 15:25:41 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 5A6CA1330B0 for ; Fri, 6 Oct 2017 15:25:41 -0700 (PDT) Received: (qmail 26336 invoked from network); 6 Oct 2017 22:25:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=66dc.59d802e4.k1710; bh=lwab1XcZdRF2ta5OyHubdEvAPKjcGc/NMNRTaqA3A/4=; b=isp0cYILAgUeg5jrtx7saifWyhgsrdJ1jaQF3joFcg0EKiAAg6h6Xzw+/IjSDUFMVc3lrysGIYWBxcH4j2Y1kikGYWlUJcSxu5M8yGO4BAnnFSOf5aDu7wo2r6LvIn2Ksu7n9zJMPfJm/XyGUpGhO5vkBWvU2gJHWWeSxo8gjEPFdzg+gXk5n056u0uXVlO/cqvJykK7YG4ZKS2iKRgtWqz95T9Ak63TFRjCFbmm2419/moxZIbGAhyI1JXpCPCK DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=66dc.59d802e4.k1710; bh=lwab1XcZdRF2ta5OyHubdEvAPKjcGc/NMNRTaqA3A/4=; b=GjMDCkjk4vK6CBGC82m+O/eqa2OnpcOTLaNuPozwbwbbgxQc1v6VKkx9NbNWj48nMIrdopHnOEYGN/EyqJMF9ooRK0wh8QPsuGHNOA7/+VaRWyYA30GpFUS6VUZCqYMSSNEQTyUhELuuj5zn+6xYKRFymGI80MTTYtw/mCNBIMDSdFoZa4C1c6vwcgDLYPCoeaFKS3wQgsYiXDof6yBIyavCOo8Cjek5dl7kgtUchcrHDBEy8zjRZDH+WiRTXDJi Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 06 Oct 2017 22:25:40 -0000 Date: 6 Oct 2017 18:25:39 -0400 Message-ID: From: "John R Levine" To: "Jacob Hoffman-Andrews" Cc: "SPASM" In-Reply-To: <61e71386-fb35-0c00-e473-03f2a100c32c@eff.org> References: <7b98f765-4fea-5b71-e860-e46c11d6617e@eff.org> <61e71386-fb35-0c00-e473-03f2a100c32c@eff.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-846918735-1507328740=:33785" Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 22:25:42 -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. --0-846918735-1507328740=:33785 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT >> mydom.example.  CAA issue "nope"   ; no web server here >> www.mydom.example. CNAME somehost.example. ; web server here >> >> Where does the CAA go? > Three options: > >  - Remove the record on mydom.example I don't want a web server at all that name. No dice. >  - Adjust the record for mydom.example to allow issuance by preferred CAs I still don't want a web server at that name. No dice. >  - Ask the maintainer of somehost.example to install an appropriate CAA > record If you'll review the message two or three back at in this thread, you'll note that there are cases where somehost.example has 400,000 names CNAMEd to it. No dice. Waving this problem away is not helpful. R's, John --0-846918735-1507328740=:33785-- From nobody Fri Oct 6 15:27:43 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD2E133064 for ; Fri, 6 Oct 2017 15:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=r4fV6i5y; dkim=pass (1536-bit key) header.d=taugh.com header.b=fn/rZhuz 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 6VAcmQAPCbnF for ; Fri, 6 Oct 2017 15:27:40 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 CEC8B133090 for ; Fri, 6 Oct 2017 15:27:39 -0700 (PDT) Received: (qmail 26769 invoked from network); 6 Oct 2017 22:27:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=688f.59d8035b.k1710; bh=u0SLB1MV+MbPUfBl1o8f1IPBRcrndg6GLHkwZq0hEWQ=; b=r4fV6i5y3ZQS2yrbFJsjc8vft0VyMXe9ZcRVrUwLY405VGDLlyAg8yYNsM0mhGORyj9HCGrxmi02MuYlql+PhiK5XFo80Er89TPVK/zAPKrlDP7pp72vj5bdRnHgLgA0uFIDkTDcTqakVzflsYIBDFa/z8z61XXEFtpU/TE8n8fMxaa3WUykpycXXmXoy0YDQRWqs/4qypb7+8QEAYlR8A7SjGhcGDWjcBxsCdb4oj/zKUnGWiGvoQxE5BXIQjJf DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=688f.59d8035b.k1710; bh=u0SLB1MV+MbPUfBl1o8f1IPBRcrndg6GLHkwZq0hEWQ=; b=fn/rZhuzK+U+9uAN9ujyeVDMgwspqvJj+6Wi6PP1w9WaF11X+tVwxIX4Jphz7YUTrVMXlw6xXYB1Fpg0Td0VAGoxklJbfi8iaT47drfx/JOannnF0vCEn7+jCrWmMkzseSuQVYNohULZE5TTJmaX0XlFe+PYmpTS9cb/0QMzouJGUUHLnOeVcBiqfaReh7ftmwbfky16Za18pPM7yf6hbTdA2XxVHudR6dJjJ3NK1dsMyPESm3ErxJeI8ED1vRvc Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 06 Oct 2017 22:27:38 -0000 Date: 6 Oct 2017 18:27:38 -0400 Message-ID: From: "John R Levine" To: "SPASM" In-Reply-To: <7b98f765-4fea-5b71-e860-e46c11d6617e@eff.org> References: <7b98f765-4fea-5b71-e860-e46c11d6617e@eff.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [lamps] CAA tree climbing, gurrghhg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 22:27:41 -0000 I see that the current draft says that CAs climb up the tree a label at a time all the way to the TLD, looking for a CAA policy record. I think you will find a great deal of resistance to that design, because it runs into the dbound problem. If I register fobar.hockey, I do not want the .hockey TLD setting my default certificate policy. DMARC has a similar problem looking for policy records for mail authentication. If there's no _dmarc record for a particular domain, implementations find the related "organizational domain", roughly the highest name under the same management, and it looks for a _dmarc record for the organizational domain. Current implementations use the mozilla PSL or something similar; if we were able to converge in something in dbound or its reincarnation, they'd use that instead. I cheefully agree that the PSL is awful, but as far as I can tell all of the alternatives are worse. R's, John From nobody Fri Oct 6 19:50:20 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104EE132D8A for ; Fri, 6 Oct 2017 19:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnArhVs1Z-Oz for ; Fri, 6 Oct 2017 19:50:17 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 ADD7513292F for ; Fri, 6 Oct 2017 19:50:16 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id h200so5329655oib.4 for ; Fri, 06 Oct 2017 19:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UvlPr6AWvIiUDwN016GAzK8x0uhbKXoXUIhHRnGI0LE=; b=Tc4a+9KVap+Gp1mZzEwfoH3IJgn4KZIQ2j4vhKuNkbiYc52jTsK0EV1CAzb1pVxjI/ ENngeVP7/ak1OrcL4ohnK2rXqvGUc/LJQH3z9wBCqyXPvAkmMIIqEQLNOW8dKeC4K9Ir A2d79gN20Jblo/pSqQxi9FnwNMy9n8c0zTh223p2Rs78HFXvOe9/gHhqkbaOFUK7fXwz dC8o1BCNEkwo7YUGdstxyLLbundMj0z6ej3b+TTaBbVdz5sm4k0p+YO3knwJaynqZd9F Wna+USl/1i/XLEzhR3vr1EfeUb1vBkBoPXI/azDOxe4TCjKJVKIUvcbd1MCrlEMTE3N6 QIdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UvlPr6AWvIiUDwN016GAzK8x0uhbKXoXUIhHRnGI0LE=; b=aNzuWiWCA3yxqzGUMkRhOXJaXUDvZ6dt7qJ/lkT8oM2qohPP0iY7eGR9FlS/jMs5RW avzRnfdwBDtXgP+7MtFMXqqLFhnQsjhdLPWIRKgNYFid+/1MdvdqyCfOqYvFvmZaNWbp oy1UnlmNNxaUJs/zDqGX2yrUdVE/BAjYr2F1T/R7CdJS0RjY7jNqhFbCS72ZIQcX09lW A6ScmX937SbOcTWUE3FgoMeDhYGd8HoEWy6n0mv87uWlhphnw5mzpw+VRe62o9REHQf+ aLgBKyWH1WQzgDNdhsAi9nwocKYf/aVAFfHn0hC+LGVUeU3DjvMmd/HrScok9EEx4WqP Kw4w== X-Gm-Message-State: AMCzsaVbrtb/9tSCq0tjQAzVrmWywhhMWew5s3fV5N8t0Ca13mwTL2Gk ZhJrGdo9cIjxubEWIoSrBiv1mrVHiSdR9JXHKNo= X-Google-Smtp-Source: AOwi7QA7fNMwtC6eYUaHg+7RWH2kvqfD7sv7c//rcS7lSeUc8qyFfzRpqVA45DEkwKfdhLWz5BnEnz6K/pJ0ivvK9fs= X-Received: by 10.202.166.9 with SMTP id p9mr2042027oie.220.1507344615990; Fri, 06 Oct 2017 19:50:15 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.95.12 with HTTP; Fri, 6 Oct 2017 19:50:15 -0700 (PDT) In-Reply-To: References: <7b98f765-4fea-5b71-e860-e46c11d6617e@eff.org> <61e71386-fb35-0c00-e473-03f2a100c32c@eff.org> From: Phillip Hallam-Baker Date: Fri, 6 Oct 2017 22:50:15 -0400 X-Google-Sender-Auth: 4yLA1tmOw7ixGG72y1R4iYmSYH8 Message-ID: To: John R Levine Cc: Jacob Hoffman-Andrews , SPASM Content-Type: multipart/alternative; boundary="001a11394aa263eb7f055aec040a" Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 02:50:18 -0000 --001a11394aa263eb7f055aec040a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 6, 2017 at 6:25 PM, John R Levine wrote: > mydom.example. CAA issue "nope" ; no web server here >>> www.mydom.example. CNAME somehost.example. ; web server here >>> >>> Where does the CAA go? >>> >> Three options: >> >> - Remove the record on mydom.example >> > > I don't want a web server at all that name. No dice. > > - Adjust the record for mydom.example to allow issuance by preferred CAs >> > > I still don't want a web server at that name. No dice. > > - Ask the maintainer of somehost.example to install an appropriate CAA >> record >> > > If you'll review the message two or three back at in this thread, you'll > note that there are cases where somehost.example has 400,000 names CNAMEd > to it. No dice. > > Waving this problem away is not helpful. > =E2=80=8BHence the proposal for _prefix.=E2=80=8Bwww.mydom.example CAA ... --001a11394aa263eb7f055aec040a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Oc= t 6, 2017 at 6:25 PM, John R Levine <johnl@taugh.com> wrote:
=
mydom.example.=C2=A0 CAA issue "nope"=C2=A0=C2=A0 ; no web server= here
www.mydom.example. CNAME somehost.example. ; web server here

Where does the CAA go?
Three options:

=C2=A0- Remove the record on mydom.example

 I don't want a web server at all that name.=C2=A0 No dice.

=C2=A0- Adjust the record for mydom.example to allow issuance by preferred = CAs

 I still don't want a web server at that name.=C2=A0 No dice.

=C2=A0- Ask the maintainer of somehost.example to install an appropriate CA= A
record

 If you'll review the message two or three back at in this thread, you&#= 39;ll note that there are cases where somehost.example has 400,000 names CN= AMEd to it.=C2=A0 No dice.

Waving this problem away is not helpful.


=E2=80= =8BHence the proposal for=C2=A0

_prefix.=E2=80=8Bwww.mydom.example CAA ...

--001a11394aa263eb7f055aec040a-- From nobody Fri Oct 6 20:17:51 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E917213219C for ; Fri, 6 Oct 2017 20:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 oXZP_y1yq54C for ; Fri, 6 Oct 2017 20:17:47 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 BADD313219B for ; Fri, 6 Oct 2017 20:17:47 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id j126so32397273oia.10 for ; Fri, 06 Oct 2017 20:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XaiMd15xmrkajaX2h7KByAy3AkgW4lgQ493eZDby9BA=; b=WFe5qYTwMpulK58TUFbusukBYGycJJH14bO5vFsSM00SwEf03YYijN8vIruvVE1W1l tZIAUxWCW+h3/NfbQPsStpeludfvEMtXS50rf5sm7AOh5PLgekzCP4OVZZAGY4G4mKii +JNyxhV8Id5MbNyBV5asYVCvez0zW8ArH7GQS0xiSsj0P0BIc4YbMsxSwRoyRRgb6OtH +0YLAiyw786s0cVuFfuJEB9UadCa5i0NhOfJykeg9krtpx20ITgzMrELPh9aGCsrf9p2 PUdJQmWBh5KjjxzKuwaZE9RhAEYTlUHPR5ZGAF9VBsWvtzM/2hdTzVqNwNx+RoBHVVVs bYlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XaiMd15xmrkajaX2h7KByAy3AkgW4lgQ493eZDby9BA=; b=t1v843HAweJHGj6p/f380+dBuP+55MJ3SAatL9SLrHaQQdpNgEQ5ati5NFKUUt8LUI p7wGRnUI23+Wa29s9O/NAgHZNdSlo5buFSUPcymXdXujKsLsmIng/OtXVr91FqGFkdoI dXiNBbrMO+/9hu9ijwvbT/B3MboIzm2bklNqwGStVnuYJY/uMErTaJXgwzIqPjfTaiN5 n0eONX/EW517OepDNByP5izclCn2/c0YoyYRUC1xsyzf55UoBX/YoLQ3pT2XBMEKXF69 CimLanebyq1skuxi5e+h3eV7W18XmWSrXwdoFlH74u8nyfxWLTJpeej6+dRguW/Hxce2 Mm/Q== X-Gm-Message-State: AMCzsaX2Jw50Z1SgWElLbwr4FPI0/pMKwNe9vFSE9ch+fwvGfbl3dhNx OcGxx1sSFEnGTUrNtufzofRK5VKSvlf2S76P6T8= X-Google-Smtp-Source: AOwi7QAeV+6fEWl1q39KYKLE9qEuO7eLRobfKmezT0A+ecgQzhNDBmR4D0bMkLVccS5/dD61giR25xvECQyUdVK2xSM= X-Received: by 10.202.195.212 with SMTP id t203mr2136230oif.279.1507346267098; Fri, 06 Oct 2017 20:17:47 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.95.12 with HTTP; Fri, 6 Oct 2017 20:17:46 -0700 (PDT) In-Reply-To: References: <7b98f765-4fea-5b71-e860-e46c11d6617e@eff.org> From: Phillip Hallam-Baker Date: Fri, 6 Oct 2017 23:17:46 -0400 X-Google-Sender-Auth: 2KIbXNi1yzalX_j8B_gnw36AVVs Message-ID: To: John R Levine Cc: SPASM Content-Type: multipart/alternative; boundary="001a1134fdeacdd2fd055aec6655" Archived-At: Subject: Re: [lamps] CAA tree climbing, gurrghhg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 03:17:50 -0000 --001a1134fdeacdd2fd055aec6655 Content-Type: text/plain; charset="UTF-8" There is an interesting difference with this spec. If the spec goes through IETF process and becomes an RFC and the folk in CABForum vote to do so, this goes into production as a compliance requirement. One side effect of that is that there cannot be any loose ends. PSL is a loose end. We debated the dbound problem at great length and then decided that it doesn't matter. There are really only a few TLDs of any consequence and if they did something silly, we can vote to unsilly as a special case. And since they know that, it is unlikely folk will be silly. Yes, VeriSign could put a CAA record in .com but I bet they won't because even if they go mad and do, we can pass a CABForum rule with a special exception. On Fri, Oct 6, 2017 at 6:27 PM, John R Levine wrote: > I see that the current draft says that CAs climb up the tree a label at a > time all the way to the TLD, looking for a CAA policy record. > > I think you will find a great deal of resistance to that design, because > it runs into the dbound problem. If I register fobar.hockey, I do not want > the .hockey TLD setting my default certificate policy. > > DMARC has a similar problem looking for policy records for mail > authentication. If there's no _dmarc record for a particular domain, > implementations find the related "organizational domain", roughly the > highest name under the same management, and it looks for a _dmarc record > for the organizational domain. Current implementations use the mozilla PSL > or something similar; if we were able to converge in something in dbound or > its reincarnation, they'd use that instead. > > I cheefully agree that the PSL is awful, but as far as I can tell all of > the alternatives are worse. > > R's, > John > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --001a1134fdeacdd2fd055aec6655 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The= re is an interesting difference with this spec. If the spec goes through IE= TF process and becomes an RFC and the folk in CABForum vote to do so, this = goes into production as a compliance requirement.

One side effect of that is that there cannot be an= y loose ends. PSL is a loose end.

We debated the dbound problem at great length and then decided t= hat it doesn't matter. There are really only a few TLDs of any conseque= nce and if they did something silly, we can vote to unsilly as a special ca= se. And since they know that, it is unlikely folk will be silly.

Yes, VeriSign could put a CAA recor= d in .com but I bet they won't because even if they go mad and do, we c= an pass a CABForum rule with a special exception.



On Fri, Oct 6, 2017 at 6:27 PM, John R Levine <johnl= @taugh.com> wrote:
I see th= at the current draft says that CAs climb up the tree a label at a time all = the way to the TLD, looking for a CAA policy record.

I think you will find a great deal of resistance to that design, because it= runs into the dbound problem. If I register fobar.hockey, I do not want th= e .hockey TLD setting my default certificate policy.

DMARC has a similar problem looking for policy records for mail authenticat= ion.=C2=A0 If there's no _dmarc record for a particular domain, impleme= ntations find the related "organizational domain", roughly the hi= ghest name under the same management, and it looks for a _dmarc record for = the organizational domain.=C2=A0 Current implementations use the mozilla PS= L or something similar; if we were able to converge in something in dbound = or its reincarnation, they'd use that instead.

I cheefully agree that the PSL is awful, but as far as I can tell all of th= e alternatives are worse.

R's,
John

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

--001a1134fdeacdd2fd055aec6655-- From nobody Sat Oct 7 08:09:09 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C681329F9 for ; Sat, 7 Oct 2017 08:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=FshXWYLt; dkim=pass (1536-bit key) header.d=taugh.com header.b=WOv6/NkB 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 k1YQnsc1eCrl for ; Sat, 7 Oct 2017 08:09:07 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 D8C39132355 for ; Sat, 7 Oct 2017 08:09:06 -0700 (PDT) Received: (qmail 61609 invoked from network); 7 Oct 2017 15:09:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=f0a7.59d8ee11.k1710; bh=9xkGUa85DNGqUU7lFI2WGNsOmtV6Q4JoK4jXL7Mxy/E=; b=FshXWYLt00i5Au1UQXH+1b7Hs9eevHcvDS2G1x3a6oVtNvU9ewmQMyFw/cwl3UJ48tB+kAQkl6iigdRrBLLPiikNeYsWb0Hprz5U4JnGIsjhULnyOxZ5q5kt3Iw3TqIvx80QZkMtWHs4Gft4L40EFnTXxmYPKe1WLINhqCe/9/WhigSYsjANFNkSB0AK2c/SJVW0g2R6yaVLwlfRNlvAVO8jMr1+W/kbYLt7BJYk7YNs2C/DTquPAq9fFz3yzcMO DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=f0a7.59d8ee11.k1710; bh=9xkGUa85DNGqUU7lFI2WGNsOmtV6Q4JoK4jXL7Mxy/E=; b=WOv6/NkB2W9y9AfZtm/BdQwfsCT6UIEwJJg8SrM+iVCHESSwaFByf8FnNdj4KXRjpuG9aYyriqxJG0T0cL8En3qqhIvUeGp9nvY+oyt4KveigbQsxIIWpGXU2wanaKmklI//QOjikJypYdlKPDOKsFubhVxOOsA9NtybXH5ASIfjrPntZxL+bc51XlT3LMMHDvzLhnEJb0y24fUm/wTREFa1Ois1LNuNGBmOFsdNy2zg89NiexLufasnGjr4JgGQ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 07 Oct 2017 15:09:05 -0000 Date: 7 Oct 2017 11:09:04 -0400 Message-ID: From: "John R Levine" To: "Phillip Hallam-Baker" Cc: "SPASM" In-Reply-To: References: <7b98f765-4fea-5b71-e860-e46c11d6617e@eff.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [lamps] CAA tree climbing, gurrghhg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 15:09:08 -0000 > One side effect of that is that there cannot be any loose ends. PSL is a > loose end. Perhaps, but CAs already use it a zillion times a minute to decide what certs to issue. > We debated the dbound problem at great length and then decided that it > doesn't matter. There are really only a few TLDs of any consequence and if > they did something silly, we can vote to unsilly as a special case. And > since they know that, it is unlikely folk will be silly. It would not be silly for Verisign to put a CAA at com. saying it has no certs at all. But it would be extremely silly for CAs to apply that CAA to 2LDs or 3LDs under .com. Or are you saying that CAAs only work in "real" TLDs? If so it would be useful to have a list. R's, John From nobody Sat Oct 7 09:24:48 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482A3134CC5 for ; Sat, 7 Oct 2017 09:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 yIOt9K2BRdhR for ; Sat, 7 Oct 2017 09:24:44 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1397A134CC4 for ; Sat, 7 Oct 2017 09:24:44 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 3B15B20047602 for ; Sat, 7 Oct 2017 09:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=9m6cmJLjrSPUNiKrguephoUTur8=; b= mVnsI9shGnuo41yBlSflV9PRRh/I8fHLI+i5nH1G+MTqTsCUtok1pxEcntLb9adi 0Ts+EkZ7MmQ8OkLzmx+ffj9MgNdL8lUKexNsd7YVWjKxOuNJwMncYQtTGk08ZwoD W29iH6XqlbgdKJOjFuzOR3Tghla2UvMupUsxkJo1prY= Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPSA id 12ADD20047600 for ; Sat, 7 Oct 2017 09:24:43 -0700 (PDT) Received: by mail-io0-f170.google.com with SMTP id z187so18343221ioz.12 for ; Sat, 07 Oct 2017 09:24:43 -0700 (PDT) X-Gm-Message-State: AMCzsaWR6w65zr+nz2bNqsH7167SjpVaj06fxadP5vGaUwiD1LxVp169 ZzRq4hWUnZJXkXSi69+b5nd9IhMzwfo6wfBpUkA= X-Google-Smtp-Source: AOwi7QDt4AKBPQvBB7DJ0lUvTz0pWC5eeO3gh3Cv+7T/9TLi2spx3XZUwWSaLlZZ98q+x1B/miTbV+qjYndxHyFpLtA= X-Received: by 10.107.38.202 with SMTP id m193mr7258998iom.98.1507393482288; Sat, 07 Oct 2017 09:24:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.176.220 with HTTP; Sat, 7 Oct 2017 09:24:41 -0700 (PDT) In-Reply-To: References: <7b98f765-4fea-5b71-e860-e46c11d6617e@eff.org> From: Ryan Sleevi Date: Sat, 7 Oct 2017 12:24:41 -0400 X-Gmail-Original-Message-ID: Message-ID: To: John R Levine Cc: Phillip Hallam-Baker , SPASM Content-Type: multipart/alternative; boundary="001a114075100c74e8055af765fe" Archived-At: Subject: Re: [lamps] CAA tree climbing, gurrghhg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 16:24:46 -0000 --001a114075100c74e8055af765fe Content-Type: text/plain; charset="UTF-8" On Sat, Oct 7, 2017 at 11:09 AM, John R Levine wrote: > One side effect of that is that there cannot be any loose ends. PSL is a >> loose end. >> > > Perhaps, but CAs already use it a zillion times a minute to decide what > certs to issue. > > We debated the dbound problem at great length and then decided that it >> doesn't matter. There are really only a few TLDs of any consequence and if >> they did something silly, we can vote to unsilly as a special case. And >> since they know that, it is unlikely folk will be silly. >> > > It would not be silly for Verisign to put a CAA at com. saying it has no > certs at all. But it would be extremely silly for CAs to apply that CAA to > 2LDs or 3LDs under .com. > I don't think that's the same meaning. I think, especially in the world of gTLDs, it's both reasonable and sensible to allow CAA records at the TLD, and there's no need for the public suffix list concerns. At best, such problems are business problems - not technology problems. --001a114075100c74e8055af765fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Oct 7, 2017 at 11:09 AM, John R Levine <johnl@taugh.com><= /span> wrote:
One side effect of that is that there cannot be any loose ends. PSL is a loose end.

 Perhaps, but CAs already use it a zillion times a minute to decide what cer= ts to issue.

We debated the dbound problem at great length and then decided that it
doesn't matter. There are really only a few TLDs of any consequence and= if
they did something silly, we can vote to unsilly as a special case. And
since they know that, it is unlikely folk will be silly.

 It would not be silly for Verisign to put a CAA at com. saying it has no ce= rts at all.=C2=A0 But it would be extremely silly for CAs to apply that CAA= to 2LDs or 3LDs under .com.

I don'= t think that's the same meaning. I think, especially in the world of gT= LDs, it's both reasonable and sensible to allow CAA records at the TLD,= and there's no need for the public suffix list concerns. At best, such= problems are business problems - not technology problems.
--001a114075100c74e8055af765fe-- From nobody Sat Oct 7 09:33:45 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEA9134CE1 for ; Sat, 7 Oct 2017 09:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=EAXTF5e8; dkim=pass (1536-bit key) header.d=taugh.com header.b=QZ1XoumN 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 BWkvmV-f4eXg for ; Sat, 7 Oct 2017 09:33:41 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 6145F134CE3 for ; Sat, 7 Oct 2017 09:33:41 -0700 (PDT) Received: (qmail 77762 invoked from network); 7 Oct 2017 16:33:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=12fc0.59d901e4.k1710; bh=+H+TD5ZRnxInl/wDHfIxCx/SaXK5SNQwtJgC031x/Js=; b=EAXTF5e8Bdtl2ksfvYmz+5dp3vqvzx6G6wL2q8fdGA/BFDk0dQiToBqeUfk9E2bo3gvIE4RdbEhNAOvlwzOr49TS1I0BPbnGKWb4vz+bOqz+e6YemxaBH5EA1UfEKM6tyuSBmD9yC5ziM3n4uR3O9lkyPktGkyXnBtwnaHOWeJthkAZpvKZBiueuXUMmCgA3NRWlBmLOzBPMLuVU0Zg6VGq3H9zd/kreLf9LF7xEwjYe2cYrp5nbwqle5Ojcdvng DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=12fc0.59d901e4.k1710; bh=+H+TD5ZRnxInl/wDHfIxCx/SaXK5SNQwtJgC031x/Js=; b=QZ1XoumNqOwCbrE7P29v0O0h7SRg5T/D0IcZY10+uu1fgqyvT5qlt/segT7dMr3UJA0pIc91PyGpwF3afawD0VjOaHTkJKq8zj28Fgo5sLlTevHpk0clSJLpYccv0SiALDOAd+vmIRP847hBMPDuzup1NuEtGIzMXdZF2kiqSwn7oABBznPLbrYTzTQWgP6WO8hNpT/2OmL5G/gZcUz/C4U11rYL+IRYkKjfCA/tniaQ7vzc4AYJR/haWY11rPlB Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 07 Oct 2017 16:33:40 -0000 Date: 7 Oct 2017 12:33:39 -0400 Message-ID: From: "John R Levine" To: "Ryan Sleevi" Cc: "SPASM" In-Reply-To: References: <7b98f765-4fea-5b71-e860-e46c11d6617e@eff.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [lamps] CAA tree climbing, gurrghhg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 16:33:43 -0000 On Sat, 7 Oct 2017, Ryan Sleevi wrote: > I don't think that's the same meaning. I think, especially in the world of > gTLDs, it's both reasonable and sensible to allow CAA records at the TLD, > and there's no need for the public suffix list concerns. At best, such > problems are business problems - not technology problems. I suppose there's some merit in that viewpoint. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Oct 7 10:30:39 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BE31331D2 for ; Sat, 7 Oct 2017 10:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 6PJccBxIpJzV for ; Sat, 7 Oct 2017 10:30:36 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003: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 442F4134A28 for ; Sat, 7 Oct 2017 10:30:36 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id v9so21823476oif.13 for ; Sat, 07 Oct 2017 10:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DBiO7iE0FdwDm/nD0mZ/8nkN8SYlW85TceqkDkP7xgs=; b=HVljZLx1A2HuMQErZvR92JCnV0D9vKBB20dgyym7KwpPZ2WMLxC3W8o8gOo7ZRLXoj 5+mbIbLnVVn3KsjI6xMjaCqDLu4Ide/U/nhCbxRjN0n1tx0+Abqxuj4HFCzBpv0APT2o KXtTbWSWSejlCRvtU5imROoDfvdIAdOkQ0M21yv6f8yWozJ3ozzBflODyVJeDAj7oNYy 31mF1lHcLlvnj6dXRKUR3MqzlRvOLRwINDxewtRqhLAEL5yA9mW2b9neBP1wrJsZpwoe vsQHjC6xQXUDWggk/V93AW+LAL9qj/RbVgueArUR7CZHMVpfoIxK8RY1dU0qnhoD2YOI dLRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DBiO7iE0FdwDm/nD0mZ/8nkN8SYlW85TceqkDkP7xgs=; b=PngK280vnbNiMbcHPNpt0izXtD0fPukDJAq0EcpMut8D2hEXanMrtd//EtDHWiZegJ 1q0H6FZ6xAdePX3vp5sjEwM9KpN8OnOQgzW8o/coUuYxQ+sZqjmv5BhvaZm2/fM33+SD QEER3letWR52X7qNmLDUUF/K/22PWF50s0nHrv3wZdcR0kD6Ur3miOmz9Brmp2tK2+hr GjknJEslmnN9uOQMuwtlrRryUwwW9fDrI/UsnSCAAGIeWUJQLasNVo4qBBsVud+jV5Ne Enujds+9o8D+alx0NHhp6JDCvcZ8DGZiGJ8V7bTX7SPvUQDL/ki+4kGvwzTKjstB+Lk/ fjkQ== X-Gm-Message-State: AMCzsaUvpZHU86Il1yUcVbAnHBw73130FN35uJv3cv1+R+qiDintGeFM lLpwRm6xyTz6b91KaR+/Bsl+pD1S+N/LYT4NGJc= X-Google-Smtp-Source: AOwi7QAmKe73h5baT0nhg7k6koem/1DqPk0f28FHSti8KkaunIXKdYsC0sDOdZw2wzwmq7i7BD3IXCOQkiHb/Ovw/PI= X-Received: by 10.202.195.212 with SMTP id t203mr3066818oif.279.1507397435540; Sat, 07 Oct 2017 10:30:35 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.95.12 with HTTP; Sat, 7 Oct 2017 10:30:34 -0700 (PDT) In-Reply-To: References: <7b98f765-4fea-5b71-e860-e46c11d6617e@eff.org> From: Phillip Hallam-Baker Date: Sat, 7 Oct 2017 13:30:34 -0400 X-Google-Sender-Auth: fAO3E82tRIFjZ7sOEwSNMjZhym0 Message-ID: To: Ryan Sleevi Cc: John R Levine , SPASM Content-Type: multipart/alternative; boundary="001a1134fdeaae4fa3055af85013" Archived-At: Subject: Re: [lamps] CAA tree climbing, gurrghhg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 17:30:38 -0000 --001a1134fdeaae4fa3055af85013 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 7, 2017 at 12:24 PM, Ryan Sleevi wrote: > > > On Sat, Oct 7, 2017 at 11:09 AM, John R Levine wrote: > >> One side effect of that is that there cannot be any loose ends. PSL is a >>> loose end. >>> >> >> Perhaps, but CAs already use it a zillion times a minute to decide what >> certs to issue. >> >> We debated the dbound problem at great length and then decided that it >>> doesn't matter. There are really only a few TLDs of any consequence and >>> if >>> they did something silly, we can vote to unsilly as a special case. And >>> since they know that, it is unlikely folk will be silly. >>> >> >> It would not be silly for Verisign to put a CAA at com. saying it has no >> certs at all. But it would be extremely silly for CAs to apply that CAA= to >> 2LDs or 3LDs under .com. >> > > I don't think that's the same meaning. I think, especially in the world o= f > gTLDs, it's both reasonable and sensible to allow CAA records at the TLD, > and there's no need for the public suffix list concerns. At best, such > problems are business problems - not technology problems. > =E2=80=8BMy original proposal was that CAs were required to state what thei= r CAA policy was. This could range from ignore completely to enforce exactly. I deliberately left that slack in the system because the alternative was to deal with all the implications of ICANN world in IETF. The stick there was that any CA that mis-issued was going to find themselves on a very sticky wicket if they had not checked CAA. Contrawise if the subject had not issued a CAA record then they would be at fault. The problem with that approach was that there is a network effect. There is little value in publishing CAA until it is checked and vice versa. Hence the need for CABForum to make it mandatory. Given that we have CT, we could have a scheme in which a CA may use any domain exclusion list provided that they publish it in a CT log first.=E2= =80=8B But that seems like something more in 'policy' space than 'technical'. --001a1134fdeaae4fa3055af85013 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Oc= t 7, 2017 at 12:24 PM, Ryan Sleevi <ryan-ietf@sleevi.com>= wrote:


On Sat, Oc= t 7, 2017 at 11:09 AM, John R Levine <johnl@taugh.com> wrote:<= br>
One side effect of that is that there cannot be any loose ends. PSL is a loose end.

 Perhaps, but CAs already use it a zillion times a minute to decide what cer= ts to issue.

We debated the dbound problem at great length and then decided that it
doesn't matter. There are really only a few TLDs of any consequence and= if
they did something silly, we can vote to unsilly as a special case. And
since they know that, it is unlikely folk will be silly.

 It would not be silly for Verisign to put a CAA at com. saying it has no ce= rts at all.=C2=A0 But it would be extremely silly for CAs to apply that CAA= to 2LDs or 3LDs under .com.

I d= on't think that's the same meaning. I think, especially in the worl= d of gTLDs, it's both reasonable and sensible to allow CAA records at t= he TLD, and there's no need for the public suffix list concerns. At bes= t, such problems are business problems - not technology problems.

=E2=80=8BMy original proposal was that = CAs were required to state what their CAA policy was. This could range from= ignore completely to enforce exactly. I deliberately left that slack in th= e system because the alternative was to deal with all the implications of I= CANN world in IETF.

The s= tick there was that any CA that mis-issued was going to find themselves on = a very sticky wicket if they had not checked CAA. Contrawise if the subject= had not issued a CAA record then they would be at fault.

The problem with that approach was that = there is a network effect. There is little value in publishing CAA until it= is checked and vice versa. Hence the need for CABForum to make it mandator= y.

Given that we have CT,= we could have a scheme in which a CA may use any domain exclusion list pro= vided that they publish it in a CT log first.=E2=80=8B But that seems like = something more in 'policy' space than 'technical'.
--001a1134fdeaae4fa3055af85013-- From nobody Sat Oct 7 11:33:54 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE92134B0F for ; Sat, 7 Oct 2017 11:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 0zwdRK_unesv for ; Sat, 7 Oct 2017 11:33:49 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 12B80134B0E for ; Sat, 7 Oct 2017 11:33:49 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id n61so8865800qte.10 for ; Sat, 07 Oct 2017 11:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ynjNu7SXtnyB9h+vv5BQ19B8bM88rPChMgSPfYDwc/8=; b=Tam+GtljtkWmHnpq+lYNWDtEBjtnc1uwlTK/Z7CNwvqyFER/G6kMJ5KuWoAm3eiZms Y7srGXfCJ26++nNTQNhWovg29Rtxa6vsaEAo73qd5F7H7pmVO3hnqL50uQgURocjpeGo qUvKxJDgnZ5mGFrr+soj75W8iy9+qMBvNN8olUgbh9ty288+WpWPfy731YZIe/iF2oPr SVfxtba+P9l2QhtD0GzwucNR3N81yaqQjLF40AiPyJbPVxh4lq9UEnzaF32GvP2XcVUr 31t4Y1jQqKvMVaqJVC47gLLeQtbtyXmD802fvLRr5k8B5kn9idRvVppW+e5wK9+OosFD /KlQ== 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=ynjNu7SXtnyB9h+vv5BQ19B8bM88rPChMgSPfYDwc/8=; b=R++AeAmpGuRzL/uSkAjRpkMtWQrwKcJLsIHjEWB9rlmJZLs/xqIDUDnIJjmw+Omtcm T7oy2lAcIboAgz0o5TDeWTCWJv4FSrTKIn6lO0lyeEnaYFr18iO/woTZF/O8+IDbKHKD +3hZaOzRmKnMVY5LlzbF4Ul4Ta3Hn7b6x9WWI5xDCEEQzzAZHW8IeiAZKqr1lFJA8mpV j4A53aSm/xwJPK06q+EvWCfXs1N01a4UCOSUoM0ypjTeuVMWBZzzs22bfccHxKzYuEsf KaVjGTECivhIQBQo1QV4SVsB4GlGC4EQgt67LeuDSVEjVjpP/HwqV4Tuz08aKlJVCNbO hxig== X-Gm-Message-State: AMCzsaXP3k85DwXecTiNP/RNQgUsXgwMrwAtM9jQ5QW37ZKM3cw7uzYt LDnhEiIvVlr3TwfubBn5sJ1+3mRxNbY73SWzDwIsuNJo X-Google-Smtp-Source: AOwi7QAYdGXL3WHwdI9SHO1i5f4wiZd07s79e4BbM5WRBQfZDaYJp3LJ3c1YyitnQRyyQANc0WOETys1kTLHvnAf//U= X-Received: by 10.37.105.203 with SMTP id e194mr4693557ybc.71.1507401227900; Sat, 07 Oct 2017 11:33:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sat, 7 Oct 2017 11:33:07 -0700 (PDT) From: Eric Rescorla Date: Sat, 7 Oct 2017 11:33:07 -0700 Message-ID: To: SPASM , draft-ietf-lamps-rfc5750-bis@ietf.org Content-Type: multipart/alternative; boundary="94eb2c14ebc8b92bdc055af9325e" Archived-At: Subject: [lamps] AD Review of draft-ietf-lamps-rfc5751-bis-06.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 18:33:53 -0000 --94eb2c14ebc8b92bdc055af9325e Content-Type: text/plain; charset="UTF-8" See https://mozphab-ietf.devsvcdev.mozaws.net/D8 for a more full-featured version of this review. This document appears to be in generally good shape. I have marked a number of issues below. Please spell check this document. I found a rather large number of typos. *INLINE COMMENTS* View Inline draft-ietf-lamps-rfc5751-bis.txt:230 Certificate: A type that binds an entity's name to a public key with a digital signature. Nit: I'm not sure "type" is the cleanest word here. I suppose this comes from ASN.1 but it's really more like a message or a credential View Inline draft-ietf-lamps-rfc5751-bis.txt:263 Data Integrity Service: A security service that protects againist unauthorized changes to data by ensuring that Typo: against View Inline draft-ietf-lamps-rfc5751-bis.txt:267 Data Confidentiality: The property that data is not discolsed to system entities unless they have been authorized Typo: disclosed View Inline draft-ietf-lamps-rfc5751-bis.txt:272 Data Origination: The corroboration that the source of the data received is as claimed. [RFC4949]. This phrase does not seem to appear in the document, and this is an odd definition. View Inline draft-ietf-lamps-rfc5751-bis.txt:305 S/MIME version 4.0 agents ought to attempt to have the greatest interoperability possible with agents for prior versions of S/MIME. Should "ought to" be SHOULD View Inline draft-ietf-lamps-rfc5751-bis.txt:390 Section 3.4.3.2: Replace micalg parameter for SHA-1 with sha-1. This might be easier to read with quotes. View Inline draft-ietf-lamps-rfc5751-bis.txt:466 - MUST- support RSA with SHA-256. I think it would be clearest when you have RSA PKCS#1 1.5 next to PSS if you clearly stated 1.5. I think it's fine elsewhere. View Inline draft-ietf-lamps-rfc5751-bis.txt:482 - MUST NOT support EdDSA using the pre-hash mode. Can you explain why you are prohibiting this mode? I'm not endorsing it, but I don't see a prohibition on (for instance) secp256k1 though that's presumably also inadvisable. View Inline draft-ietf-lamps-rfc5751-bis.txt:488 section of the community which believes that there might be a backdoor to these curves. The EdDSA curves were, in part, created in response to this feeling. However, there are still significant This seems like it's kind of controversial for no good reason. These curves are more modern, faster, and were standardized in IETF. Isn't that a good enough reason? View Inline draft-ietf-lamps-rfc5751-bis.txt:491 sections of the industry which need to have NIST approved algorithms. For this reason, both sets of curves are represented in the recieving agent list, but there is only a requirement for curve in the sending Typo: receiving View Inline draft-ietf-lamps-rfc5751-bis.txt:495 See Section 4.1 for information on key size and algorithm references. It might be worth noting that these requirements are intended to guarantee that any pair of sender and receiver can interoperate. View Inline draft-ietf-lamps-rfc5751-bis.txt:518 with AES-128 content encryption algorithm). As both 128 and 256 bit AES modes are mandatory-to-implment as content encryption algorithms (Section 2.7), both the AES-128 and AES-256 key wrap algorithms MUST Typo: implement. View Inline draft-ietf-lamps-rfc5751-bis.txt:546 2.4.2. SignedData Content Type Note to self: order of signature and encryption View Inline draft-ietf-lamps-rfc5751-bis.txt:640 implies that the sender can deal with the algorithm as well as undertanding the ASN.1 structures associated with that algorithm. There are also several identifiers that indicate support for other Typo: understanding. View Inline draft-ietf-lamps-rfc5751-bis.txt:649 If present, the SMIMECapabilities attribute MUST be a SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines SignedAttributes as a SET OF Attribute. The SignedAttributes in a IMPORTANT: there are a number of conformance requirements here. You need to specify how one should behave if you receive a misformatted message. View Inline draft-ietf-lamps-rfc5751-bis.txt:653 SMIMECapabilities attribute. CMS defines the ASN.1 syntax for Attribute to include attrValues SET OF AttributeValue. A SMIMECapabilities attribute MUST only include a single instance of This seems ungrammatical. Perhaps "as a SET OF" View Inline draft-ietf-lamps-rfc5751-bis.txt:656 AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue. How should I behave in this case as well? View Inline draft-ietf-lamps-rfc5751-bis.txt:671 matches. For instance, the DER-encoding for the SMIMECapability for AES-128 CBC MUST be identically encoded regardless of the implementation. Because of the requirement for identical encoding, Is this a normative reference or a statement of fact? View Inline draft-ietf-lamps-rfc5751-bis.txt:717 signerInfo MUST NOT include multiple instances of the SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 syntax for Attribute to include attrValues SET OF AttributeValue. A It would be clearer if here and above you said "Although CMS defines... the SignedAttributes ... MUST NOT include multiple" to make clear you are narrowing the CMS rules. View Inline draft-ietf-lamps-rfc5751-bis.txt:745 In order to determine the key management certificate to be used when sending a future CMS EnvelopedData message for a particular "key management" seems like an unclear name. Perhaps "encryption key" to match 2.5.3? View Inline draft-ietf-lamps-rfc5751-bis.txt:758 the same subject name as the signer of a X.509 certificate that can be used for key management. IMPORTANT: Does this certificate itself have to be valid? View Inline draft-ietf-lamps-rfc5751-bis.txt:863 agent chooses not to use AES-256 GCM in this step, it SHOULD use AES-128 CBC. Why not AES-128 GCM, as that is also a MUST. View Inline draft-ietf-lamps-rfc5751-bis.txt:965 fields. It is up to the receiving client to decide how to present this "inner" header along with the unprotected "outer" header. IMPORTANT: I think some guidance here is probably needed, at least to explain that if you intermix them it causes confusion. We have seen plenty of issues here. View Inline draft-ietf-lamps-rfc5751-bis.txt:1013 S/MIME implementations SHOULD however use transfer encoding described in Section 3.1.3 for all MIME entities they secure. The reason for securing only 7-bit MIME entities, even for enveloped data that are This seems to conflict with the next paragraph. Maybe "In general" here and "In the case where" in front of the next would help it read better. View Inline draft-ietf-lamps-rfc5751-bis.txt:1029 (such as base64) would unnecessarily expand the message size. Implementations MAY "know" that recipient implementations are capable of handling inner binary MIME entities either by interpreting the id- If you change "know" to "determine" here you can lose the scare quotes. View Inline draft-ietf-lamps-rfc5751-bis.txt:1072 multipart/signed message with 8-bit or binary data in the first part, it would have to return the message to the sender as undeliverable. Nit: "encounters" and "would have to" disagree. I believe you want "encountered" View Inline draft-ietf-lamps-rfc5751-bis.txt:1208 assigned, then this can be omitted. Thus, since "certs-only" can only be signed, "signed-" is omitted. Isn't it "verification" and "decryption" which are applied? View Inline draft-ietf-lamps-rfc5751-bis.txt:1232 possible to replace ciphertext in such a way that the processed message will still be valid, but the meaning can be altered. IMPORTANT: this is not correct if an AEAD algorithm is used. I'm just getting into this, but it appears that you have the following choices: - EnvelopedData with an encryption algorithm - EnvelopedData with an AEAD algorithm - AuthEnvelopedData with an encryption algorithm and a MAC - AuthEnvelopedData with an AEAD algorithm The second and fourth of these seem to differ in whether you have authenticated attributes. Or is #2 prohibited? It wasn't entirely clear to me from 5083 and I haven't chased it yet. View Inline draft-ietf-lamps-rfc5751-bis.txt:1276 valid, but the meaning can be altered. However this is substantially more difficult than it is for an enveloped-only message as the Can you elaborate more on this attack? It seems like you could just swap in your own ciphertext, but that's like the same as just crafting a new message, right? View Inline draft-ietf-lamps-rfc5751-bis.txt:1589 it will not yield significant compression. Base64 encrypted data could very well benefit, however. Incidentally, this is not strictly true. Consider the case where you use AES-GCM to encrypt data which you know to itself be 7-bit clean. In that case you can easily obtain a 12.5% compression ratio by stripping the high bit and replacing it with zeros on decompression. For the more general case see: https://pdfs.semanticscholar.org/6072/b10c4ab2851047464fe4fff766693a 4184e6.pdf View Inline draft-ietf-lamps-rfc5751-bis.txt:1661 automatically generate a message to an intended recipient requesting that recipient's certificate in a signed return message. Receiving and sending agents SHOULD also provide a mechanism to allow a user to This is just like textually requesting it, right? Or is there an indicator for this? View Inline draft-ietf-lamps-rfc5751-bis.txt:1878 Using weak cryptography in S/MIME offers little actual security over sending plaintext. However, other features of S/MIME, such as the This seems inconsistent with the definition of "weak" as <= 112 bits. That still offers significant security View Inline draft-ietf-lamps-rfc5751-bis.txt:1937 Many people assume that the use of an authenticated encryption algorithm is all that is needed to be in a situtation where the sender of the message will be authenticated. In almost all cases Typo: situation View Inline draft-ietf-lamps-rfc5751-bis.txt:1989 a concern need to provide some type of padding so that the length of the message does not provide this information. IMPORTANT: You also need to talk about compression oracles. View Inline draft-ietf-lamps-rfc5751-bis.txt:2343 Appendix A. ASN.1 Module Note: I did not review this on the premise that it was done so in 3851. View Inline draft-ietf-lamps-rfc5751-bis.txt:2456 statement on SHA-1 can be found in [RFC6194] but it is out-of-date relative to the most recient advances. Typo: recent. View Inline draft-ietf-lamps-rfc5751-bis.txt:2498 the binding of the public key to the identity that signed the message as well. You should note that because these weaknesses are recent (at least in the public sector) if you know you have had the message for a long time, it may be safer to accept it. View Inline draft-ietf-lamps-rfc5751-bis.txt:2517 some issues have been created that can cause interopatability problems: Typos: mandatory, interoperability View Inline draft-ietf-lamps-rfc5751-bis.txt:2565 to encrypt new emails. B.4. KeyEncryptionAlgorithmIdentifier Did you mean to use RFC 2119 normative language here? View Inline draft-ietf-lamps-rfc5751-bis.txt:2589 it is recommended that RFC 2311 [SMIMEv2] be moved to Historic status. Are you actually moving it, or just suggesting that the IESG do so? *REPOSITORY* rIETFREVIEW ietf-review *REVISION DETAIL* https://mozphab-ietf.devsvcdev.mozaws.net/D8 *EMAIL PREFERENCES* https://mozphab-ietf.devsvcdev.mozaws.net/settings/panel/emailpreferences/ *To: *ekr-moz, ekr --94eb2c14ebc8b92bdc055af9325e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

See=C2=A0https://mozphab-ietf.devs= vcdev.mozaws.net/D8 for a more full-featured version of this review.


This document appears to be in generally good shape. I have = marked a number of issues below.

Please spell check this document. I found a rather large number of typos= .


INLINE COMMENTS
View Inlinedraft-ietf-lamps-rfc5751-bis.txt:230
Certificate: A type that binds an entity's name to a pu= blic key
with a digital signature.

Nit: I'm not sure "type" is the cleanest word here. I= suppose this comes from ASN.1 but it's really more like a message or a= credential


View Inlinedraft-ietf-lamps-rfc5751-bis.txt:263=
Data Integrity Service: A security service that protects againis= t
unauthorized changes to data by ensuring t= hat

Typo: against


View Inlinedraft-ietf-lamps-rfc5751-bis.txt:= 267
Data Confidentiality: The property that data is not discolsed to
system entities unless they have been auth= orized

Typo: disclosed


View Inlinedraft-ietf-lamps-rfc5751-bis.tx= t:272
Data Origination: The corroboration that the source of the data
received is as claimed. [RFC4949].

This phrase does not seem to appear in the document, and this is an= odd definition.


View Inlinedraft-ietf-lamps-rfc5751-bis.txt:305
S/MIME version 4.0 agents ought to attempt to have the greatest
interoperability possible with agents for prior versions of S= /MIME.

Should "ought to" be SHOULD


View In= linedraft-ietf-lam= ps-rfc5751-bis.txt:390
Section 3.4.3.2:= Replace micalg parameter for SHA-1 with sha-1.

This might be easier to read with quotes.


<= a style=3D"float:right;text-decoration:none" href=3D"https://mozphab-ietf.d= evsvcdev.mozaws.net/D8#inline-271" rel=3D"noreferrer" target=3D"_blank">Vie= w Inlinedraft-ietf= -lamps-rfc5751-bis.txt:466
- MUST- support RSA with SHA-256.

I think it would be clearest when you have RSA PKCS#1 1.5 next to P= SS if you clearly stated 1.5. I think it's fine elsewhere.


<= div style=3D"padding:0px;background:rgb(247,247,247);border-color:rgb(227,2= 28,232);border-style:solid;border-width:0px 0px 1px;margin:0px">
View Inlinedraft-ietf-lamps-rfc5751-bis.txt:482
- MUST NOT support EdDSA using the pre-hash mode.

Can you explain why you are prohibiting this mode? I'm not endo= rsing it, but I don't see a prohibition on (for instance) secp256k1 tho= ugh that's presumably also inadvisable.


View In= linedraft-ietf-lam= ps-rfc5751-bis.txt:488
section of the community which believes that there might be a
backdoor to these curves. The EdDSA curves were, in part, cr= eated in
response to this feeling. However, there are still significa= nt

This seems like it's kind of controversial for no good reason. = These curves are more modern, faster, and were standardized in IETF. Isn= 9;t that a good enough reason?


View Inlinedraft-ietf-lamps-rfc5751= -bis.txt:491
sections of the industry which need to have NIST approved algorit= hms.
For this reason, both sets of curves are represented in the r= ecieving
agent list, but there is only a requirement for curve in the = sending

Typo: receiving


View Inlinedraft-ietf-lamps-rfc5751-bis.tx= t:495
See Section 4.1 for information on key size and algorithm referen= ces.

It might be worth noting that these requirements are intended to gu= arantee that any pair of sender and receiver can interoperate.


<= div style=3D"padding:0px;background:rgb(247,247,247);border-color:rgb(227,2= 28,232);border-style:solid;border-width:0px 0px 1px;margin:0px">
View Inlinedraft-ietf-lamps-rfc5751-bis.txt:518
with AES-128 content encryption algorithm). As both 128 and 256 = bit
AES modes are mandatory-to-implment as content encryption alg= orithms
(Section 2.7), both the AES-128 and AES-256 key wrap algorith= ms MUST

Typo: implement.


View Inlinedraft-ietf-lamps-rfc5751-bis= .txt:546
2.4.2. SignedData Content Type

Note to self: order of signature and encryption


=
View Inlinedraf= t-ietf-lamps-rfc5751-bis.txt:640
implies that the sender can deal with the algorithm as well as
undertanding the ASN.1 structures associated with that algori= thm.
There are also several identifiers that indicate support for = other

Typo: understanding.


View Inlinedraft-ietf-lamps-rfc5751-b= is.txt:649
If present, the SMIMECapabilities attribute MUST be a
SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS de= fines
SignedAttributes as a SET OF Attribute. The SignedAttributes= in a
IMPORTAN= T: there are a number of conformance requirements here. You need to = specify how one should behave if you receive a misformatted message.
<= /div>

View Inlinedraft-ietf-lamps-rfc5751-bis.txt:653
SMIMECapabilities attribute. CMS defines the ASN.1 syntax for
Attribute to include attrValues SET OF AttributeValue. A
SMIMECapabilities attribute MUST only include a single instan= ce of

This seems ungrammatical. Perhaps "as a SET OF"

=
View Inlinedraft-ietf-lamps-rfc5751-bis.txt:656
AttributeValue. There MUST NOT be zero or multiple instances of
AttributeValue present in the attrValues SET OF AttributeValu= e.

How should I behave in this case as well?


<= a style=3D"float:right;text-decoration:none" href=3D"https://mozphab-ietf.d= evsvcdev.mozaws.net/D8#inline-283" rel=3D"noreferrer" target=3D"_blank">Vie= w Inlinedraft-ietf= -lamps-rfc5751-bis.txt:671
matches. For instance, the DER-encoding for the SMIMECapability = for
AES-128 CBC MUST be identically encoded regardless of the
implementation. Because of the requirement for identical enc= oding,

Is this a normative reference or a statement of fact?


View Inlinedraft-ietf-lamps-rfc5751-bis.txt:717
signerInfo MUST NOT include multiple instances of the
SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.= 1 syntax
for Attribute to include attrValues SET OF AttributeValue. A

It would be clearer if here and above you said "Although CMS d= efines... the SignedAttributes ... MUST NOT include multiple" to make = clear you are narrowing the CMS rules.


"key management" seems like an unclear name. Perhaps &quo= t;encryption key" to match 2.5.3?
IMPORTAN= T: Does this certificate itself have to be valid?
<= br>
View Inlined= raft-ietf-lamps-rfc5751-bis.txt:863
agent chooses not to use AES-256 GCM in this step, it SHOULD use
AES-128 CBC.

Why not AES-128 GCM, as that is also a MUST.


View Inlinedraft-= ietf-lamps-rfc5751-bis.txt:965
fields. It is up to the receiving client to decide how to presen= t
this "inner" header along with the unprotected &quo= t;outer" header.
IMPORTAN= T: I think some guidance here is probably needed, at least to explai= n that if you intermix them it causes confusion. We have seen plenty of iss= ues here.

View Inlinedraft-ietf-lamps-rfc5751-bis.txt:1013
S/MIME implementations SHOULD however use transfer encoding descr= ibed
in Section 3.1.3 for all MIME entities they secure. The reas= on for
securing only 7-bit MIME entities, even for enveloped data th= at are

This seems to conflict with the next paragraph. Maybe "In gene= ral" here and "In the case where" in front of the next would= help it read better.


View Inlinedraft-ietf-lamps-rfc5751-bis.txt:= 1029
(such as base64) would unnecessarily expand the message size.
Implementations MAY "know" that recipient implement= ations are capable
of handling inner binary MIME entities either by interpreting= the id-

If you change "know" to "determine" here you ca= n lose the scare quotes.


View Inlinedraft-ietf-lamps-rfc5751-bis= .txt:1072
multipart/signed message with 8-bit or binary data in the first p= art,
it would have to return the message to the sender as undelive= rable.

Nit: "encounters" and "would have to" disagree.= I believe you want "encountered"


View In= linedraft-ietf-lam= ps-rfc5751-bis.txt:1208
assigned, then this can be omitted. Thus, since "certs-= only" can
only be signed, "signed-" is omitted.

Isn't it "verification" and "decryption" wh= ich are applied?


View Inlinedraft-ietf-lamps-rfc5751-bis.txt:1232<= /span>
possible to replace ciphertext in such a way that the processed
message will still be valid, but the meaning can be altered.
IMPORTAN= T: this is not correct if an AEAD algorithm is used.

I'm just getting into this, but it = appears that you have the following choices:

  • EnvelopedData wi= th an encryption algorithm
  • EnvelopedData wi= th an AEAD algorithm
  • AuthEnvelopedDat= a with an encryption algorithm and a MAC
  • AuthEnvelopedDat= a with an AEAD algorithm

The second and fourth of these seem to = differ in whether you have authenticated attributes.

Or is #2 prohibited? It wasn't enti= rely clear to me from 5083 and I haven't chased it yet.

=
View Inline= draft-ietf-lamps-rfc5751-bis.txt:1276
valid, but the meaning can be altered. However this is substanti= ally
more difficult than it is for an enveloped-only message as th= e

Can you elaborate more on this attack? It seems like you could just= swap in your own ciphertext, but that's like the same as just crafting= a new message, right?


View Inlinedraft-ietf-lamps-rfc5751-bis.txt= :1589
it will not yield significant compression. Base64 encrypted d= ata
could very well benefit, however.

Incidentally, this is not strictly true. Consider the case where yo= u use AES-GCM to encrypt data which you know to itself be 7-bit clean. In t= hat case you can easily obtain a 12.5% compression ratio by stripping the h= igh bit and replacing it with zeros on decompression. For the more general = case see: https://pdfs.semanticscholar.org= /6072/b10c4ab2851047464fe4fff766693a4184e6.pdf


View Inlinedraft-ietf-lamps-rfc5751-bis.txt:1661
automatically generate a message to an intended recipient request= ing
that recipient's certificate in a signed return message. = Receiving
and sending agents SHOULD also provide a mechanism to allow a= user to

This is just like textually requesting it, right? Or is there an in= dicator for this?


View Inlinedraft-ietf-lamps-rfc5751-bis.txt:1878=
Using weak cryptography in S/MIME offers little actual security o= ver
sending plaintext. However, other features of S/MIME, such a= s the

This seems inconsistent with the definition of "weak" as = <=3D 112 bits. That still offers significant security

View Inlinedra= ft-ietf-lamps-rfc5751-bis.txt:1937
Many people assume that the use of an authenticated encryption
algorithm is all that is needed to be in a situtation where t= he
sender of the message will be authenticated. In almost all c= ases

Typo: situation


View Inlinedraft-ietf-lamps-rfc5751-bis.tx= t:1989
a concern need to provide some type of padding so that the length= of
the message does not provide this information.
IMPORTAN= T: You also need to talk about compression oracles.

View Inlinedraft-ietf-lamps-rfc5751-bis.txt:2343
Appendix A. ASN.1 Module

Note: I did not review this on the premise that it was done so in 3= 851.


View Inlinedraft-ietf-lamps-rfc5751-bis.txt:2456
statement on SHA-1 can be found in [RFC6194] but it is out-of-= date
relative to the most recient advances.

Typo: recent.


View Inlinedraft-ietf-lamps-rfc5751-bis.txt:= 2498
the binding of the public key to the identity that signed the
message as well.

You should note that because these weaknesses are recent (at least = in the public sector) if you know you have had the message for a long time,= it may be safer to accept it.


View Inlinedraft-ietf-lamps-rfc5751= -bis.txt:2517
some issues have been created that can cause interopatability
problems:

Typos: mandatory, interoperability


View Inlin= edraft-ietf-lamps-= rfc5751-bis.txt:2565
to encrypt new emails.
B.4. KeyEncryptionAlgorithmIdentifier

Did you mean to use RFC 2119 normative language here?


View Inlinedraft-ietf-lamps-rfc5751-bis.txt:2589
it is recommended that RFC 2311 [SMIMEv2] be moved to Historic
status.

Are you actually moving it, or just suggesting that the IESG do so?=


REPOSITORY
rIETFREVIEW ietf-r= eview


--94eb2c14ebc8b92bdc055af9325e-- From nobody Sat Oct 7 11:37:21 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49498134B12; Sat, 7 Oct 2017 11:37:14 -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 uycmojqQWQUt; Sat, 7 Oct 2017 11:37:12 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79E01342F1; Sat, 7 Oct 2017 11:37:11 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id t69so13641053wmt.2; Sat, 07 Oct 2017 11:37: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=x94bjUdkXDMVmhfXlLTCu4egzpqJb5s7zTtFk52b1YQ=; b=EOZvUU42P0+tY8esykPQSAY9y2rj0TTpR9AOBLFXrBQZCvvFmEmNC9ZDIMCLDxYu/6 30YWiQfRZ+CH9JcVUQaFw1U6EIS4DOKjQCBXG8G9dsIlczbTysJLkHYMBIS7Aw3hjbau hb8+iPVySvPBL9WsFuCUauFPFlqR6lxCUvS5BBcoFXTyz1+fE0p4HddFk789SfaiyNyI +G6jz/oCg1LZslVSsLfxz05SAc2XpVJOocJAArGw7h6fkvDuUOhx0VKsy2CJNygcqAKA iqDC2NfyZfyamRu70UR4hn+DKK2KKPad6ONrv7KUAbfXeKQDjgLozhkgVCMuwN9l0RSB hlHQ== 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=x94bjUdkXDMVmhfXlLTCu4egzpqJb5s7zTtFk52b1YQ=; b=f/bGsEUDPhV/N5HdDC0FbN4jcYxpvFi5RORPD4iMmy1n3sYfyOrqSuHIRj9nmXxY+m Fx6WMp6Xhw0kA7+HuwCY6IZyYy5k2mbcwJpD0AshI3p/EO3RR0l5fzuo8PcmUGY4WlE2 UxasxuCcnLb3UdUc0V3GS72t38cQCRxbz15s1VIKT5/N7jonmRP9q6ZfuYS6xtSw0tCl MZ1oCrTUVXBVhocNJkNlO2tnrYeSi/PCDOLtuccDBl9AHfz4jYlGr4p49LyJzI582M6b NNXt6tpGxSVf8kWYhxW0cpGhxE/NAf0JQM/YwrqyUAL4AkGkBJ4E/mNgeQybDXtHWPL3 lZsQ== X-Gm-Message-State: AMCzsaXW9gbKkMO97fqfnys77BHwOBM7hCp6iTvvx9Xi6/KuLEEzVI9x FHZ6+JmAIsznx5Hk+0hJ69tzoZ+Nxjnijg3bryo= X-Google-Smtp-Source: AOwi7QBZLFVdLrLWMfNXYEf4+jrxj4diUUwLrBWsBOZWjHBcNTV7tFqxYWA5m6DkLp6JVlFxkRyWdaDFE3a8I25lnSk= X-Received: by 10.80.174.241 with SMTP id f46mr7882561edd.135.1507401430163; Sat, 07 Oct 2017 11:37:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.220.202 with HTTP; Sat, 7 Oct 2017 11:37:09 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Sat, 7 Oct 2017 21:37:09 +0300 Message-ID: To: Nikos Mavrogiannopoulos Cc: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: multipart/alternative; boundary="f403045c18e0c76566055af93e42" Archived-At: Subject: Re: [lamps] [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 18:37:14 -0000 --f403045c18e0c76566055af93e42 Content-Type: text/plain; charset="UTF-8" Dear Nicos, Sorry for the delay with my response. On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos wrote: > On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky > wrote: > > Dear Nikos > > > > On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos < > nmav@gnutls.org> > > wrote: > >> > >> > >> 4. How do you handle extensions to this format? > >> > >> Overall, why not use X.509 extensions to store such additional > >> constraints? We already (in the p11-kit trust store in Fedora/RHEL > >> systems) use the notion of stapled extensions to limit certificates > >> [0, 1] and seems quite a flexible approach. Have you considered that > >> path? > >> > >> regards, > >> Nikos > >> > >> [0]. > >> https://p11-glue.freedesktop.org/doc/storing-trust-policy/ > storing-trust-model.html > >> [1]. > >> http://nmav.gnutls.org/2016/06/restricting-scope-of-ca- > certificates.html > > I've looked through the specification. It's OK for me, but I do not get > > whether the attached extensions are crypto-protected. > > No, as these values are inserted by the administrator of the system, > or us (the distributor of the software), we didn't feel we needed the > introduction of additional PKI. > Well, the specification I suggest should allow applying CLPs issued by major vendors (Mozilla etc). For this purposes the CLPs should be validable => signed. > How do you see the infrastructure on the > draft-belyavskiy-certificate-limitation-policy? Who do you envision > signing these structures? (I assume that distribution of data will be > done by software distributors?) > I anticipate some ways to distribute CLPs. 1. Major vendor-issued CLPs are distributed either by vendors or by OS vendors (similar to, e.g., ca-certificates package in Debian). In this case we should have certificates to sign these CLPs distributed together with these bundles. 2. App-specific CLPs may include the key as a part of the application bundle. So CLP is distributed via normal app-distributing channel. 3. Locally created CLPs. This is the case more or less similar to the p11-glue solution, if I understand it correctly. Various protocols, such as TAMP (RFC 5934) can be used for transport the CLPs too. > > >> 4. How do you handle extensions to this format? > >> > > Simillary to CRL. Do you have ideas of the extensions? > > One problem with that is the fact that the existing CRL extensions are > about extending attributes of the CRL, rather than adding/removing > attributes to the certificate in question. > For this purposes I implied that the limitations are provided not by extensions, but as SEQUENCE of limitations related to the certificates. Was I wrong in the ASN1 scheme in the current version of my draft? > To bring the stapled extensions to your proposal, you'd need the > Extensions and Extension fields from RFC5280, and > add into limitedCertificates structure (I'll split it on the example > below for clarity) the following field. > > LimitedCertificates ::= SEQUENCE OF LimitedCertificate > > LimitedCertificate ::= SEQUENCE { > userCertificate CertificateSerialNumber, > certificateIssuer Name, > limitationDate Time, > limitationPropagation Enum, > fingerprint SEQUENCE { > fingerprintAlgorithm AlgorithmIdentifier, > fingerprintValue OCTET STRING > } OPTIONAL, > limitations SEQUENCE, > } OPTIONAL, > }; > > > stapledExtensions Extensions; <----- NEW > } > Sorry, I do not get the difference between the purposes of the field 'limitations' and 'stapledExtensions'. > Another difference between this profile and the p11-kit one, is that > the extensions/revocation here is done on the certificate, while in > p11-kit is done on the public key. Both approaches have pros and cons. > Sure. > > Another question. I also noticed the fingerprint field above. Is that > to distinguish between same CAs with different keys? In that case > using the SubjectPublicKeyIdentifier may be sufficient, and more > natural as this is how certificates with matching DNs/serials are > distinguished. > Do you mean Subject Key Identifier (RFC 5280, 4.2.1.2)? Yes, I agree and I'll update the draft. I introduced the fingerprint field to distinguish bogus certs from the valid ones, but I think the SKI will be OK for this purpose. Thank you! -- SY, Dmitry Belyavsky --f403045c18e0c76566055af93e42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Nicos,

Sorry for the delay with my= response.

On = Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos &l= t;nmav@gnutls.org&= gt; wrote:
On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky <beldmit@gmail.com> wrote:
> Dear Nikos
>
> On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos <nmav@gnutls.org>
> wrote:
>>
>>
>> 4. How do you handle extensions to this format?
>>
>> Overall, why not use X.509 extensions to store such additional
>> constraints? We already (in the p11-kit trust store in Fedora/RHEL=
>> systems) use the notion of stapled extensions to limit certificate= s
>> [0, 1] and seems quite a flexible approach. Have you considered th= at
>> path?
>>
>> regards,
>> Nikos
>>
>> [0].
>> https://p= 11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-mo= del.html
>> [1].
>> http://nmav.gnutls.= org/2016/06/restricting-scope-of-ca-certificates.html
> I've looked through the specification. It's OK for me, but I d= o not get
> whether the attached extensions are crypto-protected.

No, as these values are inserted by the administrator of the system,=
or us (the distributor of the software), we didn't feel we needed the introduction of additional PKI.

Well, t= he specification I suggest should allow applying CLPs issued by major vendo= rs (Mozilla etc).
For this purposes the CLPs should be validable = =3D> signed.



How do you see the infrastructure on the
draft-belyavskiy-certificate-limitation-policy? Who do you envision signing these structures? (I assume that distribution of data will be
done by software distributors?)

I antic= ipate some ways to distribute CLPs.

1. Major vendo= r-issued CLPs are distributed either by vendors or by OS vendors=C2=A0
(similar to, e.g., ca-certificates package in Debian). In this case w= e should have=C2=A0
certificates to sign these CLPs distributed t= ogether with these bundles.

2. App-specific CLPs m= ay include the key as a part of the application bundle.=C2=A0
So = CLP is distributed via normal app-distributing channel.

3. Locally created CLPs. This is the case more or less similar to the= p11-glue solution,
if I understand it correctly.

<= /div>
Various protocols, such as TAMP (RFC 5934) can be used for transp= ort the CLPs too.
=C2=A0

>> 4. How do you handle extensions to this format?
>>
> Simillary to CRL. Do you have ideas of t= he extensions?

One problem with that is the fact that the existing CRL extensions a= re
about extending attributes of the CRL, rather than adding/removing
attributes to the certificate in question.

<= div>For this purposes I implied that the limitations are provided not by ex= tensions,
but as SEQUENCE of limitations related to the certifica= tes.

Was I wrong in the ASN1 scheme in the current= version of my draft?



To bring the stapled extensions to your proposal, you'd need the
Extensions and Extension fields from RFC5280, and
add into limitedCertificates structure (I'll split it on the example below for clarity) the following field.

LimitedCertificates=C2=A0 ::=3D=C2=A0 =C2=A0SEQUENCE OF LimitedCertificate<= br>
LimitedCertificate ::=3D SEQUENCE {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 userCertificate=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CertificateSerialNumber,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 certificateIssuer= =C2=A0 =C2=A0 =C2=A0 =C2=A0Name,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 limitationDate=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Time,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 limitationPropagati= on=C2=A0 =C2=A0Enum,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fingerprint SEQUENC= E {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 finge= rprintAlgorithm AlgorithmIdentifier,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 finge= rprintValue=C2=A0 =C2=A0 =C2=A0OCTET STRING
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} OPTIONAL,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 limitations=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 SEQUENCE,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} OPTIONAL,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0};


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stapledExtensions E= xtensions; <----- NEW
}

Sorry, I do not get the difference be= tween the purposes of the field 'limitations'
and 'st= apledExtensions'.


Another difference between this profile and the p11-kit one, is that
the extensions/revocation here is done on the certificate, while in
p11-kit is done on the public key. Both approaches have pros and cons.
<= /blockquote>

Sure.
=C2=A0

Another question. I also noticed the fingerprint field above. Is that
to distinguish between same CAs with different keys? In that case
using the SubjectPublicKeyIdentifier may be sufficient, and more
natural as this is how certificates with matching DNs/serials are
distinguished.

Do you mean=C2=A0Subject= Key Identifier (RFC 5280, 4.2.1.2)?
Yes, I agree and I'll up= date the draft.

I introduced the fingerprint field= to distinguish bogus certs from the valid ones,
but I think the = SKI will be OK for this purpose.

Thank you!
<= /div>

--
SY, Dmitry Belyav= sky
--f403045c18e0c76566055af93e42-- From nobody Sat Oct 7 11:51:30 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510661321A2 for ; Sat, 7 Oct 2017 11:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 D3-Oo7XF-xk5 for ; Sat, 7 Oct 2017 11:51:27 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 F0AAE134B2B for ; Sat, 7 Oct 2017 11:51:26 -0700 (PDT) Received: (qmail 5201 invoked from network); 7 Oct 2017 18:51:25 -0000 Received: from unknown (64.57.183.53) by gal.iecc.com with QMQP; 7 Oct 2017 18:51:25 -0000 Date: 7 Oct 2017 18:51:03 -0000 Message-ID: <20171007185103.13239.qmail@ary.lan> From: "John Levine" To: spasm@ietf.org Cc: phill@hallambaker.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 18:51:28 -0000 In article you write: >​Hence the proposal for > >_prefix.​www.mydom.example CAA ... Right. I think that solves everything but the DNAME problem, and I think the DNAME problem, if it actually exists, is insoluble. R's, John From nobody Sat Oct 7 12:10:34 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A220E134B36 for ; Sat, 7 Oct 2017 12:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 3DBKvuEzTso1 for ; Sat, 7 Oct 2017 12:10:31 -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 CF65C134B33 for ; Sat, 7 Oct 2017 12:10:30 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id w197so29601336oif.6 for ; Sat, 07 Oct 2017 12:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hS0XmQtQEB7tz6dqcRk2RIVSZ0u9iXeNL5K+IYt2Fsc=; b=ZFEkvVBaw3xNq5BkMlIDZMAmcmMVEyN0O7Cmw5oHQR7LQlxR1uzPGVAfmw1Qlk7rSY RvMqdILsI/2fX1F4H5R0UJEnIrlYEUd/vQc0yhY8dbCwd2D+BoJL0pb0TDCWt7lFMf8O 8e446dn6n1/oyhjUrUB6TXthVSpXUD8dGzmMdKmN2GVHzsREMZ+u+ogCHpTCty2Y3/Kw dry8OierFfZtSj3fVq3KjJ3zM4BKIvIrUtd06HmXRGZy3pT0Lr4eHjUXhAVLW/skB1eC 110kVzozTR/xFlxsKphIXFSdwi3xyOjHYjTzCgLC+te2uMLeh/gzNjFVTASPJaQMVUHK OFbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hS0XmQtQEB7tz6dqcRk2RIVSZ0u9iXeNL5K+IYt2Fsc=; b=UCGTE4rJHTRYMs6S/uK84GMUL+9LYGzaRDMU5ze+rfxaREzj+AXoufzByJPVZj8lpr OMMxoOddNm8MHKG2Ds3DXayK1hIClAu2cqQriq6/qhHxn73HZIDjwEnHx79Ec52bOlZJ jAlv70ZDG6u6WNhxoVn0p5wCMLCjZpL66nNsWjxFOWBhDzYZL3Tda2P6xL3PFOLoN9Kz VoqT3u1MZbMwWxmPQ4BhKEnImTDdAev89ztWVhOvsoM8FK4xNJUW4l8eaoXBIp4p/9sw JGqrdzR+jkriZpbZjoq0oMeyv2KIYZ/C17MWP5qlaUrWmZz8TRlJ6wh++tWPgSXU9qND oGaQ== X-Gm-Message-State: AMCzsaURGslNu2AIxgIiC3wt/t6O8IG2rDOeciC/ALuq2vY7JETPOquD 5ZSwuu/PYaDmuNDd+HyXrP2WPp2eANCABi++dqs= X-Google-Smtp-Source: AOwi7QCujBuL86tLdsD686AddaIQ9sc+YdqBKyIfFY3/OruxzseVOMqQ2avb6g3LRuSo+6TFofesOOZc5Wa7HFp/agg= X-Received: by 10.202.195.212 with SMTP id t203mr3165113oif.279.1507403430127; Sat, 07 Oct 2017 12:10:30 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.95.12 with HTTP; Sat, 7 Oct 2017 12:10:29 -0700 (PDT) In-Reply-To: <20171007185103.13239.qmail@ary.lan> References: <20171007185103.13239.qmail@ary.lan> From: Phillip Hallam-Baker Date: Sat, 7 Oct 2017 15:10:29 -0400 X-Google-Sender-Auth: GYT3_6dOyJhELV-cSOJCVWbkZdM Message-ID: To: John Levine Cc: SPASM Content-Type: multipart/alternative; boundary="001a1134fdeafc6d96055af9b5d1" Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 19:10:32 -0000 --001a1134fdeafc6d96055af9b5d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 7, 2017 at 2:51 PM, John Levine wrote: > In article @mail.gmail.com> you write: > >=E2=80=8BHence the proposal for > > > >_prefix.=E2=80=8Bwww.mydom.example CAA ... > > Right. I think that solves everything but the DNAME problem, and I > think the DNAME problem, if it actually exists, is insoluble. > > R's, > John > =E2=80=8BI don't think there is a DNAME problem. DNAME is not a DNS RR, it is a DNSSEC RR. The only time it should be returned is when a synthetic CNAME is returned. DNAME is just like an NSEC3 record=E2=80=8B, it is not a record that carrie= s data or signature information directly. All it does is to provide a record that a signature can be attached to for a wildcarded CNAME. --001a1134fdeafc6d96055af9b5d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Oc= t 7, 2017 at 2:51 PM, John Levine <johnl@taugh.com> wrote:
=
In article <CAMm+Lwj3NkBnXy8_ERS+ZnRE3OhFrJi2WwaDeThiNimqm5Domg@mail.gmail= .com> you write:
>=E2=80=8BHence the proposal for
>
>_prefix.=E2=80=8Bwww.mydom.example CAA ...

Right.=C2=A0 I think that solves everything but the DNAME problem, a= nd I
think the DNAME problem, if it actually exists, is insoluble.

R's,
John

=E2=80=8BI don't think there is a D= NAME problem.
<= br>
DNAME is no= t a DNS RR, it is a DNSSEC RR. The only time it should be returned is when = a synthetic CNAME is returned.

DNAME is just like an NSEC3 record=E2=80=8B, it is not a record that = carries data or signature information directly. All it does is to provide a= record that a signature can be attached to for a wildcarded CNAME.

--001a1134fdeafc6d96055af9b5d1-- From nobody Sat Oct 7 13:13:41 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9117D1342F3 for ; Sat, 7 Oct 2017 13:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=BbFNYjX/; dkim=pass (1536-bit key) header.d=taugh.com header.b=QIk8YeDw 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 9d3EErUguA2R for ; Sat, 7 Oct 2017 13:13:37 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 AAAFA134B58 for ; Sat, 7 Oct 2017 13:13:37 -0700 (PDT) Received: (qmail 22737 invoked from network); 7 Oct 2017 20:13:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=58cf.59d93570.k1710; bh=1jpX1gS1jEH3pJjAKxRbWoVkeiGK4ebsfr/igWcxrJk=; b=BbFNYjX/193eNKUNmitWOYPAKO4ImVsdB1OSmfy5IV1hZe31s+wb6vFVn+wdGyDnW2bXPhD7Z7aL9o0++WQeGnsGkDKAqpwIeR76xFl+mRtWm9hKu1yLxBlwn8Nl9BvlmoAQQUXQREgljOnbVIjwDmClNGys0irU8Brox5SJu1cc/vkSZcgpliVwhF8+yrbGjvRzBap1Mp/y07qhLwolIRpzM22o6Hg88tlJVqSQvsm/Abs5ZTQmYMl5j0LABvNJ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=58cf.59d93570.k1710; bh=1jpX1gS1jEH3pJjAKxRbWoVkeiGK4ebsfr/igWcxrJk=; b=QIk8YeDw3+dh2A8gL7FbNn5SV97kI9Uy/tZWeLHZ3AG6CHJ2HO6rJlL4G0eZI5J5uH2UWsU3RWLckxrTpY4it9P9cUEc6S1lb6zDvBsNxzjA7Ouu/IJ5R+c8c7uPpDq+i6WAj9iyreljOZr8V5UaKtED1EjMn8L38mNCOOh0oIIkPocXE/Ay0CkVpB98rn6Pj5WKK+Faq31noC/L6agU2UQ28FdqJIyM7KEuLXth546WEzSAL7kXQhm8JxbDkOmL Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 07 Oct 2017 20:13:36 -0000 Date: 7 Oct 2017 16:13:35 -0400 Message-ID: From: "John R Levine" To: "Phillip Hallam-Baker" Cc: "SPASM" In-Reply-To: References: <20171007185103.13239.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1167435722-1507407216=:37220" Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 20:13:39 -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. --0-1167435722-1507407216=:37220 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 7 Oct 2017, Phillip Hallam-Baker wrote: >> Right. I think that solves everything but the DNAME problem, and I >> think the DNAME problem, if it actually exists, is insoluble. > ​I don't think there is a DNAME problem. Neither do I but for a completely different reason. The CNAME problem here is that you use a CNAME to point your web server at a third party host but you want to publish your own CAA, not the host's CAA. Hypothetically, you might want to do the same thing with DNAME, but every DNAME I've ever seen other than AS112 aliases two name trees where the corresponding names are (or at least are supposed to be) under the same control. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-1167435722-1507407216=:37220-- From nobody Sat Oct 7 13:25:58 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D76B132195 for ; Sat, 7 Oct 2017 13:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 joRnaYOpcNrB for ; Sat, 7 Oct 2017 13:25:56 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 EF19D13293A for ; Sat, 7 Oct 2017 13:25:55 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id c77so32314299oig.0 for ; Sat, 07 Oct 2017 13:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kKNgYKPosoNGS+3HdXwOfAASr/+Tv8/GVHGEnTL6y1U=; b=uPCryobKz5w5Ob1Y4qubibpwWjSYGB7s4CdKbDca+JjfnEDCVK2Dt8Ci+NFJjnnQna 1QHWJ+GrGEWNCbtscTC9m9h1J1FzyeZLfaHKnyrzke5Po9yUuD51Abrjbm2bDlKuC6SE 7fMSaV0eVQprWr9c9xXee/g1pVAGgX+1vX2KPShgKdjfteB6RlHGaU8btkEOXiz81G4a YkQJGoOVHmFLjKOL7+etTw18AcUzNckd5tO2bn+uTwa1texsQHPiqIzS8Mq5NIJFELh4 3RPdIjrnsHkwQzQjIB2IqJvz5d+JK4GIruDegs8hpTtgwDZYgAYKcvK+yLRDtIm+yvVE cuig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kKNgYKPosoNGS+3HdXwOfAASr/+Tv8/GVHGEnTL6y1U=; b=q8NqVhLLflDtQZ0fEgJT0xBbgvaJyV2EiXXCvtNpNxcWPWpJiK4eGm7cQjdemK2IvZ ChLJTo3pnxaTdICq65KkH8GmpCYsTBZqrVvXvQKfjPcr7WJBpBgTCvUGTBQojKl4CsC8 YBrusAzTVAkn/tig5YkZ6K7tak6EwLUk5Pnp9uAerVtrill/ql4vrVsKTZogVtYPwIew QodolVJpkBWgbnMIxL5T7fwxaL/hEAWp40ATCXNFTgqVDIMiDYeK/bmJ5HHYF34s7t1e MJhxTr/cGM9nUNXdupTESimZgXq0lXGHatr1ytLmOJsY5z4twhQLgNJ8L6W0nafLXqfi IxRQ== X-Gm-Message-State: AMCzsaVLUH0B4Gnlc3eBhH5llD9deWNdt7ObW0W8/I1Pks6NfKA2Xiz9 DbeIgjWJoXeabKiVGiToZe+fzCJF6ZSoGDxzACw= X-Google-Smtp-Source: AOwi7QBu8KJh+uoOcg3gpyob66H8YFycoVhhfGxxz6pYeMWvwU7T29Yu8VGjmmL4+84iBaGZRagIhczZyuL1C7mVEDk= X-Received: by 10.202.104.22 with SMTP id d22mr3330678oic.68.1507407955225; Sat, 07 Oct 2017 13:25:55 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.95.12 with HTTP; Sat, 7 Oct 2017 13:25:54 -0700 (PDT) In-Reply-To: References: <20171007185103.13239.qmail@ary.lan> From: Phillip Hallam-Baker Date: Sat, 7 Oct 2017 16:25:54 -0400 X-Google-Sender-Auth: yIBcv743ZpyJERaFqH_rGNn0W5s Message-ID: To: John R Levine Cc: SPASM Content-Type: multipart/alternative; boundary="001a1140f7b8b3f633055afac39f" Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 20:25:57 -0000 --001a1140f7b8b3f633055afac39f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 7, 2017 at 4:13 PM, John R Levine wrote: > On Sat, 7 Oct 2017, Phillip Hallam-Baker wrote: > >> Right. I think that solves everything but the DNAME problem, and I >>> think the DNAME problem, if it actually exists, is insoluble. >>> >> > =E2=80=8BI don't think there is a DNAME problem. >> > > Neither do I but for a completely different reason. > > The CNAME problem here is that you use a CNAME to point your web server a= t > a third party host but you want to publish your own CAA, not the host's C= AA. > > Hypothetically, you might want to do the same thing with DNAME, but every > DNAME I've ever seen other than AS112 aliases two name trees where the > corresponding names are (or at least are supposed to be) under the same > control. =E2=80=8BIf DNAME appeared on the wire, that would be a good reason to make= use of it. for that purpose. Unfortunately, the only time you can rely on it being published is when DNSSEC is in use. When CAA was originally written, CDNs were sufficiently rare that the main use of CNAME was also name equality under the same control. That has changed. --001a1140f7b8b3f633055afac39f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Oc= t 7, 2017 at 4:13 PM, John R Levine <johnl@taugh.com> wrote:
On Sat, 7 Oct 2017, Phill= ip Hallam-Baker wrote:
Right.=C2=A0 I think that solves everything but the DNAME problem, and I think the DNAME problem, if it actually exists, is insoluble.

=E2=80=8BI don't think there is a DNAME problem.

 Neither do I but for a completely different reason.

The CNAME problem here is that you use a CNAME to point your web server at = a third party host but you want to publish your own CAA, not the host's= CAA.

Hypothetically, you might want to do the same thing with DNAME, but every D= NAME I've ever seen other than AS112 aliases two name trees where the c= orresponding names are (or at least are supposed to be) under the same cont= rol.

=E2=80=8BIf DNAME appeared on the wire, that would be a go= od reason to make use of it. for that purpose. Unfortunately, the only time= you can rely on it being published is when DNSSEC is in use.

When CAA was originally written, CDNs = were sufficiently rare that the main use of CNAME was also name equality un= der the same control. That has changed.

=C2=A0
--001a1140f7b8b3f633055afac39f-- From nobody Sat Oct 7 13:40:00 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E8C134AC1 for ; Sat, 7 Oct 2017 13:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=k4Yc991C; dkim=pass (1536-bit key) header.d=taugh.com header.b=jxw5MDdb 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 sGI-m8aP18W5 for ; Sat, 7 Oct 2017 13:39:57 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 08795134326 for ; Sat, 7 Oct 2017 13:39:56 -0700 (PDT) Received: (qmail 27157 invoked from network); 7 Oct 2017 20:39:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6a13.59d93b9c.k1710; bh=BPCEFjGJE2EogJjnWpowpOmrND8w+6cPSYo4Iwmx4mI=; b=k4Yc991CmbcgnTdDwZjSwdmCDHgRDEUl25KkOgiAadkyFl3MpTUgAuPoyOXt7K3Qkgr8uuEJ43ewUtFojOsubUDfAMwK9D90bMq4100wV6Oqafi7FwNUM4IUcQXyIFVxb/slTrD94bfmfUQjK2seeNlLNBxH5K7jzxNNJ7UFBv9AYSaDsOPNcR006MvTtzc/FHugoQxtXpItApe4Kc2rQ0oZQWpIXGHp0LiScob+j8EoOl0DAHDLpRv/g2LqZOU5 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6a13.59d93b9c.k1710; bh=BPCEFjGJE2EogJjnWpowpOmrND8w+6cPSYo4Iwmx4mI=; b=jxw5MDdbMyqV+rxTz+N0wGfC8GwxnRqNhgp/yaf3WEMumD2IhE5KUy3yaao6wZ2dk1wnr6Xd1ZQQR+hIXYjxLjy6yVXEi4leB46/V09IigdwqIywMRd6BRnC3DBrQMf6xhlMsA8iJXGFg3d6SK8qa1NNH+aas5KssnI3u2gPhGQFOMf8V9/6Y9NUTi6NfnaBKe4Wz7ykx5dVvdrlF6eUiwUIfd+FVsZVe9OYKeDEGjWDmg6hsTnmTHLT5i5QGSVG Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 07 Oct 2017 20:39:55 -0000 Date: 7 Oct 2017 16:39:55 -0400 Message-ID: From: "John R Levine" To: "Phillip Hallam-Baker" Cc: "SPASM" In-Reply-To: References: <20171007185103.13239.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1725020819-1507408795=:37332" Archived-At: Subject: Re: [lamps] Next steps on CAA X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 20:39:58 -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. --0-1725020819-1507408795=:37332 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 7 Oct 2017, Phillip Hallam-Baker wrote: >>> Right. I think that solves everything but the DNAME problem, and I >>>> think the DNAME problem, if it actually exists, is insoluble. >>> >> ​I don't think there is a DNAME problem. > ​If DNAME appeared on the wire, t... > When CAA was originally written, CDNs were sufficiently rare that the main > use of CNAME was also name equality under the same control. That has > changed. Right about CNAMEs. The DNAME problem (if it exists) has nothing to do with whether the DNAME shows up in the DNS answer. It's whether it's important to be able to publish a CAA record that describes a policy for a DNAME'd web server, with the CAA not DNAME'd, just like the CNAME problem that prefixed names address. As I've said several times, although it's hypothetically possible, I doubt it's an issue in practice because other than the exotic AS112 I've never seen anyone use DNAME to point names at a third party. That's fortunate since the prefix hack doesn't help for DNAMEs. R's, John --0-1725020819-1507408795=:37332-- From nobody Sat Oct 7 20:31:35 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C26A13331E; Sat, 7 Oct 2017 20:31:22 -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 HEoUoE651Y-u; Sat, 7 Oct 2017 20:31:21 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 0B7E2133078; Sat, 7 Oct 2017 20:31:20 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id c82so20174030lfc.6; Sat, 07 Oct 2017 20:31:20 -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=Prd6OgF7t7YAi6BCUrTaOlcSYcyIAeTLoc4K4V2s8j4=; b=d4my61sYNBVlPOeMxkf+5RIyZgwT+SenU42iKIX7D1gHjHZFjYQ9QbPtdqbYqvdlJK BDbsD6rnVLMismMHxOGKkBxVWzlSuLJElKv+iS3c6saW68gOknjcFdzJByXaMCE9xfmr vv/e3jfJxVjyndkmbUn1/9zLibCFYafV4ELlO1+lrykKrVmFQ9XSSAd/uwklsLUoVi0a Z35N6GbkNVuix1qqcikOz1j/8YJigsbgn0zbw0VCGAFM2vYGO6T6WCdb78T5cG9jRkQV RIm0pNPi1WvNv+MuPLAMGknAJSiIMnAlCz5panmQ7V7R1C4L0KrwcH9HDFLg448MQM0d +dHA== 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=Prd6OgF7t7YAi6BCUrTaOlcSYcyIAeTLoc4K4V2s8j4=; b=iBX89SxVt7xHfOsdVYSF1u54w/n4Qp5ETvVTEpArRKIGQAitLyI9W/isAFZmYZQipz k5ENfKnvw9eC3DOcnYtEjiPXgqjjBu9FudubH1oEleJ08BjEo1OjwLmEC4AZGtIHys6M Y57N6v5LeM8+Q4E4vUsjtgkZS0P21gqNMOlrYNsMa6Aft111TQFgHrg577qDHDrS2E6O P9JkMgftyMPLz+yZqAhBBud65eVIsEw9V5FZonesJ70ELxa9t42vLRdr7IZmQc08ouSd 5KxKm3q3xZ1faDrQJ/Mo5/NBY0bSFHlGkXRsW1GsrEisNEC61M7vRaeAMXcf77axsqQS h4zg== X-Gm-Message-State: AMCzsaV5jHLfC2832mFSkaGl4RYaDze9kIivgXxTS5DttKgE3HPVNU0S LPJXyXYke+b4iCIVon4uwQ/oNYxRCoKmq5EsJr8= X-Google-Smtp-Source: AOwi7QAXUoA4L06mmq/nwvpTnFH+Ygyomp3o6mS2ux9w29TjL4W7W19ID59obXswesQhxHJXS6zq1S3rwvNxFbK9/P8= X-Received: by 10.25.143.156 with SMTP id s28mr2521530lfk.236.1507433478938; Sat, 07 Oct 2017 20:31:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.28.19 with HTTP; Sat, 7 Oct 2017 20:31:18 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Peter Bowen Date: Sat, 7 Oct 2017 20:31:18 -0700 Message-ID: To: Dmitry Belyavsky Cc: "saag@ietf.org" , LAMPS , "mozilla-dev-security-policy@lists.mozilla.org" , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 03:31:22 -0000 On Tue, Sep 12, 2017 at 5:59 AM, Dmitry Belyavsky via dev-security-policy wrote: > Here is the new version of the draft updated according to the discussion on > mozilla-dev-security list. Given that RFC 5914 already defines a TrustAnchorList and TrustAnchorInfo object and that the Trust Anchor List object is explicitly contemplated as being included in a signed CMS message, would it not make more sense to start from 5914 and define new extensions encode constraints not currently defined? Thanks, Peter From nobody Sun Oct 8 07:16:05 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B344F1342E0 for ; Sun, 8 Oct 2017 07:16:03 -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, FUZZY_CPILL=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=redhoundsoftware.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 Q-IEsOI8yf6f for ; Sun, 8 Oct 2017 07:16:02 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B1C134563 for ; Sun, 8 Oct 2017 07:16:02 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id n5so19356865qke.11 for ; Sun, 08 Oct 2017 07:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=hITRZf9hT6t0xdB4JdfHhLm8th9azff/CNVFokXBUJU=; b=J44fNxJnvKrUn0unURpamhOPuLFH83FExa0gTAYERixcweKmZdLib86G/jDUYD5QAa v1XQnJTXJ8591cdX0syPmey+edKEUTqnZJ82nwjRDgym5wsoxaCYM8neRkLr1llqarjM S5RV5UpGk99EbEkSctS8Dxz9vZ2ag9nQS1q2U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=hITRZf9hT6t0xdB4JdfHhLm8th9azff/CNVFokXBUJU=; b=GPmFHUoZ2gEMYmdDcXP0a1mb0UrWwYkHdLjR8ZlQRItghwloeXh3uuQ2x35/AY9KtE E7GNAmBa4FoJTo5gcmbOBAKKWdZmb5bcQpjANPER/MqeHo7H1US7S83xoBzCkKQzsSfU DcdpsIuQ8bW3Ie8XpNtv1bHvTew0E4PF/2omVwhXa329gQn1LYAcUNOwmsxXM4iN3zs+ 3xBufvQOWnwd4ZNKRihNMuaqOF/e/MDhxbHefQ9LbtdfolgvGcxvEKDyKSv2AHIkKXn4 jNoTSeOjivmmR092cGMuhZ262pB48ZTUEaZQJATDJrhKTJ1tW0AMGJhRNLYz0RMjGSED +Ddw== X-Gm-Message-State: AMCzsaULrk06LNmJhe2t4YWKPPltLeu5X1fLpfvj/EUPpK40bjUqpeSN 77v5DuZheNVHEampsISRAPOAgQ== X-Google-Smtp-Source: AOwi7QCta0ux/xhB3WHoo64t/jM1QOBHHQ4HNJiyr9MzumkNygno/2cu6IiMLruWKMVQYB8Mg2HPOA== X-Received: by 10.55.18.28 with SMTP id c28mr6029124qkh.297.1507472161100; Sun, 08 Oct 2017 07:16:01 -0700 (PDT) Received: from [192.168.2.246] (pool-173-66-76-215.washdc.fios.verizon.net. [173.66.76.215]) by smtp.googlemail.com with ESMTPSA id n45sm3663687qtf.51.2017.10.08.07.15.59 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 08 Oct 2017 07:16:00 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Sun, 08 Oct 2017 10:16:00 -0400 From: Carl Wallace To: Peter Bowen , Dmitry Belyavsky CC: LAMPS , "" , "mozilla-dev-security-policy@lists.mozilla.org" , "saag@ietf.org" Message-ID: Thread-Topic: [pkix] New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [lamps] [pkix] New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 14:16:04 -0000 Also, RFC 5937 defines how to process the constraints from the 5914 structure. On 10/7/17, 11:31 PM, "pkix on behalf of Peter Bowen" wrote: >On Tue, Sep 12, 2017 at 5:59 AM, Dmitry Belyavsky via >dev-security-policy wrote: >> Here is the new version of the draft updated according to the >>discussion on >> mozilla-dev-security list. > >Given that RFC 5914 already defines a TrustAnchorList and >TrustAnchorInfo object and that the Trust Anchor List object is >explicitly contemplated as being included in a signed CMS message, >would it not make more sense to start from 5914 and define new >extensions encode constraints not currently defined? > >Thanks, >Peter > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From nobody Mon Oct 9 05:29:53 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAFD12ECEC; Mon, 9 Oct 2017 05:29:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant To: Cc: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-eai-addresses.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150755218750.18429.7677923740371819251@ietfa.amsl.com> Date: Mon, 09 Oct 2017 05:29:47 -0700 Archived-At: Subject: [lamps] Genart last call review of draft-ietf-lamps-eai-addresses-15 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 12:29:48 -0000 Reviewer: Stewart Bryant Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-lamps-eai-addresses-?? Reviewer: Stewart Bryant Review Date: 2017-10-09 IETF LC End Date: 2017-10-09 IESG Telechat date: Not scheduled for a telechat Summary: I have looked at the changes since the last version I reviewed and it is still ready for publication. Major issues: None Minor issues: None Nits/editorial comments: None From nobody Tue Oct 10 07:39:59 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB8112ECEC; Tue, 10 Oct 2017 07:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=eYTSt0G+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UNyrI0bL 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 QXTVfftSGITp; Tue, 10 Oct 2017 07:39:50 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914F31343C3; Tue, 10 Oct 2017 07:39:27 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C5DB121074; Tue, 10 Oct 2017 10:39:26 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Tue, 10 Oct 2017 10:39:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=9WyOHDh8tPt5W5hI5K 12DG4jU5Ku0ombM5rT4fyuF4k=; b=eYTSt0G+lgQm61NE4UttmeAEEFgjafLsQY z33LfIiCx/mhNHjA8HnjGYB4y7aXA47nvxTMS7gl6YTx5ygYHGF6nrwwgp8Ta6Bw c9KJFMvmpnSWQfMjBLPu2Qqxske/LiPpfDaGgztIcgbBEc5FPoQdHCLu+XknuYi/ 3BrOxbMjQlSl4pEq9T3LARWLFnwvnpFRgN8KQWaPuiLlKaxKcM5gP66m5ecmraFd /ByzYFT0qLEzMV7zjiSoESzv1LcHVpfE+4/pAfWUDhxoqh9zF1VYf6jUBvffM0KN ckAhk5t2KhzwmZs9x/ftMAKu94sKkVoLGzk+fSa0NN7vkuho8c+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=9WyOHDh8tPt5W5hI5K12DG4jU5Ku0ombM5rT4fyuF4k=; b=UNyrI0bL fsoaEpwb5gT0QXugvze22BV0u4IMQlRftjxbIwbBrzHo/dbHCPKxSTNbbSszqYyo i3E5i/hsNIcbpww/IZw3M6ICZsZiyHU9sqg6yVPxYg5Qv+cvUuG6ywqzkeOlyJva 3GEH0f8NbZUKKoT8jHr0XNvcOyYkD0WRbD3DVY1G75NpDp2bry08U5IqWpFlNhMU TFVGQ1APTtZlpzpR8qm8pUNRj/l1qIPdye5ZYGzK9DpASKfMfHAR46B+EZfoF3w0 bkHnbbdlydhNBW6kBbmEc/g7WTZX1RgTC+5lRXUU4TGhml8NxGiVsH66EToclrH1 yaqf2bII6KkdAw== X-ME-Sender: X-Sasl-enc: JtqdydCA9sFC2JCeDW2qCZikh1OT48hljymdXPc6SOL4 1507646366 Received: from sjc-alcoop-88112.cisco.com (unknown [128.107.241.190]) by mail.messagingengine.com (Postfix) with ESMTPA id BD77F24772; Tue, 10 Oct 2017 10:39:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <150663032250.27722.15835601633819810120@ietfa.amsl.com> Date: Tue, 10 Oct 2017 10:39:23 -0400 Cc: gen-art , draft-ietf-lamps-rfc5280-i18n-update.all@ietf.org, spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8CC64708-D350-40A6-B2CB-37B5039E8140@cooperw.in> References: <150663032250.27722.15835601633819810120@ietfa.amsl.com> To: Joel Halpern X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [lamps] [Gen-art] Genart telechat review of draft-ietf-lamps-rfc5280-i18n-update-03 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 14:39:52 -0000 Joel, thank you for your review. I have entered a Yes ballot for this = document. Alissa > On Sep 28, 2017, at 4:25 PM, Joel Halpern wrote: >=20 > Reviewer: Joel Halpern > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-lamps-rfc5280-i18n-update-03 > Reviewer: Joel Halpern > Review Date: 2017-09-28 > IETF LC End Date: 2017-07-25 > IESG Telechat date: 2017-10-12 >=20 > Summary: This document is still ready for publication as a Proposed = Standard >=20 > Major issues: N/A >=20 > Minor issues: N/A >=20 > Nits/editorial comments: N/A >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Oct 10 18:10:48 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 926B51270AB; Tue, 10 Oct 2017 18:10:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-lamps-rfc5280-i18n-update@ietf.org, Phillip Hallam-Baker , Russ Housley , lamps-chairs@ietf.org, phill@hallambaker.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150768424357.24799.4538872386645863659.idtracker@ietfa.amsl.com> Date: Tue, 10 Oct 2017 18:10:43 -0700 Archived-At: Subject: [lamps] Adam Roach's Discuss on draft-ietf-lamps-rfc5280-i18n-update-03: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 01:10:43 -0000 Adam Roach has entered the following ballot position for draft-ietf-lamps-rfc5280-i18n-update-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The final paragraph in Section 2.4 reads: Implementations should convert the local-part and the host-part of internationalized email addresses placed in these extensions to Unicode before display. The mention of converting "local-part" to "Unicode" has a very strong implication that the local-part of internationalized email addresses can be (should be?) ACE-encoded (or otherwise converted to some non-Unicode encoding). Unless my understanding of internationalized email addresses is wildly wrong (and that may be the case), this isn't how they work: the local-part *is* in Unicode, and so conversion to Unicode doesn't make sense. This seems highly likely to lead developers down the path of ACE-encoding the local-part component of email addresses, which would cause incompatibilities. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The document has several instances of (lower-case) "should" where talking about implementation behavior. These look like they should be normative to me -- if that's the intention, please make them uppercase. If not, please update to RFC 8174 boilerplate. The document contains the following normative requirement: Note: Implementations MUST allow for increased space requirements for IDNs. It's hard to determine what an implementation needs to do in order to satisfy this normative requirement. Presumably, "increased" is relative to previous buffer allocations for domain names? Also, the statement can be satisfied as stated by simply increasing such buffers by a single byte. Surely that's not what's intended, is it? (Aside: I find the use of "Note:" preceding normative text to be confusing, so you might want to remove it) From nobody Tue Oct 10 21:10:23 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F40C13239C; Tue, 10 Oct 2017 21:10:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-lamps-rfc5280-i18n-update@ietf.org, Phillip Hallam-Baker , Russ Housley , lamps-chairs@ietf.org, phill@hallambaker.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150769502121.24823.6778910805810972408.idtracker@ietfa.amsl.com> Date: Tue, 10 Oct 2017 21:10:21 -0700 Archived-At: Subject: [lamps] Ben Campbell's No Objection on draft-ietf-lamps-rfc5280-i18n-update-03: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 04:10:21 -0000 Ben Campbell has entered the following ballot position for draft-ietf-lamps-rfc5280-i18n-update-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -1.1: Please consider using the boilerplate from 8174. There's at least at least one use of a lower-case "should" (in 7.5.1, last paragraph). From nobody Wed Oct 11 11:22:30 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C28B13306C for ; Wed, 11 Oct 2017 11:22:24 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVmLA96rDj-9 for ; Wed, 11 Oct 2017 11:22:21 -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 73F1C126B6E for ; Wed, 11 Oct 2017 11:22:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C8A7830056B for ; Wed, 11 Oct 2017 14:22:20 -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 CTi5xonCwmgK for ; Wed, 11 Oct 2017 14:22:19 -0400 (EDT) Received: from [192.168.6.27] (unknown [64.134.67.184]) by mail.smeinc.net (Postfix) with ESMTPSA id 74DE4300265; Wed, 11 Oct 2017 14:22:16 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <150768424357.24799.4538872386645863659.idtracker@ietfa.amsl.com> Date: Wed, 11 Oct 2017 14:22:07 -0400 Cc: IESG , SPASM , Phillip Hallam-Baker Content-Transfer-Encoding: quoted-printable Message-Id: <8A6B588D-B72B-48C1-A7DB-1BB40F5C7D0F@vigilsec.com> References: <150768424357.24799.4538872386645863659.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Adam Roach's Discuss on draft-ietf-lamps-rfc5280-i18n-update-03: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 18:22:24 -0000 > On Oct 10, 2017, at 9:10 PM, Adam Roach wrote: >=20 > Adam Roach has entered the following ballot position for > draft-ietf-lamps-rfc5280-i18n-update-03: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > The final paragraph in Section 2.4 reads: >=20 > Implementations should convert the local-part and the host-part of > internationalized email addresses placed in these extensions to > Unicode before display. >=20 > The mention of converting "local-part" to "Unicode" has a very strong > implication that the local-part of internationalized email addresses = can be > (should be?) ACE-encoded (or otherwise converted to some non-Unicode = encoding). > Unless my understanding of internationalized email addresses is wildly = wrong > (and that may be the case), this isn't how they work: the local-part = *is* in > Unicode, and so conversion to Unicode doesn't make sense. >=20 > This seems highly likely to lead developers down the path of = ACE-encoding the > local-part component of email addresses, which would cause = incompatibilities. Right. I'll correct that text. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The document has several instances of (lower-case) "should" where = talking about > implementation behavior. These look like they should be normative to = me -- if > that's the intention, please make them uppercase. If not, please = update to RFC > 8174 boilerplate. Okay. I'll double check each use of "should" in the document. > The document contains the following normative requirement: >=20 > Note: Implementations MUST allow for increased space requirements > for IDNs. >=20 > It's hard to determine what an implementation needs to do in order to = satisfy > this normative requirement. Presumably, "increased" is relative to = previous > buffer allocations for domain names? Also, the statement can be = satisfied as > stated by simply increasing such buffers by a single byte. Surely = that's not > what's intended, is it? The real assistance comes in the next sentence: An IDN ACE label will begin with the four additional characters "xn--" and may require as many as five ASCII characters to specify a single international character. > (Aside: I find the use of "Note:" preceding normative text to be = confusing, so > you might want to remove it) It is more of an implementation consideration. Russ From nobody Wed Oct 11 14:26:32 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B125013219E for ; Wed, 11 Oct 2017 14:26:31 -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 mPp6haCwOQjp for ; Wed, 11 Oct 2017 14:26:29 -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 BE2A4132992 for ; Wed, 11 Oct 2017 14:26:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 12F8E3005C7 for ; Wed, 11 Oct 2017 17:26:29 -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 iHm8XKWN2hJl for ; Wed, 11 Oct 2017 17:26:27 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 542F330026B; Wed, 11 Oct 2017 17:26:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <150769502121.24823.6778910805810972408.idtracker@ietfa.amsl.com> Date: Wed, 11 Oct 2017 17:26:27 -0400 Cc: IESG , SPASM , Phillip Hallam-Baker Content-Transfer-Encoding: 7bit Message-Id: <72EACCDA-E67E-402C-8501-78F3871E3F95@vigilsec.com> References: <150769502121.24823.6778910805810972408.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lamps] Ben Campbell's No Objection on draft-ietf-lamps-rfc5280-i18n-update-03: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 21:26:32 -0000 Thanks. This is fixed in my edit buffer. Russ > On Oct 11, 2017, at 12:10 AM, Ben Campbell wrote: > > Ben Campbell has entered the following ballot position for > draft-ietf-lamps-rfc5280-i18n-update-03: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > -1.1: Please consider using the boilerplate from 8174. There's at least at > least one use of a lower-case "should" (in 7.5.1, last paragraph). From nobody Wed Oct 11 23:05:13 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8B9132F30; Wed, 11 Oct 2017 23:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=PGMSKrCl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eqfl8PPn 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 FMxxvjYkfQgp; Wed, 11 Oct 2017 23:05:05 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F64B132A1A; Wed, 11 Oct 2017 23:05:05 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id EC14820D9D; Thu, 12 Oct 2017 02:05:04 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 12 Oct 2017 02:05:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=ZNeLfYlP0KxIy5Q/lu0EzX26xynIe 2v9Vy6Ell0y7tE=; b=PGMSKrCl3OHo4jQN1LGlRDTaOqzYqtaFUZ6aXf2sXD1CA WbBkvDcksBqRhYC7Zh/EoBx8rI9z3qWxVxy31A//Seg/1X5tMk/0d7Cb5Dgi2g8b ddbsLh49OZXByF8mNABTf2Jg3j23iJpbADjtizV/O7ClxhoT+ro+kz1QUEBj4/6Q b+6eVlkKmvxNNln+mE5r6VglC4eSzsBr89Zv3pBfKiL2J173iFYfCNkfkvvNwnJ/ FjsmVNYk7VLiK85j2Oeh0e2aHDBHDIE0mR7EvgX/xLKLzinzugzzBlC5lETGY7wN krAU+BcRJJmDsTW35CtpXNdirUIlMc5OBDY1YYMjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ZNeLfY lP0KxIy5Q/lu0EzX26xynIe2v9Vy6Ell0y7tE=; b=eqfl8PPno42aAUPvIlbzXh 7wviERioxujNssQvDm7mFf/qFvI8Ntzl6SK/vkU1XOWUEjQRNQKGwgHzDem1AKDd 1FSTpSd7uNr1BcG42Zaq/rcv0R/wE/HpkH7Ge1eO9c9Ak4VjZ6tGa//pRXxbOkIc ht9LwUy+Bqmri5aJ1NmaGYMhtwuQcdNFjYV3UIdT428ZPWdBnZhSXZjVixDVBhmB zZAL0qJVMQy3t3fWoP9HlU2hGK/IjCPO/LgXRF9jAGgxOn8QVU159JA8MT/bL10z w9Vr1nIyeXhCdVq2tA4A1QcdtpooVkUw2C99G5CuLoXiYcLJ656jB9hIL7EqxkJg == X-ME-Sender: Received: from [192.168.1.111] (ppp109-252-99-137.pppoe.spdop.ru [109.252.99.137]) by mail.messagingengine.com (Postfix) with ESMTPA id 819F77F91D; Thu, 12 Oct 2017 02:05:04 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: <8A6B588D-B72B-48C1-A7DB-1BB40F5C7D0F@vigilsec.com> Date: Thu, 12 Oct 2017 07:08:47 +0100 Cc: SPASM , IESG Content-Transfer-Encoding: quoted-printable Message-Id: <7EBEBC65-4F26-439D-8683-55306752950D@fastmail.fm> References: <150768424357.24799.4538872386645863659.idtracker@ietfa.amsl.com> <8A6B588D-B72B-48C1-A7DB-1BB40F5C7D0F@vigilsec.com> To: Russ Housley , Adam Roach Archived-At: Subject: Re: [lamps] Adam Roach's Discuss on draft-ietf-lamps-rfc5280-i18n-update-03: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 06:05:07 -0000 On 11 Oct 2017, at 19:22, Russ Housley wrote: >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> The final paragraph in Section 2.4 reads: >>=20 >> Implementations should convert the local-part and the host-part of >> internationalized email addresses placed in these extensions to >> Unicode before display. >>=20 >> The mention of converting "local-part" to "Unicode" has a very strong >> implication that the local-part of internationalized email addresses can b= e >> (should be?) ACE-encoded (or otherwise converted to some non-Unicode enco= ding). >> Unless my understanding of internationalized email addresses is wildly wr= ong >> (and that may be the case), this isn't how they work: the local-part *is*= in >> Unicode, and so conversion to Unicode doesn't make sense. >>=20 >> This seems highly likely to lead developers down the path of ACE-encoding= the >> local-part component of email addresses, which would cause incompatibilit= ies. >=20 > Right. I'll correct that text. Good catch. I think just deleting local-part from the list should do. From nobody Thu Oct 12 05:04:18 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A555913449D; Thu, 12 Oct 2017 05:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63ajlBVraiIq; Thu, 12 Oct 2017 05:04:05 -0700 (PDT) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 57FCF1330AD; Thu, 12 Oct 2017 05:04:05 -0700 (PDT) Received: by mail-qk0-x242.google.com with SMTP id k123so918593qke.3; Thu, 12 Oct 2017 05:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=TCqPnYL4yBFTpRdUr7jblVhd2/TZXBoC9g9GpOVcukw=; b=aZXngVJolKmB5qKUZjBFNqxaUs8suE/ETIDub7xnI/rT+nQHZLaUuVVxKauMy15SQl NiayiBih/spKuPqfB5qJOaHmS9GjeJ9HNGgvA37jw8lnBCDk2EbaYvqSA5m0ei7nkOkg sv3NLA+4/haizzyfcGWWp5F81ZFhsbFQ44OENQhZLKOAZs5UKpqRAP8u4JGk2LcAOw8N 9ur5kwX7Gtr6ZxJv/kfwqpXnQoOLLhI7QgfZ1FcgHQtlKFgnIqML57kDMxcH9jQ5zbD0 ta9CNvc65Rvl/gYYcZDoBDyH45yjPQn4cr5FVyO1A6j1yZ7Dww2F4XJe0gGKyE09YSRa fLuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=TCqPnYL4yBFTpRdUr7jblVhd2/TZXBoC9g9GpOVcukw=; b=jtH/xx4PZJeubpu9imObBWTgZWsb4S5rKlKC0PYmGSneDmVgx+UIMzCnx01TuZBO7n IfSO0WXJj/hPQLbCfrQrO+PAHdWfgRPtj9Wje/s3+ZEjog464MPiQG1fBJo3717IqnjX jhv4bvi5DYWIJdFZitlMaSSuqDFCbvqvgmP1du+kO/IATdH0MAD8tvRjHpAc0AqgFond U/wW4yfCB8v9dPtidQCKVykqHH86bBRVHyWY9DQDckM21O51qTubtTE8hSTPW8ogVCm9 xlyu2XgsxnVYyNGKWPsFpuIowgDUkolzfigmQ5eJmXAl93mJup3Fj4SNDKd784nMAhY0 nRLg== X-Gm-Message-State: AMCzsaVahLQ+z/0u6a05EuuukAw9XeywMeKayRxjPiNkajxy6ToIevKM lVJUHXu36Ee81P9ZwQVKWtoVq0j/rWaVaBW5+uA= X-Google-Smtp-Source: ABhQp+S0Ize0DihDopeTfONoJZR2DeYX/5+R4CCzu9p+nsV8RV6f60RHcvV0Rz8eAsTf15MGKkks+OErQseG4cYvesE= X-Received: by 10.55.119.5 with SMTP id s5mr59984qkc.233.1507809844422; Thu, 12 Oct 2017 05:04:04 -0700 (PDT) MIME-Version: 1.0 Sender: n.mavrogiannopoulos@gmail.com Received: by 10.12.148.1 with HTTP; Thu, 12 Oct 2017 05:03:23 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Nikos Mavrogiannopoulos Date: Thu, 12 Oct 2017 14:03:23 +0200 X-Google-Sender-Auth: cN59JnC25PeuqtWEpUsR4t3QJOQ Message-ID: To: Dmitry Belyavsky Cc: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 12:04:11 -0000 On Sat, Oct 7, 2017 at 8:37 PM, Dmitry Belyavsky wrote: > Dear Nicos, > > Sorry for the delay with my response. > > On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos > wrote: >> >> On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky >> wrote: >> > Dear Nikos >> > >> > On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos >> > >> > wrote: >> >> >> >> >> >> 4. How do you handle extensions to this format? >> >> >> >> Overall, why not use X.509 extensions to store such additional >> >> constraints? We already (in the p11-kit trust store in Fedora/RHEL >> >> systems) use the notion of stapled extensions to limit certificates >> >> [0, 1] and seems quite a flexible approach. Have you considered that >> >> path? >> >> >> >> regards, >> >> Nikos >> >> >> >> [0]. >> >> >> >> https://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.html >> >> [1]. >> >> >> >> http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certificates.html >> > I've looked through the specification. It's OK for me, but I do not get >> > whether the attached extensions are crypto-protected. >> >> No, as these values are inserted by the administrator of the system, >> or us (the distributor of the software), we didn't feel we needed the >> introduction of additional PKI. > > > Well, the specification I suggest should allow applying CLPs issued by major > vendors (Mozilla etc). > For this purposes the CLPs should be validable => signed. Hi, If mozilla or any other organization is willing to deploy such PKI, that would be great. However for the majority of software, I'd expect that such files are distributed using the same channel as software, and thus using the same authentication mechanism for it rather than a new PKI. For a software distributor to use that optional signing could work. >> One problem with that is the fact that the existing CRL extensions are >> about extending attributes of the CRL, rather than adding/removing >> attributes to the certificate in question. > For this purposes I implied that the limitations are provided not by > extensions, > but as SEQUENCE of limitations related to the certificates. > > Was I wrong in the ASN1 scheme in the current version of my draft? I do not think that the presented ASN.1 description is valid. The "limitations SEQUENCE," doesn't define anything in ASN.1 (i..e, it is a sequence of what?). > >> >> To bring the stapled extensions to your proposal, you'd need the >> Extensions and Extension fields from RFC5280, and >> add into limitedCertificates structure (I'll split it on the example >> below for clarity) the following field. >> >> LimitedCertificates ::= SEQUENCE OF LimitedCertificate >> >> LimitedCertificate ::= SEQUENCE { >> userCertificate CertificateSerialNumber, >> certificateIssuer Name, >> limitationDate Time, >> limitationPropagation Enum, >> fingerprint SEQUENCE { >> fingerprintAlgorithm AlgorithmIdentifier, >> fingerprintValue OCTET STRING >> } OPTIONAL, >> limitations SEQUENCE, >> } OPTIONAL, >> }; >> >> >> stapledExtensions Extensions; <----- NEW >> } > > > Sorry, I do not get the difference between the purposes of the field > 'limitations' > and 'stapledExtensions'. I cannot answer this as I cannot see the syntax of the limitations field. I thought it was a field intended to spark discussion rather than anything specific. regards, Nikos From nobody Thu Oct 12 11:58:11 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E0513306A; Thu, 12 Oct 2017 11:58:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150783468462.16877.7887924946874882629@ietfa.amsl.com> Date: Thu, 12 Oct 2017 11:58:04 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc5280-i18n-update-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 18:58:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Internationalization Updates to RFC 5280 Author : Russ Housley Filename : draft-ietf-lamps-rfc5280-i18n-update-04.txt Pages : 9 Date : 2017-10-12 Abstract: These updates to RFC 5280 provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for Internationalized Email Addresses in X.509 Certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5280-i18n-update-04 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5280-i18n-update-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5280-i18n-update-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 18 10:26:51 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BB61270AB; Wed, 18 Oct 2017 10:26:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-lamps-rfc5280-i18n-update@ietf.org, Phillip Hallam-Baker , Russ Housley , lamps-chairs@ietf.org, phill@hallambaker.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150834760460.12457.7208764721267798395.idtracker@ietfa.amsl.com> Date: Wed, 18 Oct 2017 10:26:44 -0700 Archived-At: Subject: [lamps] Adam Roach's No Objection on draft-ietf-lamps-rfc5280-i18n-update-04: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 17:26:45 -0000 Adam Roach has entered the following ballot position for draft-ietf-lamps-rfc5280-i18n-update-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5280-i18n-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. From nobody Thu Oct 19 17:21:03 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E418D134957 for ; Thu, 19 Oct 2017 17:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.869 X-Spam-Level: ** X-Spam-Status: No, score=2.869 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 5Crc5JH-W1fb for ; Thu, 19 Oct 2017 17:21:00 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 68EFF13495F for ; Thu, 19 Oct 2017 17:20:53 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 395D83740E16 for ; Fri, 20 Oct 2017 00:20:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zmt0QTn_ZmfS for ; Thu, 19 Oct 2017 20:20:52 -0400 (EDT) Received: from nuc.openca.org (207-38-147-98.s4930.c3-0.avec-ubr2.nyr-avec.ny.cable.rcncustomer.com [207.38.147.98]) (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 EA2F83740C3E for ; Thu, 19 Oct 2017 20:20:51 -0400 (EDT) To: spasm@ietf.org From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <9441d5c6-2164-a6b5-aafc-03da4a38a8b0@openca.org> Date: Thu, 19 Oct 2017 20:20:39 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080500040800030602090806" Archived-At: Subject: [lamps] Request for Presentation @IETF100 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 00:21:02 -0000 This is a cryptographically signed message in MIME format. --------------ms080500040800030602090806 Content-Type: multipart/alternative; boundary="------------A5A540B1178923EC809C2FBC" Content-Language: en-US This is a multi-part message in MIME format. --------------A5A540B1178923EC809C2FBC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, I wanted to ask if it was possible to reserve 5-10 minutes @IETF100 for=20 a presentation about the work we are doing on the distribution of=20 revocation information over DNS. In particular, I would like to go over=20 the current I-D we have submitted (hopefully to be soon-updated). For the implementation we are still lacking behind (mostly because my=20 very recent stepping into parenthood :D), but I hope we can have some=20 news there too :D Please let me know, Cheers, Max --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------A5A540B1178923EC809C2FBC Content-Type: multipart/related; boundary="------------44F23C1FE29C996FDD54997F" --------------44F23C1FE29C996FDD54997F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi all,

I wanted to ask if it was possible to reserve 5-10 minutes @IETF100 for a presentation about the work we are doing on the distribution of revocation information over DNS. In particular, I would like to go over the current I-D we have submitted (hopefully to be soon-updated).

For the implementation we are still lacking behind (mostly because my very recent stepping into parenthood :D), but I hope we can have some news there too :D

Please let me know,

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------44F23C1FE29C996FDD54997F Content-Type: image/png; name="ndiddgffgieghojd.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ndiddgffgieghojd.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= --------------44F23C1FE29C996FDD54997F-- --------------A5A540B1178923EC809C2FBC-- --------------ms080500040800030602090806 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 AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEw MjAwMDIwMzlaMC8GCSqGSIb3DQEJBDEiBCBlyYjr1BlEkr7D3g36ex0oRZy08LlmZlCkRWb9 vylafTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBAJ7OHQ0nIyofXppV 9HiTyFGnmR9C9xeEONz2KEeBpjcLH77cwCBYCFy1WxpZJ0fldG1Tim1SqL7IK0LgTOuO7sDz iyNZVvDYh28xS9t0cla1pm94M0EjIGqznBkyQGvVEKRHbNlGnXBBfPHWG9l3OVenm4v7qyj3 bHxuksV/TvwJLKQIXy+Ws/dB8rwTz4fci8zOzp1ZAe6UiZtWkC+XNEf5vsH44pXvjNtQ7kHx ts8NbO4AyAwmlQ3HinT4LQbW1HNN/57w0siTaenjEVX2l2ebmJK/3qhJxplCPtNBAe4qCpWm koGE/0NbD6s8XIqY6piqSQ37TN+TFztGL0yxqNEAAAAAAAA= --------------ms080500040800030602090806-- From nobody Fri Oct 20 17:28:08 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C01AD1344FD; Fri, 20 Oct 2017 17:24:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: spasm@ietf.org, ekr@rtfm.com X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854546178.20809.1255733103636238047.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:21 -0700 Archived-At: Subject: [lamps] lamps - Requested session has been scheduled for IETF 100 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:22 -0000 Dear Russ Housley, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. lamps Session 1 (1:00:00) Monday, Morning Session I 0930-1200 Room Name: Orchard size: 50 --------------------------------------------- Special Note: 1100-1200 Request Information: --------------------------------------------------------- Working Group Name: Limited Additional Mechanisms for PKIX and SMIME Area Name: Security Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: rtcweb ace acme openpgp stir fud ipwave tls sipbrandy sidrops saag perc quic curdle Second Priority: cfrg dprive ecrit oauth sacm mile modern radext Third Priority: mtgvenue iasa20 People who must be present: Russ Housley Eric Rescorla Sean Turner Jim Schaad Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Oct 26 14:59:23 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B915413F60D; Thu, 26 Oct 2017 14:59:16 -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 DHnptkKB9M5l; Thu, 26 Oct 2017 14:59:14 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 96C6213F46E; Thu, 26 Oct 2017 14:59:14 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 509C43741015; Thu, 26 Oct 2017 21:59:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lzoytQTzIki7; Thu, 26 Oct 2017 17:59:07 -0400 (EDT) Received: from maxs-mbp.cablelabs.com (unknown [192.160.73.16]) (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 04D913740E16; Thu, 26 Oct 2017 17:59:06 -0400 (EDT) To: saag@ietf.org, LAMPS References: <10f5c653-e2b7-9332-02b0-5528e6693582@openca.org> <3D9CC81C-404A-48D0-9F45-14829FADC646@vpnc.org> <58937108-5f04-5be8-bfe8-948dd4ea13dc@openca.org> From: "Dr. Pala" Message-ID: Date: Thu, 26 Oct 2017 15:59:06 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <58937108-5f04-5be8-bfe8-948dd4ea13dc@openca.org> Content-Type: multipart/alternative; boundary="------------08F6701D51A17113189BBF61" Content-Language: en-US Archived-At: Subject: [lamps] Draft New Version (was Re: [saag] Proposal for OCSP over DNS) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 21:59:17 -0000 This is a multi-part message in MIME format. --------------08F6701D51A17113189BBF61 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, I just want to let everybody know that we manage to send in the latest version of the draft that better organizes the text and incorporates the previous work / I-Ds into one: https://datatracker.ietf.org/doc/draft-pala-odin comments, feedback, etc. always welcome :D Cheers, Max On 10/23/17 3:38 PM, Dr. Pala wrote: > > Hi Paul, all, > > the way I personally see this is not only related to Internet CAs / > website-oriented TLS, but also as a way to distribute the revocation > information in environments where entities (devices, software, etc.) > might be restricted from accessing the global Internet but still > allowed to query the DNS. Entities leveraging specific trust > environments (e.g., OCF, CMI, etc. ) might especially benefit from > this additional distribution mechanism (which is not in competition > with existing solutions :D) > > Beefing up CAs web infrastructures is what CAs have been doing so far > - AFAIK, however that comes at high operational costs that have to be > covered somehow :D I think that it will be useful to have an > alternative that can be as efficient (if not even more efficient), > distributed (info get closer to the client), and that comes at > (potentially) lower operational costs. > > Just my 2 cents... > > Cheers, > Max > > > On 10/23/17 3:13 PM, Paul Hoffman wrote: >> On 23 Oct 2017, at 13:54, Dr. Pala wrote: >> >>> we are currently working on specifying how to use DNS as a transport >>> protocol for revocation information for X509 certificates. In >>> particular, we are working on how to leverage the distributed nature >>> of DNS to efficiently (and at lower operational costs) distribute >>> OCSP responses to applications/devices/etc. >>> >>> We started this work sometime ago but never really had the time to >>> finish it. Now it seems we can focus more on the topic and would >>> like to discuss this work in a more public venue. >>> >>> We currently have two similar I-D submitted (that should probably be >>> re-edited and merged): >>> >>>  * https://datatracker.ietf.org/doc/draft-pala-odin/ >>>  * https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/ >>> >>> EKR suggested that this may be another topic for the SEC-DISPATCH >>> meeting. Can we have 5-10 minutes for this @IETF100 ? >> >> These sound like "we want HTTP over UDP to save latency, so we'll >> just substitute DNS". That's certainly an option, but it hasn't been >> a popular route in the IETF. Are the busy CAs asking for this? Is >> there a reason why they can't just beef up their web infrastructure >> (like their customers are)? >> >> --Paul Hoffman > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > OpenCA Logo > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------08F6701D51A17113189BBF61 Content-Type: multipart/related; boundary="------------7521D1A940D3FDEE1E02516E" --------------7521D1A940D3FDEE1E02516E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi all,

I just want to let everybody know that we manage to send in the latest version of the draft that better organizes the text and incorporates the previous work / I-Ds into one:

https://datatracker.ietf.org/doc/draft-pala-odin

comments, feedback, etc. always welcome :D

Cheers,
Max


On 10/23/17 3:38 PM, Dr. Pala wrote:

Hi Paul, all,

the way I personally see this is not only related to Internet CAs / website-oriented TLS, but also as a way to distribute the revocation information in environments where entities (devices, software, etc.) might be restricted from accessing the global Internet but still allowed to query the DNS. Entities leveraging specific trust environments (e.g., OCF, CMI, etc. ) might especially benefit from this additional distribution mechanism (which is not in competition with existing solutions :D)

Beefing up CAs web infrastructures is what CAs have been doing so far - AFAIK, however that comes at high operational costs that have to be covered somehow :D I think that it will be useful to have an alternative that can be as efficient (if not even more efficient), distributed (info get closer to the client), and that comes at (potentially) lower operational costs.

Just my 2 cents...

Cheers,
Max


On 10/23/17 3:13 PM, Paul Hoffman wrote:
On 23 Oct 2017, at 13:54, Dr. Pala wrote:

we are currently working on specifying how to use DNS as a transport protocol for revocation information for X509 certificates. In particular, we are working on how to leverage the distributed nature of DNS to efficiently (and at lower operational costs) distribute OCSP responses to applications/devices/etc.

We started this work sometime ago but never really had the time to finish it. Now it seems we can focus more on the topic and would like to discuss this work in a more public venue.

We currently have two similar I-D submitted (that should probably be re-edited and merged):

 * https://datatracker.ietf.org/doc/draft-pala-odin/
 * https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/

EKR suggested that this may be another topic for the SEC-DISPATCH meeting. Can we have 5-10 minutes for this @IETF100 ?

These sound like "we want HTTP over UDP to save latency, so we'll just substitute DNS". That's certainly an option, but it hasn't been a popular route in the IETF. Are the busy CAs asking for this? Is there a reason why they can't just beef up their web infrastructure (like their customers are)?

--Paul Hoffman

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


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

--------------7521D1A940D3FDEE1E02516E Content-Type: image/png; name="ddffjiojeijcccop.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ddffjiojeijcccop.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= --------------7521D1A940D3FDEE1E02516E-- --------------08F6701D51A17113189BBF61-- From nobody Fri Oct 27 05:16:50 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD93713B13E; Fri, 27 Oct 2017 05:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 UYXRqJSfWO92; Fri, 27 Oct 2017 05:16:46 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 CF253138BD8; Fri, 27 Oct 2017 05:16:46 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id j126so10544494oib.8; Fri, 27 Oct 2017 05:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Yc0YEwQg9Ae/vBs3D1SCwAE5yYQ0JqzP5ERo9QcvGm0=; b=OMHQdhH0hFTZ4DYGu5qXIc/Bp/GuE7LO/AxVGyqMbyIp1VUQXrKMV2i+UJoInxqs8I KM2/62pVi/haQ9sYDH7f+IJm0H4jeqKgzX8MZtYFQbG/7JWyHEtvJiDIJ8u5mG2Dg9lv xxrfWxTEgXcOI1Q0ESWbjbeXdLMQcbgpzowzdcfuFH7kc6QXR7brhCSlg9F9oN71/ucn LOIHKi1xPClDRXyNxNglmypRn7FsrfGM9zUwCE5Sdf/mlXTO8FVFiOg5T5D87LojR06M CAB8Mbw+attn/PFcK0Qjb/1HbdBwfCBeD3EmvOwuSvERJKNUVUAZ0GzBod1SWdxjlvLQ T/SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Yc0YEwQg9Ae/vBs3D1SCwAE5yYQ0JqzP5ERo9QcvGm0=; b=q5ZuOabZSd4cT+GxKT9aU6Lbg93vw/1aAcLR6JUFNQZAPA65Y11CzTULDyIH5mmBds y+OBEl7emO5f/NIoplOmIE6e6MoltFChqN78c0sTdykF+fx6S2U16wQ84j5vVrb+ZZwF czXQVncwFqRTCyVIuRv6IhCVWzITHGfASbZ0UYEk29Bm1RD7vMSNQRaGs57XWrp2VF+V jHLaSWwtILt4Xmz3wJHu5LbJRu8MiAdycuVC8nptigEQxpud/FgjhywHBU/AqG4idNtI AHLJ7PV/3YdnXLtpgb7IQg3ztswPr7nCLe7T2W2ION4q0EMpKYkK/HM5nrKrk0X3YR6s rIfA== X-Gm-Message-State: AMCzsaVe9iKr2GBxCs2d+xJ6hUSu7qtzuZEpTW/DvhnMscCq54DMaQD6 rIFm6ljV8eRLxf8Z108KGHl4ycIW7w8UP6Fmmpk= X-Google-Smtp-Source: ABhQp+Smc5xV3bKf038wf3vDSsYZ3oxaF3JG85DIbyGnH+mB2QO1amOQwf1qWjYvKfEJGS+5Pr3zZvUVJfGbzgyK9/0= X-Received: by 10.157.17.72 with SMTP id p8mr163963otp.305.1509106606078; Fri, 27 Oct 2017 05:16:46 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.80.42 with HTTP; Fri, 27 Oct 2017 05:16:45 -0700 (PDT) In-Reply-To: <3D9CC81C-404A-48D0-9F45-14829FADC646@vpnc.org> References: <10f5c653-e2b7-9332-02b0-5528e6693582@openca.org> <3D9CC81C-404A-48D0-9F45-14829FADC646@vpnc.org> From: Phillip Hallam-Baker Date: Fri, 27 Oct 2017 08:16:45 -0400 X-Google-Sender-Auth: VtwmmqA_KcMJ1rv_AjrzLhtJlxE Message-ID: To: Paul Hoffman Cc: "Dr. Pala" , "saag@ietf.org" , SPASM Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] [saag] Proposal for OCSP over DNS X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 12:16:49 -0000 On Mon, Oct 23, 2017 at 5:13 PM, Paul Hoffman wrote: > On 23 Oct 2017, at 13:54, Dr. Pala wrote: > >> we are currently working on specifying how to use DNS as a transport >> protocol for revocation information for X509 certificates. In particular, we >> are working on how to leverage the distributed nature of DNS to efficiently >> (and at lower operational costs) distribute OCSP responses to >> applications/devices/etc. >> >> We started this work sometime ago but never really had the time to finish >> it. Now it seems we can focus more on the topic and would like to discuss >> this work in a more public venue. >> >> We currently have two similar I-D submitted (that should probably be >> re-edited and merged): >> >> * https://datatracker.ietf.org/doc/draft-pala-odin/ >> * https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/ >> >> EKR suggested that this may be another topic for the SEC-DISPATCH meeting. >> Can we have 5-10 minutes for this @IETF100 ? > > > These sound like "we want HTTP over UDP to save latency, so we'll just > substitute DNS". That's certainly an option, but it hasn't been a popular > route in the IETF. Are the busy CAs asking for this? Is there a reason why > they can't just beef up their web infrastructure (like their customers are)? Since QUIC is 'TCP++ over UDP' and flavor of the month, OCSP over QUIC is probably a more viable route. The expiry of the Micali and Kocher efficient revocation patents mean that we now have options beyond OCSP which is what we are currently focused on at Comodo. I have proposed OCSP over DNS several times in the past. The problem I ran into was that the chief concern of the browser providers is latency. And some are unwilling to accept any proposal that increases latency in any way for the sake of public safety. Attempting to use DNS as transport is highly problematic. Many networks block unknown RRs for a start. It is hard enough to get DNSSEC to work right. That led me to an approach where the OCSP and DNS lookups were combined into one UDP transaction to a trusted discovery service combining DNS lookup, OCSP and certificate fetch, aka 'omnibroker'. That is an approach I will probably be revisiting in the near future. From nobody Fri Oct 27 13:54:47 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD06F13836A for ; Fri, 27 Oct 2017 13:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nBkay1hq3ed7 for ; Fri, 27 Oct 2017 13:54:44 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id EBEC01395F3 for ; Fri, 27 Oct 2017 13:54:42 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id F272D3741019 for ; Fri, 27 Oct 2017 20:54:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pawsNuWPvVJ9 for ; Fri, 27 Oct 2017 16:54:33 -0400 (EDT) Received: from maxs-mbp.cablelabs.com (unknown [192.160.73.16]) (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 6C3313741015 for ; Fri, 27 Oct 2017 16:54:33 -0400 (EDT) To: spasm@ietf.org References: <10f5c653-e2b7-9332-02b0-5528e6693582@openca.org> <3D9CC81C-404A-48D0-9F45-14829FADC646@vpnc.org> From: "Dr. Pala" Message-ID: Date: Fri, 27 Oct 2017 14:54:32 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] [saag] Proposal for OCSP over DNS X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 20:54:46 -0000 Hi Phillip, all, I totally agree with your points - however, I still think that proposing this work could have some benefits and can be complimentary to work that will tackle more efficient revocation. I would support work in that direction and I think that this work could be a good starting point. In the meantime, providing the additional option to use DNS for the revocation info distribution (although more efficient data structures might be defined in the future) could help preparing support in software out there without the need to modify the data structures for the revInfo. For OCSP over QUIC (and, please, correct me if I am wrong here :D), I personally think that that would be more related to the transport layer (more similar to an HTTP endpoint) while one of the main points here is the use of the distributed and cached architecture of DNS which can help in reducing operational costs for CAs, move the revocation data closer to the edge of the network, and provide another distribution mechanism that can be leveraged by clients (not just browsers.. but also for IoT environments when authenticating devices and/or servers) that might not have direct access to the Internet but that can query the DNS system :D Thanks again, Cheers, Max On 10/27/17 6:16 AM, Phillip Hallam-Baker wrote: > On Mon, Oct 23, 2017 at 5:13 PM, Paul Hoffman wrote: >> On 23 Oct 2017, at 13:54, Dr. Pala wrote: >> >>> we are currently working on specifying how to use DNS as a transport >>> protocol for revocation information for X509 certificates. In particular, we >>> are working on how to leverage the distributed nature of DNS to efficiently >>> (and at lower operational costs) distribute OCSP responses to >>> applications/devices/etc. >>> >>> We started this work sometime ago but never really had the time to finish >>> it. Now it seems we can focus more on the topic and would like to discuss >>> this work in a more public venue. >>> >>> We currently have two similar I-D submitted (that should probably be >>> re-edited and merged): >>> >>> * https://datatracker.ietf.org/doc/draft-pala-odin/ >>> * https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/ >>> >>> EKR suggested that this may be another topic for the SEC-DISPATCH meeting. >>> Can we have 5-10 minutes for this @IETF100 ? >> >> These sound like "we want HTTP over UDP to save latency, so we'll just >> substitute DNS". That's certainly an option, but it hasn't been a popular >> route in the IETF. Are the busy CAs asking for this? Is there a reason why >> they can't just beef up their web infrastructure (like their customers are)? > Since QUIC is 'TCP++ over UDP' and flavor of the month, OCSP over QUIC > is probably a more viable route. > > The expiry of the Micali and Kocher efficient revocation patents mean > that we now have options beyond OCSP which is what we are currently > focused on at Comodo. > > > I have proposed OCSP over DNS several times in the past. The problem I > ran into was that the chief concern of the browser providers is > latency. And some are unwilling to accept any proposal that increases > latency in any way for the sake of public safety. > > Attempting to use DNS as transport is highly problematic. Many > networks block unknown RRs for a start. It is hard enough to get > DNSSEC to work right. > > That led me to an approach where the OCSP and DNS lookups were > combined into one UDP transaction to a trusted discovery service > combining DNS lookup, OCSP and certificate fetch, aka 'omnibroker'. > That is an approach I will probably be revisiting in the near future. > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Sun Oct 29 05:15:56 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046A213F542 for ; Sun, 29 Oct 2017 05:15:54 -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 (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 5H7k0yJlmZbn for ; Sun, 29 Oct 2017 05:15:52 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0099.outbound.protection.outlook.com [23.103.201.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1DE613A9F5 for ; Sun, 29 Oct 2017 05:15:51 -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=SGQ3GqGSYXw2WAMMvQfGOgX3ucoOSc5pMuPcejHtjTI=; b=oMfd+AiH6ld8Ihmm/sRCp2W0y63vqDS+Q7fyhUwgxXEN25jey+1+hBCp3SZUfurZ2AkBGUFLOFkr77ltSsqTbgUTSLDhCWSnvqKnk1WNkkbCi6k1NUMd5ohQG+xgA60oZhLMdH2a5UmQumUp5AZr5Or8cL8TOqb4oJ3HBgkvw3M= Received: from MWHPR09MB1469.namprd09.prod.outlook.com (10.173.50.19) by MWHPR09MB1472.namprd09.prod.outlook.com (10.173.50.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Sun, 29 Oct 2017 12:15:49 +0000 Received: from MWHPR09MB1469.namprd09.prod.outlook.com ([10.173.50.19]) by MWHPR09MB1469.namprd09.prod.outlook.com ([10.173.50.19]) with mapi id 15.20.0178.012; Sun, 29 Oct 2017 12:15:49 +0000 From: "Dang, Quynh (Fed)" To: "spasm@ietf.org" CC: 'Russ Housley' Thread-Topic: CMS with SHAKE128 and SHAKE256 draft. Thread-Index: AQHTUK+ohcjyehsaR0i8PIMsuKOaGA== Date: Sun, 29 Oct 2017 12:15:49 +0000 Message-ID: References: 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=quynh.dang@nist.gov; x-originating-ip: [129.6.222.142] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR09MB1472; 6:u3YyRWq0+aqfQbFsKL9NsSpXXAal4QgLzIekRL1NyhpxDYYansGdM7BciutEjLrkjuIPfMhQC4ugru5snADaIIF2GhwsTOl6Yeb77r+mNCOUj4i6XFYCbFaTqz9GWB9liqHBY1mGhsg1niIiVUGFfOvOu29Tjaz9PWtiYnIsHBFdQArFz6t7A3GFQos2loh0odrcPTf7NyhAeP4AeMIyP/wPGMvgMtWT8kJi+YRLUXShXGpmgIdYZuYGmFDKXVrv8fHQI7ak7RoxYs6V/xyRRrebjD8fN2Xc4r+PttAswUzvDxY78mtnS/qCpC6RRCR7Z/zb2ba7b1TAPBNX1KvonHWIk92gOHeczk8JHZNJk8o=; 5:B1sZXuqff2C/LBV4p0tlQVk4rY7zTsM1hisasJjtv0vrzcpOqCpfmbx9JO/fF+ZRG7FBbQpJ64aN3BNUB6tKL/ZSnG8g4Lc+tz30GFzGzBueKVfI2jletM7XXoYYcQgugHUvZsfkxpKmCyZB9tR0mIjQTZzLDDhNpkGkP762yGw=; 24:Bd/AKqp3JtmaRwi0wwj9ewbVJhw4ixmdG/mqBPFrhd80E87Oic1o3bFjfNkDCc3CczhaGJ6c7jxD1VMZGBOuFMwxAa2Mur6LNJicCwRlBK4=; 7:yHf4cGzX2jSey+pX9gFXjVHpG2CYcdg8kqBVG33/6uOCbJn+G5BQYTWais22izEVyKbBQjS68FLrehXRwb05njfdaSHS/o+jZQgHa96EeRl0SBnsEKBXuAzHJkx+yQ2ZoIoEUiMr11a/erA/J7K6cATqcubqd9sbEjPIDFMEaW5wdPTHqRKxHJd8kJ4LDVsNkPAmbSdZ9dItGJ4dd5Aqf61ChvhMeq5LkxVE2FfLu2HwwWEL1dE8/5rAGI829m0Q x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b3a14cdb-94e0-47e7-076f-08d51ec6caa3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(48565401081)(2017052603199); SRVR:MWHPR09MB1472; x-ms-traffictypediagnostic: MWHPR09MB1472: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(788757137089); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231020)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR09MB1472; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR09MB1472; x-forefront-prvs: 0475418F50 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(189002)(199003)(78114003)(53754006)(7696004)(5660300001)(6606003)(2950100002)(6916009)(2351001)(19627405001)(74316002)(2906002)(101416001)(7736002)(25786009)(77096006)(3280700002)(50986999)(76176999)(53936002)(54356999)(3660700001)(6506006)(6436002)(8936002)(1730700003)(81166006)(8676002)(81156014)(3846002)(102836003)(6116002)(68736007)(5640700003)(4743002)(4326008)(2900100001)(33656002)(97736004)(105586002)(189998001)(106356001)(606006)(478600001)(53546010)(66066001)(86362001)(6306002)(9686003)(55016002)(14454004)(316002)(2501003)(99286003)(966005)(236005)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1472; H:MWHPR09MB1469.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR09MB1469ECAAFB1DCDDBBC2C229CF3580MWHPR09MB1469namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: b3a14cdb-94e0-47e7-076f-08d51ec6caa3 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2017 12:15:49.2957 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1472 Archived-At: Subject: [lamps] CMS with SHAKE128 and SHAKE256 draft. X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 12:15:54 -0000 --_000_MWHPR09MB1469ECAAFB1DCDDBBC2C229CF3580MWHPR09MB1469namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Since our group did not adopt SHA3s, I replaced them by SHAKE128 and SHAKE2= 56 (asked by Russ Housley: the chair) in this draft https://tools.ietf.org/html/draft-housley-lamps-cms-sha3-hash-00, then gene= rated a new draft posted at the link below. https://datatracker.ietf.org/doc/draft-dang-lamps-cms-shakes-hash/ Since we use the SHAKEs, I specified KMAC for MAC. Regards, Quynh. ________________________________ From: Spasm on behalf of Russ Housley Sent: Friday, September 15, 2017 3:43 PM To: spasm@ietf.org Subject: [lamps] Starting work to CAA and SHAKE I have been discussing the recharter with EKR, and he agrees that we should= get started on this work even though the LAMPS re-charter is blocked on a = bit of process. Having completed the S/MIME 4.0 specifications and updates to support i18n = email addresses in PKIX certificates, the LAMPS WG is now ready to work on = two additional topics: 1. Specify a discovery mechanism for CAA records to replace the one describ= ed in RFC 6844. 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. Other topics can be considered when these two are progressing. CAA RFC 6844 describes the mechanism by which CAA records relating to a domain = are discovered. Implementation experience has demonstrated an ambiguity in= the current processing of CNAME and DNAME records during discovery. Subse= quent discussion has suggested that a different discovery approach would re= solve limitations inherent in the current approach. We have seen at least = two individual drafts on this topic. I would like to have the WG adopt a r= fc6844bis as a starting point. SHAKE Unlike the previous hashing standards, the SHA-3 functions are the outcome = of an open competition. They have a clear design rationale and have receiv= ed a lot of public analysis, resulting in great confidence that the SHA-3 f= amily of functions are very secure. Also, since the design of the SHA-3 fu= nctions use a very different construction from the SHA-2 functions, they of= fer an excellent alternative to the SHA-2 family of functions. In particular, SHAKE128/256 and SHAKE256/512 offer security = and performance benefits. We have not seen any individual drafts on this y= et. It seems to me that one draft is needed for PKIX and another draft is = needed for CMS and S/MIME. Is anyone willing to work on them? Russ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_MWHPR09MB1469ECAAFB1DCDDBBC2C229CF3580MWHPR09MB1469namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,

Since our group did not adopt SHA3s, I replaced them by SHAKE128 and SHAKE2= 56 (asked by Russ Housley: the chair) in this draft
https://tools.ietf.org/html/draf= t-housley-lamps-cms-sha3-hash-00, then generated a new draft poste= d at the link below. 


Since we use the SHAKEs, I specified KMAC for MAC.

Regards,
Quynh. 

From: Spasm <spasm-bou= nces@ietf.org> on behalf of Russ Housley <housley@vigilsec.com> Sent: Friday, September 15, 2017 3:43 PM
To: spasm@ietf.org
Subject: [lamps] Starting work to CAA and SHAKE
 
I have been discussing the recharter with EKR, and= he agrees that we should get started on this work even though the LAMPS re= -charter is blocked on a bit of process.

Having completed the S/MIME 4.0 specifications and updates to support i18n = email addresses in PKIX certificates, the LAMPS WG is now ready to work on = two additional topics:

1. Specify a discovery mechanism for CAA records to replace the one describ= ed in RFC 6844.

2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME.
Other topics can be considered when these two are progressing.


CAA

RFC 6844 describes the mechanism by which CAA records relating to a domain = are discovered.  Implementation experience has demonstrated an ambigui= ty in the current processing of CNAME and DNAME records during discovery.&n= bsp; Subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in the c= urrent approach.  We have seen at least two individual drafts on this = topic.  I would like to have the WG adopt a rfc6844bis as a starting p= oint.


SHAKE

Unlike the previous hashing standards, the SHA-3 functions are the outcome = of an open competition.  They have a clear design rationale and have r= eceived a lot of public analysis, resulting in great confidence that the SH= A-3 family of functions are very secure.  Also, since the design of the SHA-3 functions use a very different constru= ction from the SHA-2 functions, they offer an excellent alternative to the = SHA-2 family
of functions.  In particular, SHAKE128/256 and SHAKE256/512 offer secu= rity and performance benefits.  We have not seen any individual drafts= on this yet.  It seems to me that one draft is needed for PKIX and an= other draft is needed for CMS and S/MIME.  Is anyone willing to work on them?

Russ
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--_000_MWHPR09MB1469ECAAFB1DCDDBBC2C229CF3580MWHPR09MB1469namp_-- From nobody Sun Oct 29 11:43:58 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639B013FAE6 for ; Sun, 29 Oct 2017 11:43:56 -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 EVRhBpcZipoq for ; Sun, 29 Oct 2017 11:43:55 -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 7D99F13FAEF for ; Sun, 29 Oct 2017 11:43:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A278B300538 for ; Sun, 29 Oct 2017 14:43:27 -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 HkTrT2xGH6GQ for ; Sun, 29 Oct 2017 14:43:26 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id A7F9830026A for ; Sun, 29 Oct 2017 14:43:26 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <333DB589-796A-462F-BBE9-EDF8E83E3CD9@vigilsec.com> Date: Sun, 29 Oct 2017 14:43:26 -0400 To: SPASM X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lamps] DRAFT Agenda for Singapore X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 18:43:56 -0000 Please review and comment on the draft agenda. Russ = = = = = = = = = LAMPS WG Agenda at IETF 100 Russ Housley cannot attend the Meeting in Singapore. Jim Schaad will chair this session. 0) Minute Taker, Jabber Scribe, Bluesheets 1) Agenda Bash 2) Issues related to documents that have been sent to the IESG a) draft-ietf-lamps-rfc5280-i18n-update (Jim) b) draft-ietf-lamps-eai-addresses (Alexey and Wei) c) draft-ietf-lamps-rfc5750-bis (Jim) d) draft-ietf-lamps-rfc5751-bis (Jim) 3) Next work items a) rfc6844bis (Phillip) b) Adding SHAKE to PKIX and CMS (Quynh and Panos) 4) Wrap Up From nobody Mon Oct 30 12:51:58 2017 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DCF13FB21; Mon, 30 Oct 2017 12:51:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150939311439.7698.15412012018417152953@ietfa.amsl.com> Date: Mon, 30 Oct 2017 12:51:54 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 19:51:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Put Your Internet Draft Title Here Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-pkix-shake-00.txt Pages : 7 Date : 2017-10-30 Abstract: This document describes the conventions for using the SHAKE family of hash functions in the Internet X.509 PKI as one-way hash functions with the RSA, DSA and ECDSA signature algorithms; the conventions for the associated subject public keys are also described. Digital signatures are used to sign messages, certificates and CRLs (Certificate Revocation Lists). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-pkix-shake/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-pkix-shake-00 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 14:42:49 2017 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874B513FBCA for ; Mon, 30 Oct 2017 14:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 qv23MWdrvvga for ; Mon, 30 Oct 2017 14:42:47 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D846513FBB7 for ; Mon, 30 Oct 2017 14:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2033; q=dns/txt; s=iport; t=1509399766; x=1510609366; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kMKEKCLdwPffYLczMOKzWN7JKPkkcKwk1D8GjfBBEPw=; b=Vrn+xHeBiJovGJvKfWbjdyzgQenc/M2oEuKJeaiCCN03ZDANIR3/gijZ 3G35rEFRFWNQnO9YBJEpeU1eVi2B2xqJPEiWAiFxugeoXM+9HlqK1aZZk cz0zrU5UG5DsiyaoIyAwDpKNV/oJpxIQp0LpXv1nfC/Kv2xi9vwlVdhTE o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAACEm/dZ/4wNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbicHjhSPEoF8lkKCEQoYC4UYAoRfPxgBAgEBAQEBAQFrHQu?= =?us-ascii?q?FHQEBAQQBATg0FwQCAQgRBAEBHwkHJwsUCQgCBBMIihsQqmOLBgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2DLoIHgVOBaYMqhGqGHQWiAwKHZI0Ngh5ehSKLGIxfiQQ?= =?us-ascii?q?CERkBgTgBHziBaHoVHyqCZAmCUh2BZ3eKCIEzgREBAQE?= X-IronPort-AV: E=Sophos;i="5.44,321,1505779200"; d="scan'208";a="24317049" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Oct 2017 21:42:46 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v9ULgkx7024083 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 30 Oct 2017 21:42:46 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 30 Oct 2017 16:42:45 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1320.000; Mon, 30 Oct 2017 16:42:45 -0500 From: "Panos Kampanakis (pkampana)" To: "spasm@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-00.txt Thread-Index: AQHTUbiZFe9pbiYYOEe7E5bqCNHWGaL80VrA Date: Mon, 30 Oct 2017 21:42:45 +0000 Message-ID: <4bd160fc96704ac59b0ba28ad5bd8145@XCH-ALN-010.cisco.com> References: <150939311439.7698.15412012018417152953@ietfa.amsl.com> In-Reply-To: <150939311439.7698.15412012018417152953@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.108.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 21:42:48 -0000 Hi all,=20 This is the first iteration of the draft that introduces SHAKE to PKIX. It = is by no means complete. We have multiple EDNOTES in it that hopefully stir= discussions among the group. Feedback is welcome. Thank you, Panos -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Monday, October 30, 2017 3:52 PM To: i-d-announce@ietf.org Cc: spasm@ietf.org Subject: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Limited Additional Mechanisms for PKIX and= SMIME WG of the IETF. Title : Put Your Internet Draft Title Here Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-pkix-shake-00.txt Pages : 7 Date : 2017-10-30 Abstract: This document describes the conventions for using the SHAKE family of hash functions in the Internet X.509 PKI as one-way hash functions with the RSA, DSA and ECDSA signature algorithms; the conventions for the associated subject public keys are also described. Digital signatures are used to sign messages, certificates and CRLs (Certificate Revocation Lists). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-pkix-shake/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-pkix-shake-00 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake-00 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm