From nobody Sat Jun 1 03:30:32 2019 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 66413120257 for ; Sat, 1 Jun 2019 03:30:30 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=px7wCubK; dkim=pass (1024-bit key) header.d=primekey.com header.b=qOmq/sHW 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 2q9FZL75XLG4 for ; Sat, 1 Jun 2019 03:30:28 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8B71200F7 for ; Sat, 1 Jun 2019 03:30:27 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id EE1D66AA0092 for ; Sat, 1 Jun 2019 12:30:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1559385021; bh=aRmCnU+Omfl+pSwAuwpHCT3Y8UpPotqHdo7yCdG7BC0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=px7wCubKzX8SQTJCCbYS39TO84OjK4Ma6Bbh9zluBWNKQmJ5k4WidXQBmVXgr/PGh Ze4SXcOV1PwgC3Jq0PArqe+HJV8qNAx723N98Qv/AvH6n7j4V6MWcfrgUkvBntP9+B qdMHdN4x9EcAARv2kvm+b4X+IOQeSxAzwNTp1jB4= Received: from [192.168.1.100] (c-b21fac9c-74736162.cust.telenor.se [178.31.172.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id B32446AA0091 for ; Sat, 1 Jun 2019 12:30:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1559385020; bh=aRmCnU+Omfl+pSwAuwpHCT3Y8UpPotqHdo7yCdG7BC0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=qOmq/sHWDc9QEQDTUAIILOvgmX3ZzLqTq3y8YCj7C6Vn/sLfayhmpveIMMXhcAhy4 R1nejSyp1xcHg/ZXyFrstRUF5wyK0FeILJgI5zdHD9QkVSPl73xh3YRYBp0SUhAMyp mQI9vmES0Zb0LZOC7EKZUXpuuJYr5MrYJT4znpuA= To: spasm@ietf.org References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> From: Tomas Gustavsson Openpgp: preference=signencrypt Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= mQENBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAG0MFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPokB NwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5uQENBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAGJAR8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: Date: Sat, 1 Jun 2019 12:30:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <12129.1559329924@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] Support for working on the lightweight CMP profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 01 Jun 2019 10:30:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2019-05-31 21:12, Michael Richardson wrote: > > Peylo, Martin (Nokia - FI/Espoo) wrote: >> One should note that the subject of this email seems to be >> somewhat misleading as it is overly limiting the scope. I expect >> that besides clarifications for e.g. RA-CA communications, the >> upcoming work will also include a refresh of mandatory algorithms >> (bye bye SHA-1). While both of those will certainly be beneficial >> also for the lightweight CMP on the interface to EEs, it will >> also have positive influence beyond the "lightweight CMP" scope. > > I think that updating algorithms almost goes without saying, but > it's good you said it. > >>> Plus we have a bunch of proprietary RESTful interfaces to CAs. > >> As they are proprietary, they seem to be somewhat out of IETF >> scope and interoperability might not have been your focus when >> you were creating those? > > The point is, if I have to support a proprietary interface to some > CA, is there an advantage to also supporting a standard lightweight > CMP if talking to the CA vendor still requires the proprietary > RESTful interface. I am expected one or two of those to become > defacto specifications, the way the AWS EC2 API did. You may want to support CMP towards the client, but use the CAs native API on that side. We've had several customers using CMP where the benefit has been that they have been able to migrate from one CA software to another (CA software in our case). By implementing standard APIs like EST and CMP we bring this forward as a benefit of less lock-in effects, customers can choose to replace us if they want. And we have seen this non-lock-in work in reality. (ps: I am the author of a Certificate Authority software product, just technology no CA service) (REST APIs is a very interesting topic and deserve a separate thread imho. We btw also have ACME as standardizes enrollment protocol for another subset of functionality. I'll start a separate topic on this.) > (ps: I am the author of a Registration Authority product) > > -- Michael Richardson , Sandelman Software > Works -= IPv6 IoT consulting =- > > > > > _______________________________________________ Spasm mailing list > Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJc8lO5AAoJEGJtxJsAQ/5AbNoIANmGojU5ygArzIzFeiTbcth+ XJGWJ6b23Vlgop7CG9qsyBkAfiheTZ3uLOtFBaqsE8RE5WwZqj6Q3cyhowPMX/o/ UTRXtNLaAGrbfQAdaaE17o3yvcv3WIU58g3J180y/3txHEdHalR4OgUayFTBjYdp sfFUHGT3DmZfDvXQVM5XQ45BbBoSpxYvKGzxzwPfg/lDclDNeFLAA/hoAuYuKMyW jrPQEgqEqdC2hmWX9FvOTHN0ev0SBPCXMDbADUjlPUrJ8HSy/wa4oZp3R7kyMrOR 4zjTx6jGIizisTdk9FF4yWKdJlACyk9BcFILpjpH61A6tOKesaTI/P9XqJRm7Tg= =N2CX -----END PGP SIGNATURE----- From nobody Sat Jun 1 04:53:44 2019 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 C9E64120221 for ; Sat, 1 Jun 2019 04:53:42 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=nMM4ipSx; dkim=pass (1024-bit key) header.d=primekey.com header.b=nMM4ipSx 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 X1-lf6QDsGln for ; Sat, 1 Jun 2019 04:53:41 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A194112004C for ; Sat, 1 Jun 2019 04:53:40 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id D0E566AA0092 for ; Sat, 1 Jun 2019 13:53:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1559390013; bh=Wsulez0wiL0QnXadX2HtUQmU8MXa4rMQMAQaBVTtM5M=; h=Subject:To:References:From:Date:In-Reply-To:From; b=nMM4ipSxqoPxCAwo1x+8f1Q1fiK26Yw61qX0oI9TNA+kUOO1k1W0/n1S5lVNZnix7 4NwxO/1nfhkzEb91Zfah75ShxwFPCooJU1TXRqcAmIM5FPmD4nOvqoAp2XKegW3QhO PLwnyakVAGK31z2HyvoCAGMhNTB23poUvpGvtjUo= Received: from [10.11.0.5] (gatekeeper.primekey.se [84.55.121.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 8D0926AA0091 for ; Sat, 1 Jun 2019 13:53:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1559390013; bh=Wsulez0wiL0QnXadX2HtUQmU8MXa4rMQMAQaBVTtM5M=; h=Subject:To:References:From:Date:In-Reply-To:From; b=nMM4ipSxqoPxCAwo1x+8f1Q1fiK26Yw61qX0oI9TNA+kUOO1k1W0/n1S5lVNZnix7 4NwxO/1nfhkzEb91Zfah75ShxwFPCooJU1TXRqcAmIM5FPmD4nOvqoAp2XKegW3QhO PLwnyakVAGK31z2HyvoCAGMhNTB23poUvpGvtjUo= To: spasm@ietf.org References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> From: Tomas Gustavsson Openpgp: preference=signencrypt Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= mQENBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAG0MFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPokB NwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5uQENBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAGJAR8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> Date: Sat, 1 Jun 2019 13:53:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <12129.1559329924@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 01 Jun 2019 11:53:43 -0000 Hi, This is a continuation of a topic that appeared in another thread, that I chose to start another thread about to not diverge the original thread. (original thread [lamps] Support for working on the lightweight CMP profile). Consider this an exploratory discussion. - Background: Today RESTful APIs are popular due to the simplicity of implementation on the client and on the server. I myself has worked with implementation on servers and clients for a range of standard APIs (such as SCEP, CMP, EST, ACME, PKCS#11 and more). I also find REST APIs engaging to work with as you don't need any special client software. If implementing in Java you just go at it with the standard API, if scripting you just use curl, etc. You also typically get easy to parse error messages back in JSON format. Very nice and easy. - Benefits of standard APIs Using standard APIs you get less lock-in effects. Less lock-in is typically good for the whole industry and use base long-term. Using standard APIs an end user can replace various components (clients, RA, CA) in their system to other vendors if they so desire. We have seen this work in practice, replacing CA technology components transparently for the rest of the system, quick and cost effective. IETF has been very good at producing industry wide standards used across multiple verticals. - Current REST-like protocols In lamps/pkix we have a couple of RESTlike APIs today. ACME for enrolling server certificates. A protocol for a specific purpose, but gaining popularity due to the easiness of implementing clients (often as scripts). EST is perhaps not a strict REST API but can be used in a similar form on the client side. All you need is openssl and curl to use it from the client side. - Current limitations In many deployments there are three components: client - RA - CA. EST and ACME typically runs on the client-RA side. EST also runs on the RA-CA side in simpler use cases. For more complex use cases, where say revocation is also needed it's more common to use CMP or a proprietary SOAP or REST API on the RA-CA side. Just to make this single point, the current REST-like APIs does not have revoke (EST has full-CMC method but that makes it complete non-REST-like and harder to implement). - Current "full" REST APIs Various products have REST APIs. These are proprietary (completely natural as there are no standards) and thus clients/RAs/CAs suffer from having to implements multiple REST APIs in order to be interoperable with various vendors. - Probe: Do others see the need/interest to standardize a more "full" REST API? We see requests and customer interest for REST APIs. Some of the requested REST functionality could very well be standardized, while some are more product specific and could be harder. Do others see the same? - Disclosure: I work for PrimeKey, a vendor who implements the (open source) CA software EJBCA. Regards, Tomas From nobody Mon Jun 3 07:36:22 2019 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 D62161202A4 for ; Mon, 3 Jun 2019 07:36:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.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 bovmZORUqclq for ; Mon, 3 Jun 2019 07:36:18 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70071.outbound.protection.outlook.com [40.107.7.71]) (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 054151201F0 for ; Mon, 3 Jun 2019 07:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector2-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ewOmFzoiPJOLFdPZwS4vxihyRpJbBxrshZ9UBih8F/M=; b=I3UacAG+LUrTg/ELXE9AWDrxCDbSdbx/eyOHRTTWJhV2tSoNENjj1c8EavpCgEFteOteDOF+o2eRaxT0hEPPsbkNH82sePTTFRl+WbtL6o/1GWUWmXMH+o4aX0MoSQN/qN+b3dhNsae763lWWifn/8zJE/1Cqh2o2vhuzGsxol4= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB1921.EURPRD10.PROD.OUTLOOK.COM (52.133.63.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.22; Mon, 3 Jun 2019 14:36:15 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a1d3:2a6c:c2ff:2fa3]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a1d3:2a6c:c2ff:2fa3%7]) with mapi id 15.20.1943.018; Mon, 3 Jun 2019 14:36:15 +0000 From: "Brockhaus, Hendrik" To: Michael Richardson , Tomas Gustavsson CC: "spasm@ietf.org" Thread-Topic: [lamps] Support for working on the lightweight CMP profile Thread-Index: AQHVFKwRAY7BM8QHd068AUQyGlLtFqaAoW+AgACA9wCAAH+/gIAAS0EAgAOxrICABGmucA== Date: Mon, 3 Jun 2019 14:36:15 +0000 Message-ID: References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <11176.1559329699@localhost> In-Reply-To: <11176.1559329699@localhost> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [80.146.228.69] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4c14627c-12d2-4d1a-1b5f-08d6e830d560 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR10MB1921; x-ms-traffictypediagnostic: AM0PR10MB1921: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-forefront-prvs: 0057EE387C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(39860400002)(376002)(366004)(396003)(189003)(199004)(7736002)(316002)(110136005)(68736007)(558084003)(81156014)(66066001)(446003)(81166006)(8676002)(305945005)(8936002)(11346002)(476003)(33656002)(76176011)(14454004)(71190400001)(486006)(478600001)(71200400001)(6436002)(7696005)(2906002)(256004)(66476007)(102836004)(186003)(26005)(64756008)(55016002)(53936002)(66556008)(66446008)(9686003)(6506007)(5660300002)(73956011)(3846002)(66946007)(86362001)(52536014)(76116006)(25786009)(74316002)(99286004)(4326008)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB1921; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: g3afC5ElH0auByrSdjEKb4bAaPyxIjAsrKMBK3HL0JCS7KpM+31ANe1l1mBwzCOmxGLdKaZV6dXzwnusPrjZ262whhsd9XZPoFRdYrxOD23volOxBHpW443RLtfsCdpaaPaNvD3Fx2Jlm5hySuwQXNUEniL0JbSscJ+rAeK5gc3OrkysKqUBai3g3rZkxW+sg4B6vrd7uGQocCDaK87PjTm9iwEw4gU3xuGOzodAP9QdiJEk5TmadmiLq5xdScU27rtCTIFcHDQyqTV5eHZvrgExW+ga1u5Pm6TzIfU3PVOJXHO4w4+r0GfeDLjLxxRTOvCcKd1bzuOwTWCnZWGDi1N1rBVB61P53HFXcs2OdPUBVj0oZ0xMupEMUCLi/+KzdNwPI+aLM25ig+Z13mTAE7Tw2FAXfmILYqPzZLv5G1I= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c14627c-12d2-4d1a-1b5f-08d6e830d560 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2019 14:36:15.3814 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hendrik.brockhaus@siemens.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB1921 Archived-At: Subject: Re: [lamps] Support for working on the lightweight CMP profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 03 Jun 2019 14:36:21 -0000 > Von: Spasm Im Auftrag von Michael Richardson > Gesendet: Freitag, 31. Mai 2019 21:08 >=20 > Based upon your comments, I will change my view, and offer support for > lightweight CMP. >=20 Thanks to Tomas for his good explanation and to Michael for changing his vi= ew :-) Hendrik From nobody Mon Jun 3 11:33:31 2019 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 88ACB1201D0 for ; Mon, 3 Jun 2019 11:33:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sftnkvx17Puv for ; Mon, 3 Jun 2019 11:33:27 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B88B512007C for ; Mon, 3 Jun 2019 11:33:27 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x53IXQTX020116 for ; Mon, 3 Jun 2019 14:33:26 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x53IXQTX020116 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1559586806; bh=QdQob1IwUfXm6EFwcVvAEsy01pwm0D4P0FWpwTSsbms=; h=From:To:Subject:Date:From; b=fySPCx+9lXDOmg3BqZiQFs8DwXRt3cSGkWExX5qzhi6Uga0DRa6JOaeqNEnz3Eoqh vhwTLRfHvfOoIwCqmzwDT9RITup0c9eKOXX8/75J2y7vXPf5VRcYlgoicP8Ztx1/+y I686QBG/jXT9jgKNaAU7FcZ+rqx8DqFVYATcw1gU= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x53IXMK8008893 for ; Mon, 3 Jun 2019 14:33:22 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Mon, 3 Jun 2019 14:33:22 -0400 From: Roman Danyliw To: "spasm@ietf.org" Thread-Topic: Second AD Review: draft-ietf-lamps-pkix-shake-10 Thread-Index: AdUaOicKPUSplJFAQJW7VEoVRR7HXg== Date: Mon, 3 Jun 2019 18:33:22 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B338267A@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lamps] Second AD Review: draft-ietf-lamps-pkix-shake-10 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 03 Jun 2019 18:33:30 -0000 Hi! As a document I inherited in the "IESG:: Waiting for Writeup Internet-Draft= s", I conducted a second AD review on draft-ietf-lamps-pkix-shake-10. I ha= ve the following feedback: (1) Header. Per idnits: =3D=3D The 'Updates: ' line in the draft header = should list only the _numbers_ of the RFCs which will be updated by this do= cument (if approved); it should not include the word 'RFC' in the list. s/Updates: RFC3279/Updates: 3279/ (2) Additional References Needed (2.a) Section 2 And, the corresponding collision and second preimage resistance strengths for SHAKE256 are min(d/2,256) and min(d,256) bits respectively. Recommend you cite Section A.1 of [SHA3] as the source of these security st= rength metrics. (2.b) Section 2 A SHAKE can be used as the message digest function (to hash the message to be signed) in RSASSA-PSS and ECDSA and as the hash in the mask generating function in RSASSA-PSS. Provide a reference on first use for RSASSA-PSS [RFC8017] and ECDSA [X9.62] (3) Editorial (3.a) Section 5.1 In an X.509 certificate a signature is encoded with an algorithm identifier in the signatureAlgorithm attribute and a signatureValue that contains the actual signature. s/signatureValue/signatureValue attribute/ (3.b) Section 5.1.1. Add commas between terms. =20 s/hash and mask generating algorithm and trailer and salt are embedded in t= he OID definition/ hash, mask generating algorithm, trailer and salt are embedded in the OID d= efinition/ (3.c) Section 5.1.1. Define the acronym MGF on first use s/mask generation function/mask generation function (MGF)/ (3.d) Section 5.1. Duplicate word. s/section Section 4/Section 4/ (4) Section 5.1. The ASN.1 blob of Certificate is inserted in the text wit= hout citation or explanation. It seems like the paragraph prior to it shou= ld make explicit reference to it (as it cites the elements). (5) Section 5.1. They MAY also generate such signatures in accordance with all other recommendations in [X9.62] or [SEC1] if they have a stated policy that requires conformance to these standards. These standards may have not specified SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE128 and SHAKE256 with output length being 32 and 64 octets respectively are substitutions for 256 and 512-bit output hash algorithms such as SHA256 and SHA512 used in the standards. I recommend being more precise in this text. s/These standards may have not specified SHAKE128 and SHAKE256 as hash algo= rithm options./ These standards have not specified SHAKE128 and SHAKE256 as hash algorithm = options./ Per "SHAKE128 and SHAKE256 with output length being 32 and 64 octets respec= tively are substitutions for ... SHA256 and SHA 512", what does substitutio= ns mean in this case? Similar output size or cryptographic strength? Regards, Roman From nobody Mon Jun 3 23:14:45 2019 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 DDA1B120139 for ; Mon, 3 Jun 2019 23:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 xXm3E2GGfOdA for ; Mon, 3 Jun 2019 23:14:41 -0700 (PDT) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E551200A4 for ; Mon, 3 Jun 2019 23:14:41 -0700 (PDT) Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id 5A34C1F146BA for ; Tue, 4 Jun 2019 08:05:00 +0200 (CEST) Received: from s499.loopia.se (unknown [172.21.200.97]) by s554.loopia.se (Postfix) with ESMTP id 3A5CE794051; Tue, 4 Jun 2019 08:05:00 +0200 (CEST) Received: from s470.loopia.se (unknown [172.21.200.36]) by s499.loopia.se (Postfix) with ESMTP id 2CCDB1349A45; Tue, 4 Jun 2019 08:05:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s499.loopia.se ([172.22.191.6]) by s470.loopia.se (s470.loopia.se [172.22.190.10]) (amavisd-new, port 10024) with UTF8LMTP id oah77E4YsWkz; Tue, 4 Jun 2019 08:04:59 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: 85.235.7.89 Received: from [192.168.2.38] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s499.loopia.se (Postfix) with ESMTPSA id F40A21349A47; Tue, 4 Jun 2019 08:04:58 +0200 (CEST) User-Agent: Microsoft-MacOutlook/10.19.0.190512 Date: Tue, 04 Jun 2019 08:04:58 +0200 From: Stefan Santesson To: Tim Hollebeek , Jacob Hoffman-Andrews , "secdir@ietf.org" CC: "spasm@ietf.org" , "ietf@ietf.org" , "draft-ietf-lamps-rfc6844bis.all@ietf.org" Message-ID: <8AD60BC4-4A2D-4A13-BED5-B12E0E0FE42B@aaa-sec.com> Thread-Topic: Secdir last call review of draft-ietf-lamps-rfc6844bis-06 References: <155917666691.9144.10382733252232760132@ietfa.amsl.com> <3f60c58a-7923-d5da-e500-052588a294fb@eff.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [lamps] Secdir last call review of draft-ietf-lamps-rfc6844bis-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 04 Jun 2019 06:14:43 -0000 Sounds great.=20 I just made a note. I do not call for any change. Stefan Santesson=20 =EF=BB=BFOn 2019-05-30, 20:40, "Tim Hollebeek" wrote= : Just to make it official, I'm the chair of the Validation Subcommittee = of the=20 Server Certificate Working Group of the CA/Browser Forum, and I intend = to=20 submit a ballot to make RFC 6844bis mandatory in the event it is publis= hed as=20 an IETF RFC. =20 -Tim =20 > -----Original Message----- > From: Jacob Hoffman-Andrews > Sent: Thursday, May 30, 2019 2:30 PM > To: Stefan Santesson ; secdir@ietf.org > Cc: spasm@ietf.org; ietf@ietf.org; draft-ietf-lamps-rfc6844bis.all@ie= tf.org > Subject: Re: Secdir last call review of draft-ietf-lamps-rfc6844bis-0= 6 > > On 5/29/19 5:37 PM, Stefan Santesson via Datatracker wrote: > > A common aspect of standards documents is that they only are releva= nt > > to those who declare compliance to the standard. This document is > > different as it relies on that all parties (CA:s) are aware of this > > standard and performs the stipulated checks. > > In practice this has been stipulated for public CAs by the CA/Browser= Forum > Baseline Requirements since September 2017: > https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandator= y/. > > In other words, the CP for this particular community of trust incorpo= rates=20 > RFC > 6844, making it mandatory. The intent is that once RFC6844bis is=20 > standardized, > CA/Browser Forum will have a followup ballot incorporating it. =20 =20 From nobody Wed Jun 5 12:28:43 2019 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 B8D6B120192; Wed, 5 Jun 2019 12:28:34 -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.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <155976291465.22323.14886121908155552910@ietfa.amsl.com> Date: Wed, 05 Jun 2019 12:28:34 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-mix-with-psk-05.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jun 2019 19:28:35 -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 : Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-lamps-cms-mix-with-psk-05.txt Pages : 29 Date : 2019-06-05 Abstract: The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support the new algorithms, if the existing syntax does not accommodate them. In the near-term, this document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-mix-with-psk-05 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-mix-with-psk-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-mix-with-psk-05 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 Jun 5 12:30:55 2019 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 08BAB12021C for ; Wed, 5 Jun 2019 12:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 MWtWmkql6SLE for ; Wed, 5 Jun 2019 12:30:52 -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 0E7221201FA for ; Wed, 5 Jun 2019 12:30:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 134F1300ABA for ; Wed, 5 Jun 2019 15:11:34 -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 Kzc74vRfk7nr for ; Wed, 5 Jun 2019 15:11:32 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 90665300A9E for ; Wed, 5 Jun 2019 15:11:32 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 5 Jun 2019 15:30:49 -0400 References: <155976291465.22323.14886121908155552910@ietfa.amsl.com> To: SPASM In-Reply-To: <155976291465.22323.14886121908155552910@ietfa.amsl.com> Message-Id: <4C7F3E8C-301D-4726-907E-BFBEE945CDD3@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-mix-with-psk-05.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jun 2019 19:30:54 -0000 This new version adds a paragraph to the security considerations, and it = adds an acknowledgment to for the ProVerif proof that was posted last = week. Russ > On Jun 5, 2019, at 3:28 PM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : Using Pre-Shared Key (PSK) in the = Cryptographic Message Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-lamps-cms-mix-with-psk-05.txt > Pages : 29 > Date : 2019-06-05 >=20 > Abstract: > The invention of a large-scale quantum computer would pose a serious > challenge for the cryptographic algorithms that are widely deployed > today. The Cryptographic Message Syntax (CMS) supports key = transport > and key agreement algorithms that could be broken by the invention = of > such a quantum computer. By storing communications that are > protected with the CMS today, someone could decrypt them in the > future when a large-scale quantum computer becomes available. Once > quantum-secure key management algorithms are available, the CMS will > be extended to support the new algorithms, if the existing syntax > does not accommodate them. In the near-term, this document = describes > a mechanism to protect today's communication from the future > invention of a large-scale quantum computer by mixing the output of > key transport and key agreement algorithms with a pre-shared key. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-cms-mix-with-psk-05 > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-mix-with-psk-05= >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-mix-with-psk-05= >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 6 11:10:50 2019 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 BA8A6120128 for ; Thu, 6 Jun 2019 11:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 header.b=Pc+/QyXV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=p06ng50q 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 OnZ2U0tu-voS for ; Thu, 6 Jun 2019 11:10:46 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4DE612001E for ; Thu, 6 Jun 2019 11:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3738; q=dns/txt; s=iport; t=1559844646; x=1561054246; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ycPGW7g+2z3gBECcrGlm+SJknsSzPuZj1QFdOcGrwa8=; b=Pc+/QyXVUwDCbBIZ9+CxnkJeOEuJfI4YPNWlbjms+qzMeVhZNXmTiRh8 NA8xMaJJRbvLN9eIGCEckpfc3TAIVbitE0ZaWVp/wlHPNcAwIPHRIGCCG RGlvjANu3xELvoWvhG7BqF7HEvSvS1y4CrXS/BWhawvV47271di5uU9SP o=; IronPort-PHdr: =?us-ascii?q?9a23=3A0UmVZRRaWEmfxe8o4qXYSMM2Fdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQ5FcFaXVls13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAAC0Vvlc/5tdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBPSQsA2pVIAQLKAqHUQOEUooMSoINlzGBLoE?= =?us-ascii?q?kA1QJAQEBDAEBGA0IAgEBhEACgmMjNAkOAQMBAQQBAQIBBG0cDIVKAQEBBAE?= =?us-ascii?q?BECgGAQEsDAsEAgEIDgMEAQEfECcLHQgBAQQBEggagwGBagMdAQIMnDwCgTi?= =?us-ascii?q?IX4IignkBAQWEfhiCDwMGgTQBi1oXgUA/gRFGgkw+gmEBAYFjgzqCJqkdCQK?= =?us-ascii?q?CDoZDjRWXCI0OhxKPHgIEAgQFAg4BAQWBTziBWHAVO4Jsgg8LAReDTYUUhT9?= =?us-ascii?q?ygSmNNAGBIAEB?= X-IronPort-AV: E=Sophos;i="5.63,560,1557187200"; d="scan'208";a="558756095" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jun 2019 18:10:45 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x56IAj4Z008584 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Jun 2019 18:10:45 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 6 Jun 2019 13:10:44 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 6 Jun 2019 13:10:43 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 6 Jun 2019 13:10:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BiExjr6wdjDRQI1ZWlsYLYf8SzKAOACintxl+e8O/X0=; b=p06ng50qVoyA0IJmwYPyr5iST4LhhcjqoO+9Oaz6mi5PBAMHYv7N5bqRBA1pdY36MrnIdGTO3kFw0oDI6uqvgBWlU5O/wOTS1v6x48Oi6D9E6GbBrYy0d+n15xyRZIKui+bIGRuFvQE4wnBlX+xEjBAqLH2E1IDP2oWd3/9rfdI= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.244.29) by BN7PR11MB2627.namprd11.prod.outlook.com (52.135.245.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.12; Thu, 6 Jun 2019 18:10:41 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::89af:3fb4:eae5:18b2]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::89af:3fb4:eae5:18b2%7]) with mapi id 15.20.1965.011; Thu, 6 Jun 2019 18:10:41 +0000 From: "Panos Kampanakis (pkampana)" To: Roman Danyliw , "spasm@ietf.org" Thread-Topic: Second AD Review: draft-ietf-lamps-pkix-shake-10 Thread-Index: AdUaOicKPUSplJFAQJW7VEoVRR7HXgCWLijA Date: Thu, 6 Jun 2019 18:10:41 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01B338267A@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B338267A@marathon> 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=pkampana@cisco.com; x-originating-ip: [64.102.57.107] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c1ef656d-1120-4cf9-c12a-08d6eaaa498c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BN7PR11MB2627; x-ms-traffictypediagnostic: BN7PR11MB2627: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 00603B7EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(39860400002)(396003)(136003)(199004)(189003)(13464003)(478600001)(14454004)(6246003)(8676002)(476003)(966005)(3846002)(7736002)(186003)(316002)(55016002)(81166006)(66574012)(229853002)(446003)(486006)(86362001)(33656002)(9686003)(11346002)(81156014)(53936002)(52536014)(25786009)(74316002)(110136005)(6306002)(71200400001)(7696005)(305945005)(71190400001)(66476007)(64756008)(76116006)(99286004)(66556008)(66946007)(73956011)(66446008)(2906002)(102836004)(68736007)(26005)(2501003)(6506007)(256004)(6436002)(8936002)(53546011)(76176011)(5660300002)(14444005)(66066001)(6116002)(11771555001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2627; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: VVT5WDqU0WUOWiPM9IdYori0Aupy1hsSqYVRjy/6/U7Fsv/sI2YDkl9YgHl4PO+BNf+JvPfLlFKAsGA7KK8+Y+5OBynpbLvm5RQigXdPtZG3WA1P0Yl3cM208hD3j4NFyMnK+DRyGSf5tXggqncvpAt16lUfwXqzyOEe11U6pvwd3U0ckgihJPznVNuH0pvfMI1GsKeeRNhGRsnk4OdkWYqSw4QOvELQNXm9TAuP0VqVh+Db7oAmUF6jkIrpgbjVi/oMvQ8FLl5sG+O6JYVADDUbaHzW5K8/1ktMMl2PoEycBEv6Fsc9DVfmnZkped+R5eN5UqZH+5CMwOBKjyc5ztplOkEJLh/3XjsvAIv/SJGjscaCeJ7CVN5FwCarcupGQwuFDxlQ9VPNnTkzxOfmL1frRUXsUveq0uYYvHsUE6c= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c1ef656d-1120-4cf9-c12a-08d6eaaa498c X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2019 18:10:41.7185 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkampana@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2627 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [lamps] Second AD Review: draft-ietf-lamps-pkix-shake-10 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jun 2019 18:10:49 -0000 Thank you Roman. They are all addressed in the latest version https://githu= b.com/csosto-pk/adding-shake-to-pkix/blob/master/draft-ietf-lamps-pkix-shak= e-current.txt The log of the actions take in regards to every individual co= mment is here https://github.com/csosto-pk/adding-shake-to-pkix/issues/44=20 I am planning to upload the next iteration next Monday unless there is more= feedback. Panos -----Original Message----- From: Spasm On Behalf Of Roman Danyliw Sent: Monday, June 03, 2019 2:33 PM To: spasm@ietf.org Subject: [lamps] Second AD Review: draft-ietf-lamps-pkix-shake-10 Hi! As a document I inherited in the "IESG:: Waiting for Writeup Internet-Draft= s", I conducted a second AD review on draft-ietf-lamps-pkix-shake-10. I ha= ve the following feedback: (1) Header. Per idnits: =3D=3D The 'Updates: ' line in the draft header = should list only the _numbers_ of the RFCs which will be updated by this do= cument (if approved); it should not include the word 'RFC' in the list. s/Updates: RFC3279/Updates: 3279/ (2) Additional References Needed (2.a) Section 2 And, the corresponding collision and second preimage resistance strengths for SHAKE256 are min(d/2,256) and min(d,256) bits respectively. Recommend you cite Section A.1 of [SHA3] as the source of these security st= rength metrics. (2.b) Section 2 A SHAKE can be used as the message digest function (to hash the message to be signed) in RSASSA-PSS and ECDSA and as the hash in the mask generating function in RSASSA-PSS. Provide a reference on first use for RSASSA-PSS [RFC8017] and ECDSA [X9.62] (3) Editorial (3.a) Section 5.1 In an X.509 certificate a signature is encoded with an algorithm identifier in the signatureAlgorithm attribute and a signatureValue that contains the actual signature. s/signatureValue/signatureValue attribute/ (3.b) Section 5.1.1. Add commas between terms. =20 s/hash and mask generating algorithm and trailer and salt are embedded in t= he OID definition/ hash, mask generating algorithm, trailer and salt are em= bedded in the OID definition/ (3.c) Section 5.1.1. Define the acronym MGF on first use s/mask generation function/mask generation function (MGF)/ (3.d) Section 5.1. Duplicate word. s/section Section 4/Section 4/ (4) Section 5.1. The ASN.1 blob of Certificate is inserted in the text wit= hout citation or explanation. It seems like the paragraph prior to it shou= ld make explicit reference to it (as it cites the elements). (5) Section 5.1. They MAY also generate such signatures in accordance with all other recommendations in [X9.62] or [SEC1] if they have a stated policy that requires conformance to these standards. These standards may have not specified SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE128 and SHAKE256 with output length being 32 and 64 octets respectively are substitutions for 256 and 512-bit output hash algorithms such as SHA256 and SHA512 used in the standards. I recommend being more precise in this text. s/These standards may have not specified SHAKE128 and SHAKE256 as hash algo= rithm options./ These standards have not specified SHAKE128 and SHAKE256 as= hash algorithm options./ Per "SHAKE128 and SHAKE256 with output length being 32 and 64 octets respec= tively are substitutions for ... SHA256 and SHA 512", what does substitutio= ns mean in this case? Similar output size or cryptographic strength? Regards, Roman _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Jun 7 08:54:05 2019 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 544921201EC for ; Fri, 7 Jun 2019 08:54:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oPHruGaJzQO for ; Fri, 7 Jun 2019 08:54:00 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 BCA9D120224 for ; Fri, 7 Jun 2019 08:53:20 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x57FrIOk010728; Fri, 7 Jun 2019 11:53:18 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x57FrIOk010728 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1559922798; bh=/OdjxHILaFIBGXDdaO3qWdZkYS47KpSr13zo8+FKUi8=; h=From:To:Subject:Date:References:In-Reply-To:From; b=Si+KAc/bKMNhJDhHFSX8mP4sULLluZu+Rkgg0lqoIZbDdypop6WLK/MC5zv1z0pF6 QtVj3NPc4KgoE6pUfOFkDlfBjOwPz9tayIWpiVXLUfiQ2ecUIOBZ84eHhWYt38h3bL inA4tTyM+iH+RIQEVZujc/P5kBcK/kGvi210Fkxk= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x57FqmMT004644; Fri, 7 Jun 2019 11:53:15 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Fri, 7 Jun 2019 11:53:00 -0400 From: Roman Danyliw To: "Panos Kampanakis (pkampana)" , "spasm@ietf.org" Thread-Topic: Second AD Review: draft-ietf-lamps-pkix-shake-10 Thread-Index: AdUaOicKPUSplJFAQJW7VEoVRR7HXgCWLijAAC19lfA= Date: Fri, 7 Jun 2019 15:52:59 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B338812D@marathon> References: <359EC4B99E040048A7131E0F4E113AFC01B338267A@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Second AD Review: draft-ietf-lamps-pkix-shake-10 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 07 Jun 2019 15:54:04 -0000 Hi Panos! The working revision below addresses all of my comments. Thank you for the= se changes (and for making them proactively in the CMS draft as applicable = too). Roman > -----Original Message----- > From: Panos Kampanakis (pkampana) [mailto:pkampana@cisco.com] > Sent: Thursday, June 06, 2019 2:11 PM > To: Roman Danyliw ; spasm@ietf.org > Subject: RE: Second AD Review: draft-ietf-lamps-pkix-shake-10 >=20 > Thank you Roman. They are all addressed in the latest version > https://github.com/csosto-pk/adding-shake-to-pkix/blob/master/draft-ietf- > lamps-pkix-shake-current.txt The log of the actions take in regards to ev= ery > individual comment is here https://github.com/csosto-pk/adding-shake-to- > pkix/issues/44 >=20 > I am planning to upload the next iteration next Monday unless there is mo= re > feedback. >=20 > Panos >=20 >=20 > -----Original Message----- > From: Spasm On Behalf Of Roman Danyliw > Sent: Monday, June 03, 2019 2:33 PM > To: spasm@ietf.org > Subject: [lamps] Second AD Review: draft-ietf-lamps-pkix-shake-10 >=20 > Hi! >=20 > As a document I inherited in the "IESG:: Waiting for Writeup Internet-Dra= fts", > I conducted a second AD review on draft-ietf-lamps-pkix-shake-10. I have > the following feedback: >=20 > (1) Header. Per idnits: =3D=3D The 'Updates: ' line in the draft heade= r should list > only the _numbers_ of the RFCs which will be updated by this document (if > approved); it should not include the word 'RFC' in the list. >=20 > s/Updates: RFC3279/Updates: 3279/ >=20 > (2) Additional References Needed >=20 > (2.a) Section 2 > And, the > corresponding collision and second preimage resistance strengths for > SHAKE256 are min(d/2,256) and min(d,256) bits respectively. >=20 > Recommend you cite Section A.1 of [SHA3] as the source of these security > strength metrics. >=20 > (2.b) Section 2 > A SHAKE can be used as the message digest function (to hash the > message to be signed) in RSASSA-PSS and ECDSA and as the hash in the > mask generating function in RSASSA-PSS. >=20 > Provide a reference on first use for RSASSA-PSS [RFC8017] and ECDSA [X9.6= 2] >=20 > (3) Editorial > (3.a) Section 5.1 > In an > X.509 certificate a signature is encoded with an algorithm identifier > in the signatureAlgorithm attribute and a signatureValue that > contains the actual signature. >=20 > s/signatureValue/signatureValue attribute/ >=20 > (3.b) Section 5.1.1. Add commas between terms. >=20 > s/hash and mask generating algorithm and trailer and salt are embedded in > the OID definition/ hash, mask generating algorithm, trailer and salt are > embedded in the OID definition/ >=20 > (3.c) Section 5.1.1. Define the acronym MGF on first use >=20 > s/mask generation function/mask generation function (MGF)/ >=20 > (3.d) Section 5.1. Duplicate word. s/section Section 4/Section 4/ >=20 > (4) Section 5.1. The ASN.1 blob of Certificate is inserted in the text w= ithout > citation or explanation. It seems like the paragraph prior to it should = make > explicit reference to it (as it cites the elements). >=20 > (5) Section 5.1. > They > MAY also generate such signatures in accordance with all other > recommendations in [X9.62] or [SEC1] if they have a stated policy > that requires conformance to these standards. These standards may > have not specified SHAKE128 and SHAKE256 as hash algorithm options. > However, SHAKE128 and SHAKE256 with output length being 32 and 64 > octets respectively are substitutions for 256 and 512-bit output hash > algorithms such as SHA256 and SHA512 used in the standards. >=20 > I recommend being more precise in this text. >=20 > s/These standards may have not specified SHAKE128 and SHAKE256 as hash > algorithm options./ These standards have not specified SHAKE128 and > SHAKE256 as hash algorithm options./ >=20 > Per "SHAKE128 and SHAKE256 with output length being 32 and 64 octets > respectively are substitutions for ... SHA256 and SHA 512", what does > substitutions mean in this case? Similar output size or cryptographic > strength? >=20 > Regards, > Roman >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Jun 7 10:23:01 2019 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 A642D120020 for ; Fri, 7 Jun 2019 10:22:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.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 0J2a9Da3iW1R for ; Fri, 7 Jun 2019 10:22:56 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on060d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::60d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5911912012D for ; Fri, 7 Jun 2019 10:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector2-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6XRG/Q7jYM0wvdrHx1NLe/RtwUydfdScvOUmMlK5Ww4=; b=C+WqBXoUbusE3Vhvz7qUKEqsp+mxmbzV5Wmaxm6ODyN4/W2eXK4vypaXMz2Wq3DN75LKsskyTOrPpsZl5bWJktfprA1pAN04dCsWWoBM55UI6O6UtLKgLA4w5AB+KSC8GyZxEYBP2gQgRTm1ydogGV8ZDNex/K8OvixLsYDWq8Q= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB2562.EURPRD10.PROD.OUTLOOK.COM (20.178.119.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.15; Fri, 7 Jun 2019 17:22:53 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a1d3:2a6c:c2ff:2fa3]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a1d3:2a6c:c2ff:2fa3%7]) with mapi id 15.20.1965.011; Fri, 7 Jun 2019 17:22:53 +0000 From: "Brockhaus, Hendrik" To: Tomas Gustavsson , "spasm@ietf.org" Thread-Topic: [lamps] Interest to standardize PKI REST APIs? Thread-Index: AQHVGHCvl8HgPTUm30+9zuWHsj3AZKaQehew Date: Fri, 7 Jun 2019 17:22:53 +0000 Message-ID: References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> In-Reply-To: <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [80.146.228.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 03effb07-a912-4315-41f3-08d6eb6cc666 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR10MB2562; x-ms-traffictypediagnostic: AM0PR10MB2562: x-ms-exchange-purlcount: 1 x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0061C35778 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(346002)(376002)(136003)(189003)(199004)(476003)(7696005)(66574012)(486006)(11346002)(99286004)(446003)(5660300002)(2501003)(53936002)(33656002)(68736007)(6506007)(26005)(25786009)(52536014)(186003)(256004)(2906002)(45080400002)(102836004)(66066001)(76176011)(14454004)(66446008)(66556008)(66946007)(64756008)(73956011)(76116006)(7736002)(66476007)(305945005)(110136005)(316002)(6306002)(6116002)(55016002)(3846002)(86362001)(71200400001)(71190400001)(9686003)(478600001)(966005)(81166006)(14444005)(81156014)(8936002)(6436002)(8676002)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB2562; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /Sw/7nLBYVSRcgR2VcmtjHJWxceDitYVoBJyhPwPIYOSKgWwtP/RDmTA7ziIpUZ4IPaKk/YZtwP5VJRw1zxGzPub7eM2rLcaYUb/fnk6+6vZbovbgtnpCKyIUpG/tmyy79s5P4c5QJ05XXZg5z5K8AB49iKe8vKTMtqi1xrQsvZiZEAhsJq/Yd61nNMFvf4RyQ7vjzNxj8a1rWoI1GlkMqpvFN1LtxTB+RnLFux72BNjt3FMS76c3uEVxkd2AC1CoNdLXGn4gf9dq6HQ6a+WZaLAUPceyqWPiu2DJcPMLiOF7YtUGiDnvuyQz66y2iaj3NHB32RA6DmzzI1yyLJVAVmB6BLxZspPh6Ud71MslCv7o31aDdLBSYa0OqjYQ8wHry2MVzjobsv8cZzq0dxbuanNqO3oz7Byq8DE2n8YcJA= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03effb07-a912-4315-41f3-08d6eb6cc666 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2019 17:22:53.5310 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hendrik.brockhaus@siemens.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2562 Archived-At: Subject: Re: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 07 Jun 2019 17:23:00 -0000 Hi Tomas I fully understand your pain implementing many different proprietary APIs a= nd I also dislike such proprietary APIs for certificate management. Typical= ly such proprietary APIs or protocols lack the desired security features a = certificate management protocol developed by an IETF Security WG offer. That is the reason to enhance the usability of existing standards like CMP.= This may also hold true for the request for RESTful APIs especially from c= loud developer. I think we need to first collect the required certificate management use ca= ses and check if they are addressed by existing protocols. Then I see two approaches: - Develop a new certificate management protocol using standard functionalit= y of REST frameworks and learn from or even copy parts from existing protoc= ols.=20 - Take an existing certificate management protocol, e.g. CMP, adapt the tra= nsport to REST APIs and adapt the transaction concept slightly to allow a s= tate-less server. As already said, I dislike to develop further certificate management protoc= ols. I think there are enough around already. Therefor I would prefer the s= econd approach. But finally the solution must be acceptable to the target a= udience of developers asking for REST APIs for certificate management. Are there also other opinions in the WG? Hendrik > -----Urspr=FCngliche Nachricht----- > Von: Spasm Im Auftrag von Tomas Gustavsson > Gesendet: Samstag, 1. Juni 2019 13:54 > An: spasm@ietf.org > Betreff: [lamps] Interest to standardize PKI REST APIs? >=20 > Hi, >=20 > This is a continuation of a topic that appeared in another thread, that I= chose > to start another thread about to not diverge the original thread. (origin= al > thread [lamps] Support for working on the lightweight CMP profile). Consi= der > this an exploratory discussion. >=20 > - Background: > Today RESTful APIs are popular due to the simplicity of implementation on > the client and on the server. I myself has worked with implementation on > servers and clients for a range of standard APIs (such as SCEP, CMP, EST, > ACME, PKCS#11 and more). I also find REST APIs engaging to work with as > you don't need any special client software. If implementing in Java you j= ust > go at it with the standard API, if scripting you just use curl, etc. You = also > typically get easy to parse error messages back in JSON format. Very nice= and > easy. >=20 > - Benefits of standard APIs > Using standard APIs you get less lock-in effects. Less lock-in is typical= ly good > for the whole industry and use base long-term. Using standard APIs an end > user can replace various components (clients, RA, > CA) in their system to other vendors if they so desire. We have seen this > work in practice, replacing CA technology components transparently for th= e > rest of the system, quick and cost effective. > IETF has been very good at producing industry wide standards used across > multiple verticals. >=20 > - Current REST-like protocols > In lamps/pkix we have a couple of RESTlike APIs today. > ACME for enrolling server certificates. A protocol for a specific purpose= , but > gaining popularity due to the easiness of implementing clients (often as > scripts). > EST is perhaps not a strict REST API but can be used in a similar form on= the > client side. All you need is openssl and curl to use it from the client s= ide. >=20 > - Current limitations > In many deployments there are three components: client - RA - CA. EST and > ACME typically runs on the client-RA side. EST also runs on the RA-CA sid= e in > simpler use cases. For more complex use cases, where say revocation is al= so > needed it's more common to use CMP or a proprietary SOAP or REST API on > the RA-CA side. Just to make this single point, the current REST-like API= s does > not have revoke (EST has full-CMC method but that makes it complete non- > REST-like and harder to implement). >=20 > - Current "full" REST APIs > Various products have REST APIs. These are proprietary (completely natura= l > as there are no standards) and thus clients/RAs/CAs suffer from having to > implements multiple REST APIs in order to be interoperable with various > vendors. >=20 > - Probe: > Do others see the need/interest to standardize a more "full" REST API? > We see requests and customer interest for REST APIs. Some of the > requested REST functionality could very well be standardized, while some = are > more product specific and could be harder. >=20 > Do others see the same? >=20 > - Disclosure: > I work for PrimeKey, a vendor who implements the (open source) CA > software EJBCA. >=20 > Regards, > Tomas >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww > .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D02%7C01%7Chendrik. > brockhaus%40siemens.com%7Cdf45bd27b9c241677a3a08d6e687d111%7C38a > e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636949868334006281& > sdata=3DrUYwh%2BPG4ZIdPzUYSWBOv1OvDb23N7fdHbyUOCup1dw%3D&am > p;reserved=3D0 From nobody Fri Jun 7 13:00:18 2019 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 1C4C8120092 for ; Fri, 7 Jun 2019 13:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Myub5IG71iPQ for ; Fri, 7 Jun 2019 13:00:14 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [209.87.249.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB823120140 for ; Fri, 7 Jun 2019 13:00:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 580F23818B for ; Fri, 7 Jun 2019 15:58:55 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 32DB2F60; Fri, 7 Jun 2019 16:00:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 30724B22 for ; Fri, 7 Jun 2019 16:00:12 -0400 (EDT) From: Michael Richardson To: "spasm\@ietf.org" In-Reply-To: References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 07 Jun 2019 20:00:16 -0000 --=-=-= Content-Type: text/plain Brockhaus, Hendrik wrote: > I think we need to first collect the required certificate management > use cases and check if they are addressed by existing protocols. I don't want to do that. It's boiling the ocean. I'm okay with making a list of RESTful APIs (proprietary ones, most of them have public specifications though), if only so that we know who to invite. > Then I see two approaches: > - Develop a new certificate management protocol using standard > functionality of REST frameworks and learn from or even copy parts from > existing protocols. sure, but: https://www.explainxkcd.com/wiki/index.php/927:_Standards > - Take an existing certificate management protocol, e.g. CMP, adapt the > transport to REST APIs and adapt the transaction concept slightly to > allow a state-less server. I think that this is what we should do. > As already said, I dislike to develop further certificate management > protocols. I think there are enough around already. Therefor I would > prefer the second approach. But finally the solution must be acceptable > to the target audience of developers asking for REST APIs for > certificate management. Good, we agree :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlz6wksACgkQgItw+93Q 3WVbdwf9E7YhY8lw/+k99EoMbrBOxyH3eGqpvZmtacZZef1v6NPUqLM8ecXffCmC 332WzWEXr4lrCc68TMqRrc0anV1jYTYb4sYTACAJS88RVykOBalnso328hrD7EwO YY3fNsImhYR+iJict/SIF1+XSzzhVKWCo4Ai30w5X/NdCoXLe104BSMtWQeg55iU OG0K1w0jklKQEK5E4MXypvwA9Z9YqI15Bpeu0wQaQKOQXeypCdeeBLtZQM2OfrIC u4eGvIqkH1b5zrtGg0TS/stngOsLqzvNy+5ugzlkWHJhgs6bclDClNUvxl20Bj7q K/+BZGTXVrcv4ndXhEBvHcmVEUU5xg== =GCU7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 9 09:43:38 2019 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 76AF21200B1 for ; Sun, 9 Jun 2019 09:43:36 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=cmSPPA1J; dkim=pass (1024-bit key) header.d=primekey.com header.b=LdAQd7F2 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 GqTHpUD5bDD4 for ; Sun, 9 Jun 2019 09:43:34 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA45A12008F for ; Sun, 9 Jun 2019 09:43:33 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 0E82F6AA0090 for ; Sun, 9 Jun 2019 18:43:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1560098606; bh=8udNaSmQgLRG32bq0gXeQLolkn+yhQQUaGBTcFWMeAY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=cmSPPA1Jof6I5uD1gTJoeSF/rDIyjgnmsT7GCvFbIdcj8cKF3bM3i/leOXmtszo3s doKzTdHsErKW51x/9PZPCkm35+EKeLqEsi9uDxru30/xNjpAfAAO/no/0w6O3IBUEn d8Hm2AlJtIUrAYTEcZq3c9tQs3v1fo4EjuvKmQb0= Received: from [192.168.43.22] (c-5eea2274-74736162.cust.telenor.se [94.234.34.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id B172A6AA0088 for ; Sun, 9 Jun 2019 18:43:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1560098605; bh=8udNaSmQgLRG32bq0gXeQLolkn+yhQQUaGBTcFWMeAY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=LdAQd7F2fYpbpK2YQeJYRxp1B9n2td9flvsFXzPqt9e/sSD8k5126rAyLxoOzdLBt XcPiFvrlBi3kjO+w62+4IVwAJd3HTxGy4EOj8LvW+vCdgEH8dyacxBlIVl+u9pfk8N wN7lzH2mgNGtGlkQNiIKCZuyKg9R3jcx2MBBUA2Y= To: spasm@ietf.org References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> <6992.1559937612@localhost> From: Tomas Gustavsson Openpgp: preference=signencrypt Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= mQENBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAG0MFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPokB NwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5uQENBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAGJAR8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <83b511c0-4047-9431-196b-9b4028ee726d@primekey.com> Date: Sun, 9 Jun 2019 18:43:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <6992.1559937612@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 09 Jun 2019 16:43:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2019-06-07 22:00, Michael Richardson wrote: > > Brockhaus, Hendrik wrote: >> I think we need to first collect the required certificate >> management use cases and check if they are addressed by existing >> protocols. > > I don't want to do that. It's boiling the ocean. > > I'm okay with making a list of RESTful APIs (proprietary ones, most > of them have public specifications though), if only so that we know > who to invite. > >> Then I see two approaches: - Develop a new certificate management >> protocol using standard functionality of REST frameworks and >> learn from or even copy parts from existing protocols. > > sure, but: > https://www.explainxkcd.com/wiki/index.php/927:_Standards > >> - Take an existing certificate management protocol, e.g. CMP, >> adapt the transport to REST APIs and adapt the transaction >> concept slightly to allow a state-less server. > > I think that this is what we should do. Thanks for the answers. The current protocol that is most "REST-like" imho is EST, if not using the "fullcmc" functionality. You can maneuver it with openssl and curl for the simple methods. Some often required functions are missing, most notable revocation. > >> As already said, I dislike to develop further certificate >> management protocols. I think there are enough around already. >> Therefor I would prefer the second approach. But finally the >> solution must be acceptable to the target audience of developers >> asking for REST APIs for certificate management. > > Good, we agree :-) > > -- Michael Richardson , Sandelman Software > Works -= IPv6 IoT consulting =- > > > _______________________________________________ Spasm mailing list > Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJc/TcqAAoJEGJtxJsAQ/5APu8H/i7mNEQ/GXMTiryQvKF+dB3q HXqJyys1TPTgQ2FVEM25+CuG9J6WVrA89JsGbavs4epe7okdepRuImSYweB7DbTL 99V+IGnD9RHEfxtp1yGUOJU0DgBixy0Rp0vd6PDqQU62SMJ3tgtSbtI5B7YEdD0T 0aLJTSPAHzK38OCpIJJMJTs/gqSXogHwPPNiTZAncE4EXjiVMBEWaRSQJnO1mW6D vN7nnDtM2pDuAkTtkqxfO2rBd88a+N7eZiEUtl9RRDOOpLiyrrTqPkqUhIUp6fpx JqeupufpVPfuJYK9owFUmEm0ooL+Y3RgAZWPBbU8+D6D/kVlUcvYezGtROJCXV4= =6QPi -----END PGP SIGNATURE----- From nobody Sun Jun 9 13:58:06 2019 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 0129F120131 for ; Sun, 9 Jun 2019 13:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 p2eQriXQVWRX for ; Sun, 9 Jun 2019 13:58:03 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00417120045 for ; Sun, 9 Jun 2019 13:58:02 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x59KlQ2O013596; Sun, 9 Jun 2019 21:57:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=RQXwh0OiLODZRxz2GySNsovBO3S3vQOr4Fu5ZV6Dmr4=; b=hWBQLcIj/3WNiEmZLxcduzmFL73o27SBn+vU9tGxuTvO1scL+emiXAPssTqLtl4ysit6 nPYsw66H7Rn1kihIjrz4G21xWO30i4XEYDiUxOPs+f2GgQFj2UiZf8/+Y0J26HJxOC7W 66JYG1Q6dEz/C4B3RIwfeDNlE2avnpccQHZ4Ul72yZJfAustMBYqBLJ6JzzGgpmop1Vl WgkADO47F/y0yTkobfAIiX20xXjMR8mkIyqtYzw9JtJlMzsLwIPhKUlXPgO/FZjmQ+6p IfvkzA9E1TSnhEYy8pOjpoXJ7jpKQ30i+2kz4k/3a9dUk6gvyYSd3mCZBFYKiqMBFsJL Kg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2t04nucssr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 09 Jun 2019 21:57:58 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x59Klmuc016102; Sun, 9 Jun 2019 16:57:57 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2t08bvn759-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 09 Jun 2019 16:57:57 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb6.msg.corp.akamai.com (172.27.123.54) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 9 Jun 2019 16:57:57 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 9 Jun 2019 16:57:56 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([::1]) by usma1ex-dag1mb3.msg.corp.akamai.com ([fe80::9049:d725:bf4b:d545%18]) with mapi id 15.00.1473.003; Sun, 9 Jun 2019 16:57:56 -0400 From: "Salz, Rich" To: Tomas Gustavsson , "spasm@ietf.org" Thread-Topic: [lamps] Interest to standardize PKI REST APIs? Thread-Index: AQHVGHCubVVgCDqctkmtGReH7tQ+IaaQvXOAgAAr9ACAAu2wAIAABAyA Date: Sun, 9 Jun 2019 20:57:55 +0000 Message-ID: References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> <6992.1559937612@localhost> <83b511c0-4047-9431-196b-9b4028ee726d@primekey.com> In-Reply-To: <83b511c0-4047-9431-196b-9b4028ee726d@primekey.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190530 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.226] Content-Type: text/plain; charset="utf-8" Content-ID: <206BE1926ADB5749AA68B90430F9B280@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-09_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=459 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906090158 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-09_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=494 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906090158 Archived-At: Subject: Re: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 09 Jun 2019 20:58:05 -0000 V2h5IHdvbid0IEFDTUUsIHdpdGggcGVyaGFwcyBuZXcgY2hhbGxlbmdlKHMpLCBzdWZmaWNlPw0K IA0KDQo= From nobody Sun Jun 9 20:45:52 2019 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 BD09A12002E; Sun, 9 Jun 2019 20:45:42 -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.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <156013834269.25431.17554984955241498574@ietfa.amsl.com> Date: Sun, 09 Jun 2019 20:45:42 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-11.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Jun 2019 03:45:43 -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 : Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-pkix-shake-11.txt Pages : 16 Date : 2019-06-09 Abstract: Digital signatures are used to sign messages, X.509 certificates and CRLs (Certificate Revocation Lists). This document describes the conventions for using the SHAKE function family in Internet X.509 certificates and CRLs as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated subject public keys are also described. 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-11 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-pkix-shake-11 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 Sun Jun 9 20:56:08 2019 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 3904312011C for ; Sun, 9 Jun 2019 20:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 header.b=WWSOreve; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jU9aQL2u 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 ZbVj6VLBFvKF for ; Sun, 9 Jun 2019 20:56:03 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D981200C1 for ; Sun, 9 Jun 2019 20:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2291; q=dns/txt; s=iport; t=1560138962; x=1561348562; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=QZL53Iv9g434Jk7SRhXVUT60sC0H6bSvquJQyFbAMfo=; b=WWSOreveRZBxJTT6mwSOyNuxXPNNfNPbLF76APfVBcnEnB/3m+Ui8Bp7 m2PjfF0PfVDEo047oPEDSkLMgywhOsBDlwbURZz+SbOyvfDLvF9vOHvXu 0OJprkhZr9rVXmyfB9mbjyyob5+w5OFJDCaaXCLegEuCAI+naJm2k2E7G o=; IronPort-PHdr: =?us-ascii?q?9a23=3AfNfdzhyVHjBLPEjXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudCkT+NPfsZgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CEAABK1P1c/51dJa1lHgEGBwaBUQk?= =?us-ascii?q?LAYE9UANqVSAECyiHXAOOXUqCDZcygS6BJANUCQEBAQwBARgLCgIBAYRAAoJ?= =?us-ascii?q?qIzQJDgEDAQEEAQECAQRtHAELhUoBAQEEAQEQKAYBASwMCwQCAQgRBAEBHgE?= =?us-ascii?q?QJwsdCAIEEwgagwGBagMdAQIMmzQCgTiIX4IignkBAQWBNgIOQYJyGIIPCYE?= =?us-ascii?q?0AYtcF4FAP4ERRoJMPoJhAQECAQEWgSApgzqCJqkrCQKCD4ZEjRmCJWmGE41?= =?us-ascii?q?6jROBKYVqi2GDRgIEAgQFAg4BAQWBTziBWHAVGiGCbAmCBgsYg02FFIU/coE?= =?us-ascii?q?pjHKCUgEB?= X-IronPort-AV: E=Sophos;i="5.63,573,1557187200"; d="scan'208";a="572551200" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Jun 2019 03:55:58 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x5A3twQT017053 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Jun 2019 03:55:59 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 9 Jun 2019 22:55:58 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 9 Jun 2019 22:55:57 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 9 Jun 2019 22:55:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k9R5j2MomsD0bIASXl3wO4CTHB+WMaQKMw9ZCJeO8/g=; b=jU9aQL2ufjO2kyNUTANyFs07zUi1AvoILLg/ysDIwyHdZ/+cjs+iDIbFxbxsgG2Q7tBcJ3piDDx/68X8RMuydlkbuAFB1iTPphDhmnFWXb1GwRtTYYOQMHnKglJxwiF6UlbVcYOksoA9twaSgBIJnyrhXgawmCsD1NjKvfaZdMs= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.244.29) by BN7PR11MB2627.namprd11.prod.outlook.com (52.135.245.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.12; Mon, 10 Jun 2019 03:55:57 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::89af:3fb4:eae5:18b2]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::89af:3fb4:eae5:18b2%7]) with mapi id 15.20.1965.017; Mon, 10 Jun 2019 03:55:56 +0000 From: "Panos Kampanakis (pkampana)" To: "spasm@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-11.txt Thread-Index: AQHVHz8hprxD4bXno0WBEoYObyulT6aUP/5w Date: Mon, 10 Jun 2019 03:55:56 +0000 Message-ID: References: <156013834269.25431.17554984955241498574@ietfa.amsl.com> In-Reply-To: <156013834269.25431.17554984955241498574@ietfa.amsl.com> 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=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1001::79] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a34d7d33-17f2-4c8a-e940-08d6ed578b02 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2627; x-ms-traffictypediagnostic: BN7PR11MB2627: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0064B3273C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(346002)(136003)(376002)(366004)(13464003)(199004)(189003)(53754006)(68736007)(25786009)(2351001)(5660300002)(6116002)(316002)(2906002)(6916009)(74316002)(6306002)(5640700003)(64756008)(66556008)(53936002)(76116006)(86362001)(229853002)(73956011)(66446008)(66476007)(66946007)(66574012)(9686003)(33656002)(256004)(14444005)(52536014)(6436002)(55016002)(305945005)(14454004)(11346002)(966005)(71200400001)(46003)(7736002)(186003)(71190400001)(2501003)(486006)(8936002)(476003)(81166006)(446003)(478600001)(81156014)(1730700003)(8676002)(99286004)(6506007)(76176011)(53546011)(7696005)(102836004)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2627; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: iLDsO+4kntf8jEahwXD9qLSmffx0CkQicRdeYh+3dVuuKLN1l01Q6K11CPpvZc38MDQ8YDFk9mzJTPqp3yJ69NoH8eslKjxxSO8Swvoeou3oqWAMw6gLp8qsCH9wKbLxeUX6kyubOshjS4msEinwP9MdbZlLitjl06N1GuDf3bd0mHJicTKQN7ZGl/h2Cb/0rI3St5Z44J8yTmRnFavXxMODm5MGnYIuGO940Aak0lXudmDMq5LQXiTthWwN/+a+V9WDihB+rrxKS3dBJgcXrXz1jvuCuk1MDZLN/ppOK+jMV/oiUKzhfvhNLfgkBUSLkUQQM0ndfLJ9fOjwaPEHPwm/rakBI6//vaXEvMDKz570PooxWG9jBhs4u2NVUiAbPiiycTgokl3C3wjuHrbgvV+D/LP5Ec0TTiXGTCiFdZE= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a34d7d33-17f2-4c8a-e940-08d6ed578b02 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2019 03:55:56.7826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkampana@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2627 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-11.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Jun 2019 03:56:06 -0000 Hi all, This update addresses Roman's AD Review. The diff is here https://github.co= m/csosto-pk/adding-shake-to-pkix/issues/44=20 And a log of the review and its fixes is in https://github.com/csosto-pk/ad= ding-shake-to-pkix/issues/44=20 Rgs,=20 Panos -----Original Message----- From: Spasm On Behalf Of internet-drafts@ietf.org Sent: Sunday, June 09, 2019 11:46 PM To: i-d-announce@ietf.org Cc: spasm@ietf.org Subject: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-11.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 : Internet X.509 Public Key Infrastructure: Additio= nal Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-pkix-shake-11.txt Pages : 16 Date : 2019-06-09 Abstract: Digital signatures are used to sign messages, X.509 certificates and CRLs (Certificate Revocation Lists). This document describes the conventions for using the SHAKE function family in Internet X.509 certificates and CRLs as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated subject public keys are also described. 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-11 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-pkix-shake-11 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 From nobody Sun Jun 9 22:34:40 2019 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 AA735120045 for ; Sun, 9 Jun 2019 22:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=g4x15H+d; dkim=pass (1024-bit key) header.d=primekey.com header.b=g4x15H+d 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 iOb2Q3BX1vZB for ; Sun, 9 Jun 2019 22:34:32 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4FB51200C4 for ; Sun, 9 Jun 2019 22:34:31 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 2CBE46AA0091 for ; Mon, 10 Jun 2019 07:34:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1560144864; bh=DyXgFQ35pnarGdC770wIWdma87jRl3PTgv08b4eCw/E=; h=Subject:To:References:From:Date:In-Reply-To:From; b=g4x15H+dp3qZnA3AvpuJDCtDf8esbWY5ydbHF6+ofi0qmrff0/Yas+hk1LCeFdUZX g/ARxeobsp5b7xECRJvXZ63VyFSBBt6bQdDyoyNb+el1rkDZGxtKQSfcb+eDRLy+sG xl/TJx6mNHp1TmeqokxBNyiC2SNsUHBm6K8grkh4= Received: from [10.11.0.8] (gatekeeper.primekey.se [84.55.121.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id EDA2A6AA0090 for ; Mon, 10 Jun 2019 07:34:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1560144864; bh=DyXgFQ35pnarGdC770wIWdma87jRl3PTgv08b4eCw/E=; h=Subject:To:References:From:Date:In-Reply-To:From; b=g4x15H+dp3qZnA3AvpuJDCtDf8esbWY5ydbHF6+ofi0qmrff0/Yas+hk1LCeFdUZX g/ARxeobsp5b7xECRJvXZ63VyFSBBt6bQdDyoyNb+el1rkDZGxtKQSfcb+eDRLy+sG xl/TJx6mNHp1TmeqokxBNyiC2SNsUHBm6K8grkh4= To: spasm@ietf.org References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> <6992.1559937612@localhost> <83b511c0-4047-9431-196b-9b4028ee726d@primekey.com> From: Tomas Gustavsson Openpgp: preference=signencrypt Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= mQENBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAG0MFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPokB NwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5uQENBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAGJAR8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <28f0bc85-fd3f-e811-baf6-220ed8564c58@primekey.com> Date: Mon, 10 Jun 2019 07:34:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Jun 2019 05:34:34 -0000 On 2019-06-09 22:57, Salz, Rich wrote: > Why won't ACME, with perhaps new challenge(s), suffice? Oh, of course, ACME may do the trick, being REST already. ACME having such a specific target, care has to be taken to not bastardize it. From nobody Mon Jun 10 05:11:59 2019 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 93F0812017F for ; Mon, 10 Jun 2019 05:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 myjPTz19k0WN for ; Mon, 10 Jun 2019 05:11:56 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2324A120178 for ; Mon, 10 Jun 2019 05:11:56 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x5AC6fOB006815; Mon, 10 Jun 2019 13:11:54 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=SMTTQWhdhEfd0NNkIal861kIZtj/FjzltS7jWV/TNRI=; b=V37C+6gfKEwAviSO9rG5EPiDafSpJORQeDyi1ipEfwhhTatYIPEKuyRqi5O3Vcd8hI32 0zWG92cCGh1y7VcuMEqOrUKRDnJt2kvdFHows+kS/bUxrv1FvCCeWx3XFIb/9l/y4v96 P+7iOyyC+J1QtRWaxhLOnq5OZrgl9TWr9/jFFYngWZJ/p9jW1Flxcqzwr4Oj+kQ21VU4 DU6YZ9tZ00QLo4wLfk4zHtU/Izi4atKdASzXxTzPEMZAgzk5uuUb61BfBnLYHawc9D+I c5Z2RFKBucpcQrWUB8N2bdOWF3YCn9k/BedUvcbzmOQw1cICNi6pieckOp+0kv5gdwwY XQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2t0kd2w7fx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Jun 2019 13:11:54 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x5AC1s04002248; Mon, 10 Jun 2019 08:11:53 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2t08bvxdbk-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 10 Jun 2019 08:11:53 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 10 Jun 2019 08:10:26 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([::1]) by usma1ex-dag1mb3.msg.corp.akamai.com ([fe80::9049:d725:bf4b:d545%18]) with mapi id 15.00.1473.003; Mon, 10 Jun 2019 08:10:26 -0400 From: "Salz, Rich" To: Tomas Gustavsson , "spasm@ietf.org" Thread-Topic: [lamps] Interest to standardize PKI REST APIs? Thread-Index: AQHVGHCubVVgCDqctkmtGReH7tQ+IaaQvXOAgAAr9ACAAu2wAIAABAyAgADTYICAACuTgA== Date: Mon, 10 Jun 2019 12:10:26 +0000 Message-ID: <42C0B0A7-792A-4DBD-B984-15A30B5C0FD0@akamai.com> References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> <6992.1559937612@localhost> <83b511c0-4047-9431-196b-9b4028ee726d@primekey.com> <28f0bc85-fd3f-e811-baf6-220ed8564c58@primekey.com> In-Reply-To: <28f0bc85-fd3f-e811-baf6-220ed8564c58@primekey.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190530 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.137] Content-Type: text/plain; charset="utf-8" Content-ID: <948A0193B9DD2449A9F1E58A952D01BE@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-10_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=610 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906100085 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-10_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=648 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906100086 Archived-At: Subject: Re: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Jun 2019 12:11:57 -0000 ICAgID4gV2h5IHdvbid0IEFDTUUsIHdpdGggcGVyaGFwcyBuZXcgY2hhbGxlbmdlKHMpLCBzdWZm aWNlPw0KICAgIA0KICAgIE9oLCBvZiBjb3Vyc2UsIEFDTUUgbWF5IGRvIHRoZSB0cmljaywgYmVp bmcgUkVTVCBhbHJlYWR5LiBBQ01FIGhhdmluZw0KICAgIHN1Y2ggYSBzcGVjaWZpYyB0YXJnZXQs IGNhcmUgaGFzIHRvIGJlIHRha2VuIHRvIG5vdCBiYXN0YXJkaXplIGl0Lg0KDQpBQ01FJ3MgYSBm cmFtZXdvcmssIGFuZCBpbiBhZGRpdGlvbiB0byB0aGUgYmFzZSBzcGVjIHdoaWNoIGluY2x1ZGVz IEROUyBob3N0cywgaXQgaXMgYWxyZWFkeSBiZWluZyB1c2VkIGZvciBtb2JpbGUgcGhvbmVzLCBJ UCBhZGRyZXNzZXMsIGV0Yy4NCg0KDQo= From nobody Mon Jun 10 07:18:19 2019 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 53EC612013F for ; Mon, 10 Jun 2019 07:18:18 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=wRZNoATo; dkim=pass (1024-bit key) header.d=primekey.com header.b=wRZNoATo 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 7_annJTBY6lf for ; Mon, 10 Jun 2019 07:18:16 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589DF120074 for ; Mon, 10 Jun 2019 07:18:16 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id D1BB56AA0091 for ; Mon, 10 Jun 2019 16:18:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1560176289; bh=88Szm8E1gvefxo0G+K0JpMSJNKV4OkoQzlXO7jQs2hw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=wRZNoAToJx6riGBMb0N+PY6al/eACK9h56p+yv9VP8yLqsy08gP8ahvtwHhJyQ4wH ySQ0ji/GmUdiEnHTSoqBcCMQee6JBmtEdMjWc+0wjoU0IBX08gCO4zze8EtMBr31k+ XJZfA7gSAytQDaKu1xs9w9PRkjuOG8Vg1wZpdj4g= Received: from [10.11.0.9] (gatekeeper.primekey.se [84.55.121.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 7756C6AA0090 for ; Mon, 10 Jun 2019 16:18:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1560176289; bh=88Szm8E1gvefxo0G+K0JpMSJNKV4OkoQzlXO7jQs2hw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=wRZNoAToJx6riGBMb0N+PY6al/eACK9h56p+yv9VP8yLqsy08gP8ahvtwHhJyQ4wH ySQ0ji/GmUdiEnHTSoqBcCMQee6JBmtEdMjWc+0wjoU0IBX08gCO4zze8EtMBr31k+ XJZfA7gSAytQDaKu1xs9w9PRkjuOG8Vg1wZpdj4g= To: spasm@ietf.org References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> <6992.1559937612@localhost> <83b511c0-4047-9431-196b-9b4028ee726d@primekey.com> <28f0bc85-fd3f-e811-baf6-220ed8564c58@primekey.com> <42C0B0A7-792A-4DBD-B984-15A30B5C0FD0@akamai.com> From: Tomas Gustavsson Openpgp: preference=signencrypt Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= mQENBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAG0MFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPokB NwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5uQENBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAGJAR8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: Date: Mon, 10 Jun 2019 16:18:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <42C0B0A7-792A-4DBD-B984-15A30B5C0FD0@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Jun 2019 14:18:18 -0000 Are there any examples of such additions to the base spec publicly available? On 2019-06-10 14:10, Salz, Rich wrote: > > Why won't ACME, with perhaps new challenge(s), suffice? > > Oh, of course, ACME may do the trick, being REST already. ACME having > such a specific target, care has to be taken to not bastardize it. > > ACME's a framework, and in addition to the base spec which includes DNS hosts, it is already being used for mobile phones, IP addresses, etc. > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Mon Jun 10 08:04:05 2019 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 87E581201B5 for ; Mon, 10 Jun 2019 08:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 ErouE-0QoxJc for ; Mon, 10 Jun 2019 08:04:02 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AABE61201B0 for ; Mon, 10 Jun 2019 08:04:02 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5AF41M4024301; Mon, 10 Jun 2019 16:04:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=cQ3nHfrSmBZvb6y1Bk7l3ky10t7IaBkN3WW0GkuoLk0=; b=EtLKPoott8gaXCQRo7slNJkYmVvzbFViGPmAHmV/IAM3u9v3cS1T3HFTOrR1xmfKBa6S dwiR8N0+2LqZG1RXB9eIrRVODm7vihUDB2DnHtWES9/Ups+X2hwl++AeIq7q3pWkZEv7 KQN34rN5Dnm65IWJRDBtLc3JIJ6vMNDGmKLKER9f2Ey7spkPR8yugsOforx/XoIhU4Ck +alQpZNEzRAEqy7doWH5pqdJtSKo+qXc+U125F1+IX64W9ntzGebbRj4+aKnxo0cDtAC VZsBRsQTyYy0yZKWnKBTHVxi77MVo3VabDt1gmhqHfuNtTVDGoid5TqTS9HsdSsde8Eg Bg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2t1q0m0e3h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Jun 2019 16:04:01 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x5AF3UtX002539; Mon, 10 Jun 2019 11:04:00 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2t08bvxx3n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 10 Jun 2019 11:04:00 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 10 Jun 2019 11:03:59 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([::1]) by usma1ex-dag1mb3.msg.corp.akamai.com ([fe80::9049:d725:bf4b:d545%18]) with mapi id 15.00.1473.003; Mon, 10 Jun 2019 11:03:59 -0400 From: "Salz, Rich" To: Tomas Gustavsson , "spasm@ietf.org" Thread-Topic: [lamps] Interest to standardize PKI REST APIs? Thread-Index: AQHVGHCubVVgCDqctkmtGReH7tQ+IaaQvXOAgAAr9ACAAu2wAIAABAyAgADTYICAACuTgIAAZr+A///JvwA= Date: Mon, 10 Jun 2019 15:03:58 +0000 Message-ID: <9E9CA336-DBCC-4625-86D2-44655AEB5721@akamai.com> References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> <6992.1559937612@localhost> <83b511c0-4047-9431-196b-9b4028ee726d@primekey.com> <28f0bc85-fd3f-e811-baf6-220ed8564c58@primekey.com> <42C0B0A7-792A-4DBD-B984-15A30B5C0FD0@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190530 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.137] Content-Type: text/plain; charset="utf-8" Content-ID: <905DD5A9DE1DA1409923892E387D85C1@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-10_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=253 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906100104 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-10_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=346 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906100104 Archived-At: Subject: Re: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Jun 2019 15:04:05 -0000 ICAgIEFyZSB0aGVyZSBhbnkgZXhhbXBsZXMgb2Ygc3VjaCBhZGRpdGlvbnMgdG8gdGhlIGJhc2Ug c3BlYyBwdWJsaWNseQ0KICAgIGF2YWlsYWJsZT8NCg0KTWFueS4gIExvb2sgYXQgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy93Zy9hY21lL2RvY3VtZW50cy8gdG8gc2VlIHRoZSBkb2N1bWVu dCBsaXN0OyB0aGUgImF1dGhvcml0eSB0b2tlbiIgaXMgZm9yIHBob25lcywgdGhlIHJlc3Qgc2hv dWxkIGJlIG9idmlvdXMuDQoNCg0KDQo= From nobody Mon Jun 10 08:27:12 2019 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 5CEE212013E for ; Mon, 10 Jun 2019 08:27:10 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=ID+u+AD4; dkim=pass (1024-bit key) header.d=primekey.com header.b=To4vowjI 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 xDf97VWIKVmw for ; Mon, 10 Jun 2019 08:27:08 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDA6120116 for ; Mon, 10 Jun 2019 08:27:08 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id EF5586AA0093 for ; Mon, 10 Jun 2019 17:27:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1560180422; bh=vANE7LoFdaQkVF+rKvN7EI7/ef8UzsvSyDRnMZ3+85A=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ID+u+AD40fczdETHM2MBMd2yyHx6exS4vZj7H41GQ3FRlicg7MvcfrGRKzBG8n2YW cMRs9fnBhHmo88dNex/R02lwYUakOVRrgcb/JiRejTezFWK18doq7VuHHdz4yg7buB S7FN9VY7Yp9izeaxJXOPaM2t2wPdtoIxWUgqPdWc= Received: from [10.11.0.3] (gatekeeper.primekey.se [84.55.121.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 818D06AA0092 for ; Mon, 10 Jun 2019 17:27:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1560180421; bh=vANE7LoFdaQkVF+rKvN7EI7/ef8UzsvSyDRnMZ3+85A=; h=Subject:To:References:From:Date:In-Reply-To:From; b=To4vowjI+9r79/xVVKqXqG+cHOLFivUq5YuC7XIVhgvznNXMLnOEhPfh6ESO/JO8P yyOsAPJm3sI+U8EerLmZAlxzpiFtJtwU+I/bwgitin3xwiX6NRiE5AkkEzVkflbf5C ZJe33S/AulU0EqImCgg6d8F/3OkYBRXzJ8wLyiZU= To: spasm@ietf.org References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> <6992.1559937612@localhost> <83b511c0-4047-9431-196b-9b4028ee726d@primekey.com> <28f0bc85-fd3f-e811-baf6-220ed8564c58@primekey.com> <42C0B0A7-792A-4DBD-B984-15A30B5C0FD0@akamai.com> <9E9CA336-DBCC-4625-86D2-44655AEB5721@akamai.com> From: Tomas Gustavsson Openpgp: preference=signencrypt Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= mQENBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAG0MFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPokB NwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5uQENBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAGJAR8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: Date: Mon, 10 Jun 2019 17:27:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <9E9CA336-DBCC-4625-86D2-44655AEB5721@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Jun 2019 15:27:10 -0000 Thanks. Lots of interesting reading there. I was aware of some of the new validation methods for webPKI (like CAA), but not this for example. https://datatracker.ietf.org/doc/draft-moriarty-acme-client Seems like there is indeed some good work done. I'll continue monitoring that. Cheers, Tomas On 2019-06-10 17:03, Salz, Rich wrote: > Are there any examples of such additions to the base spec publicly > available? > > Many. Look at https://datatracker.ietf.org/wg/acme/documents/ to see the document list; the "authority token" is for phones, the rest should be obvious. > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Tue Jun 11 09:35:13 2019 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 A4F3E120353 for ; Tue, 11 Jun 2019 09:35:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 GC5Ljy_-m5ef for ; Tue, 11 Jun 2019 09:35:02 -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 921C2120363 for ; Tue, 11 Jun 2019 09:34:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 96D15300AAB for ; Tue, 11 Jun 2019 12:15:22 -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 7y-ZPkbF3UOx for ; Tue, 11 Jun 2019 12:15:20 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id D26F23005D6; Tue, 11 Jun 2019 12:15:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <83521276-738B-4298-A36D-B3C04E11A05C@vigilsec.com> Date: Tue, 11 Jun 2019 12:34:35 -0400 Cc: IESG , SPASM Content-Transfer-Encoding: quoted-printable Message-Id: References: <155916984601.5535.15415810479866156115.idtracker@ietfa.amsl.com> <83521276-738B-4298-A36D-B3C04E11A05C@vigilsec.com> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jun 2019 16:35:05 -0000 Ben: I have not heard back from you. Please let me know if the proposed way = forward would resolve your DISCUSS position. Russ > On May 31, 2019, at 1:03 PM, Russ Housley = wrote: >=20 > Ben: >=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> After further reflection, I think we need to resurrect the discussion >> sparked by DKG's last-call review. Specifically, in Section 5 when = we >> consider the case that there is not a directory service/repository >> available, we give guidance to "the recipient" and "recipients". But = in >> at least some cases, there are two tiers of recipients/relying = parties, >> that have different properties, as in the web PKI situation. >> Specifically, web server operators rely on root CAs to certify the >> certificates that they present to TLS clients. But we also consider = the >> TLS clients themselves, which may not have a direct path to receiving >> the updated root CA self-signed certificate, and because of the >> different ways these different types of recipient rely on root CA >> information, the order in which they update can cause breakage. We = do >> not necessarily need to present a clear solution that will always = avoid >> this breakage, but I do think we need to at least discuss the >> possibility of such scenarios. >>=20 >> To consider a concrete case, consider a system with a TLS client = ("A"), >> a TLS server ("B"), and the root CA ("C"). C issues (potentially via >> intermediates) an end-entity certificate for B, and we consider a = case >> where A initiates TLS connections to B. Initially, C has the root >> CA/key at C1, and is initiating a transition to C2; before the >> transition both A and B have C1 in their trusted store. When A = receives >> C2, it can perform the requisite validation and add C2 to its trust >> store for use potentially validating incoming certificate chains. = When >> B receives C2, it can similarly perform the requisite validation and = add >> C2 to its trust store, but B's trust store is used for validating >> *outgoing* certificate chains, not (just) incoming ones. If B were = to >> keep C2 in its trust store and construct an outgoing certificate = chain >> based on C2 (and omitting oldWithNew and newWithOld), before A has >> received C2, then the TLS handshake fails! >>=20 >> If A had access to C2, or to oldWithnew/NewWithOld, then it would = still >> be able to validate B's certificate chain, but this document (and RFC >> 4210) do not give guidance that B should transmit newWithOld to A, >> leaving open this scenario for breakage. >>=20 >> My current inclination is to add some text to this document = acknowleding >> the potential for a chain of relying parties, and recommending that = the >> "intermediate parties" in the scenario make newWithOld/oldWithNew = available until >> the notAfter time from oldWithNew, but I am of course open to further >> discussion/suggestions. >=20 > I think that the document is fairly clear that there can be some = failure if there is not a repository or directory service. However, = while thinking about this over night, I realized that we could also = point to the the Subject Information Access certificate extension in RFC = 5280, Section 4.2.2.2. >=20 > The id-ad-caRepository OID is used when the subject is a CA that > publishes certificates it issues in a repository. The = accessLocation > field is defined as a GeneralName, which can take several forms. >=20 > ... >=20 > Where the information is available via HTTP or FTP, accessLocation > MUST be a uniformResourceIdentifier and the URI MUST point to either > a single DER encoded certificate as specified in [RFC2585] or a > collection of certificates in a BER or DER encoded "certs-only" CMS > message as specified in [RFC2797]. >=20 > I am willing to RECOMMEND the inclusion of this extension and posting = the oldWithNew and newWithOld so that they can be fetched using the = "certs-only" (simple PKI response). This format would allow = certificates to be added and removed from the bag of certificates over = time. >=20 >> Separately, I just want to quickly check that the id-ce-hashOfRootKey >> OID has been properly allocated and recorded, as I couldn't find >> evidence to indicate that in a quick search. I assume this is the >> origin of the CTIA acknowledgment that Alissa mentions, but there's = not >> quite enough there to connect the dots. >=20 > CTIA allocated the OID for the ASN.1 module and the OID for the = certificate extension from their arc. In response to Alissa's comment, = I suggested an additional sentence for the Acknowledgements to make this = clear. >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Section 1.1 >>=20 >> Please use the boilerplate from RFC 8174 (yes, I read the shepherd = writeup). >=20 > Already fixed in my edit buffer. >=20 >> Section 1.2 >>=20 >> side note: this claim about "always encoded with DER" seems a bit >> optimistic unless scoped down to a specific context. >=20 > X.509 and RFC 5280 require the DER encoding for the signature = computation and the signature validation. If someone uses a different = encoding somewhere along the way, it needs to be put back in DER form = for the signature to validate. >=20 > How about: >=20 > Certificates [RFC5280] use ASN.1 [X680]; Distinguished Encoding = Rules > (DER) [X690] are REQUIRED for certificate signing and validation. >=20 >> Section 5 >>=20 >> After issuing the oldWithNew and newWithOld certificates, the Root = CA >> MUST stop using the old private key to sign certificates. >>=20 >> Isn't this only relevant for newWithOld? We don't need to use the = old >> private key to sign certificates to make a certification of the old = key >> signed by the new key. >=20 > This is a statement about when to stop using the old private key. = But, indeed, you are correct: >=20 > After issuing the newWithOld certificate, the Root CA MUST stop = using > the old private key to sign certificates. >=20 >> Changing names from one generation to another can lead to confusion >> when reviewing the history of a trust anchor store. To assist with >> such review, a recipient MAY create an audit entry to capture the = old >> and replacement self-signed certificates. >>=20 >> It seems like there may be non-name changes that might also cause >> confusion (or worse); do we want to mention this possibility and/or = the >> recipient's duty to check for unexpected changes? >=20 > This was a recommendation from DKC in the thread that you reference in = your DISCUSS comments. I do not know of any relying part software that = keeps the audit log of changes to the trust store. Many software update = programs, for example, update the trust anchor store without creating = such an audit. I am not sure that building further on this concept is = desirable. >=20 >> Section 6 >>=20 >> I think some explicit guidance is needed about there being a critical >> operational issue in the (unexpected) case of the cryptographic >> breakdown of the hash function used to compute HashedRootKey. The >> current discussion of needing a hash function that is = preimage-resistant >> is good, of course, but some indication of the consequences if a has >> function becomes bad during the course of use (or a bad hash function = is >> chosen initially) seems to be in order. >=20 > How about adding this sentence to the end of that paragraph: >=20 > If the employed hash function is broken after the Root CA publishes > the self-signed certificate with the HashOfRootKey certificate > extension, an attacker would be able to trick the recipient into > installing the incorrect next generation certificate in the trust > anchor store. >=20 >> I also agree with the secdir reviewer that some guidance about how to >> know that the first trasition is complete would be nice (in the = absence >> of the RFC 4210 transition process), but understand that such = guidance >> is hard to give. >=20 > I do not have great advice, but there is a hint: >=20 > Queries for the CRLs associated with certificates that are > subordinate to the self-signed certificate can give some > indication for the number of relying parties that are still > actively using the self-signed certificates. >=20 > Russ From nobody Tue Jun 11 22:49:53 2019 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 A19E6120086 for ; Tue, 11 Jun 2019 22:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=siemens.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 a9YRp9VVLV8g for ; Tue, 11 Jun 2019 22:49:50 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40045.outbound.protection.outlook.com [40.107.4.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DAF412007A for ; Tue, 11 Jun 2019 22:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector2-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rScxfmJtXCHtdXS4vqGqgQEVm+yM+GTzCH9CUUaqj/c=; b=ntOUmDqCiISoqTavBPwMHyB3lXVzDQH6vMtvaGzAPYXLGSJlV8Cpl0M2yR+wGDiU8X28dmzVicXtHMGMP6c4/bako9rP59zIGEgzhke8/Whf+ojQvCu3kdY2XkQiUyDLxpXR0sdCptNKh7FRsCpdHmYWKCAPema10Tf8N5B114M= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB1986.EURPRD10.PROD.OUTLOOK.COM (52.134.84.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.16; Wed, 12 Jun 2019 05:49:46 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a1d3:2a6c:c2ff:2fa3]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a1d3:2a6c:c2ff:2fa3%7]) with mapi id 15.20.1965.017; Wed, 12 Jun 2019 05:49:46 +0000 From: "Brockhaus, Hendrik" To: Michael Richardson , "spasm@ietf.org" Thread-Topic: [lamps] Interest to standardize PKI REST APIs? Thread-Index: AQHVGHCvl8HgPTUm30+9zuWHsj3AZKaQehewgAAsQgCABubnEA== Date: Wed, 12 Jun 2019 05:49:46 +0000 Message-ID: References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> <6992.1559937612@localhost> In-Reply-To: <6992.1559937612@localhost> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [80.146.228.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6f4896c4-2de5-4f35-d6df-08d6eef9c68f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR10MB1986; x-ms-traffictypediagnostic: AM0PR10MB1986: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0066D63CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(346002)(366004)(396003)(39860400002)(199004)(189003)(66946007)(6436002)(55016002)(25786009)(9686003)(86362001)(53936002)(2501003)(81156014)(3846002)(66476007)(68736007)(71200400001)(256004)(14444005)(316002)(14454004)(71190400001)(486006)(52536014)(99286004)(8676002)(76116006)(73956011)(66066001)(33656002)(5660300002)(478600001)(11346002)(66446008)(110136005)(446003)(2906002)(81166006)(66556008)(476003)(64756008)(8936002)(26005)(7736002)(76176011)(305945005)(6116002)(6506007)(186003)(74316002)(7696005)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB1986; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: UrioKGEOBq2/NYjr6p9wsB2M9jNg1DIAqKbm9Uorwfqu+LVDcQ67TzWxBDSEqtZUJNDJiiuAeR4rIWfnv3X8SRrPOOYvLDsO2BCWKek3GNpFn6g8duOqThUoI73Hj+dR94A/p+9dKD5beQR8Lm8GoOf0QIGxpy3ljcPgTW0KkdJL+j1KViLEP/e53X68arXI7x2Hqo3A6I+UG12+XHOINezvG82xbPXmv59Wlha5locJQCeLDGHMiilc2jqa/Wi3LEZV8GRN6Qc9/uyoReKfL/+GlnAjNjVBYxd8x4WHa5Z7wlv59tog88SosNluDuxbp67oGKRSj/7c3yaW22St2KKb9C7aVBRTAc6weEXz7V3rv/kyTOg7e18HOa+fbOCQP4Ho9NY0xMnvB250qHFOk5xt/u6qxSCodzhy6etdIFs= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6f4896c4-2de5-4f35-d6df-08d6eef9c68f X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2019 05:49:46.4137 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hendrik.brockhaus@siemens.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB1986 Archived-At: Subject: Re: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jun 2019 05:49:53 -0000 > Michael Richardson wrote: >=20 > Brockhaus, Hendrik wrote: > > I think we need to first collect the required certificate managemen= t > > use cases and check if they are addressed by existing protocols. >=20 > I don't want to do that. It's boiling the ocean. IMHO knowing about the uses cases we want to address is not 'boiling the o= cean'. If we want to come up with a solution that fits our needs, we should= do this. Other vice we come up with a solution that looks nice, but cannot= be used for major use cases. Like EST is an interesting approach for the l= ast mile, but does not offer revocation, self-contained messages and end-to= -end security. All are required in more complex scenarios. I see the following requirements. - Enrollment, update und revocation - Local and central key generation - Confirmation of certificate enrollment/update - Polling for delayed delivery - Some general messages like GetCSRParam and RootCACertUpadate - Approval of request by intermediate RAs, e.g. by adding additional signat= ures - Security features . Self-contained protection of requests/responses (end-to-end security) . Proof-of-possession . Proof-of-identity, e.g. signature, HMAC . Replay protection, e.g. nonces . Timeliness, e.g. timestamps So there is no surprise. But some features like self-contains messages toge= ther with approval of an RA is not available in protocols like ACME and EST= . So we can discuss extending these, or we utilize an existing protocol lik= e CMP that already offers the above and adapt its transport and messages fl= ow to REST. From nobody Tue Jun 11 23:44:07 2019 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 C70651200B4 for ; Tue, 11 Jun 2019 23:44:05 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=uY9epfZD; dkim=pass (1024-bit key) header.d=primekey.com header.b=uY9epfZD 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 1mgvopOTpA00 for ; Tue, 11 Jun 2019 23:44:03 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 993CB120077 for ; Tue, 11 Jun 2019 23:44:02 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 674CD6AA0090 for ; Wed, 12 Jun 2019 08:43:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1560321835; bh=iuWYlqXXQj4/4jlcdWng49ny90DF2krWU3A9AQvFPDM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=uY9epfZD6mtjAHO+nlaMmDP+nFfNvU3qHUB6AWfF8dBzl0WnLh1HUyXwR4ieS+2SA PcOgvRbLv8mgNfB4NVGQHS/OJ0mP90rQqRXE6NHYq0cid9oQ6rpFbutpORBNdvwMcp 0RGP6970vOJvnVHx5OgfNbCF1bspHe3drKwZXd7Y= Received: from [10.11.0.8] (gatekeeper.primekey.se [84.55.121.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id F20926AA008D for ; Wed, 12 Jun 2019 08:43:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1560321835; bh=iuWYlqXXQj4/4jlcdWng49ny90DF2krWU3A9AQvFPDM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=uY9epfZD6mtjAHO+nlaMmDP+nFfNvU3qHUB6AWfF8dBzl0WnLh1HUyXwR4ieS+2SA PcOgvRbLv8mgNfB4NVGQHS/OJ0mP90rQqRXE6NHYq0cid9oQ6rpFbutpORBNdvwMcp 0RGP6970vOJvnVHx5OgfNbCF1bspHe3drKwZXd7Y= To: spasm@ietf.org References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> <6992.1559937612@localhost> From: Tomas Gustavsson Openpgp: preference=signencrypt Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= mQENBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAG0MFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPokB NwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5uQENBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAGJAR8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: Date: Wed, 12 Jun 2019 08:43:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jun 2019 06:44:06 -0000 I'm not sure that properties such as self-contained protection is a good fit for REST API. (one of) The key point (at least for me) of REST API is the easiness of testing/development. You can use a Swagger web page to test the API directly from a browser, and get copy-paste curl commands to run in a script. Error responses are simple, human readable JSON. Using CMP, for example, as base will not make this possible. CMP works well as it is imho, and I don't think it will become easier to use with a new transport. The HTTP transport itself of CMP is easy enough (I like it). Of course PKCS#10 request and certificates/CRLs are self-contained protected, but there is nothing similar for say revocation requests. Simple use cases can use simple protocols, but it will be hard I think to support complex use cases sẃith such. This is where CMP shines, for complex use cases, and I have no ambition to replace CMP. Regards, Tomas On 2019-06-12 07:49, Brockhaus, Hendrik wrote: >> Michael Richardson wrote: >> >> Brockhaus, Hendrik wrote: >> > I think we need to first collect the required certificate management >> > use cases and check if they are addressed by existing protocols. >> >> I don't want to do that. It's boiling the ocean. > > IMHO knowing about the uses cases we want to address is not 'boiling the ocean'. If we want to come up with a solution that fits our needs, we should do this. Other vice we come up with a solution that looks nice, but cannot be used for major use cases. Like EST is an interesting approach for the last mile, but does not offer revocation, self-contained messages and end-to-end security. All are required in more complex scenarios. > > I see the following requirements. > - Enrollment, update und revocation > - Local and central key generation > - Confirmation of certificate enrollment/update > - Polling for delayed delivery > - Some general messages like GetCSRParam and RootCACertUpadate > - Approval of request by intermediate RAs, e.g. by adding additional signatures > - Security features > . Self-contained protection of requests/responses (end-to-end security) > . Proof-of-possession > . Proof-of-identity, e.g. signature, HMAC > . Replay protection, e.g. nonces > . Timeliness, e.g. timestamps > > So there is no surprise. But some features like self-contains messages together with approval of an RA is not available in protocols like ACME and EST. So we can discuss extending these, or we utilize an existing protocol like CMP that already offers the above and adapt its transport and messages flow to REST. > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Wed Jun 12 01:43:52 2019 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 B4BAA1200FA for ; Wed, 12 Jun 2019 01:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=siemens.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 uIe_lwb2wy7Z for ; Wed, 12 Jun 2019 01:43:47 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10063.outbound.protection.outlook.com [40.107.1.63]) (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 C0D80120089 for ; Wed, 12 Jun 2019 01:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector2-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C5kN5eAXpg2WhBTObBOx1O+zMYF7EiTnL1CnqPj8zcM=; b=TJLwhLMH2cHVziI4UTHxaSjJsT1YbuaQ3t4m49Bbz2aF6KvTOKfHTN9zZ/tvr+uPP95Wxu7Zrisk1dEouSfXnhbn5GP2H+HTm8lnU1e7XFiQEjGLbwYkrCPPfZqHxRVTvUJMSd2gssEej22CLq61F+2Kg0Q1RfDwJ7WJa3uT730= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB2162.EURPRD10.PROD.OUTLOOK.COM (20.177.108.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Wed, 12 Jun 2019 08:43:44 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a1d3:2a6c:c2ff:2fa3]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a1d3:2a6c:c2ff:2fa3%7]) with mapi id 15.20.1965.017; Wed, 12 Jun 2019 08:43:44 +0000 From: "Brockhaus, Hendrik" To: Tomas Gustavsson , "spasm@ietf.org" Thread-Topic: [lamps] Interest to standardize PKI REST APIs? Thread-Index: AQHVGHCvl8HgPTUm30+9zuWHsj3AZKaQehewgAAsQgCABubnEIAAFkmAgAAY4fA= Date: Wed, 12 Jun 2019 08:43:44 +0000 Message-ID: References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> <6992.1559937612@localhost> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [80.146.228.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b61148a3-111f-4546-0a59-08d6ef1213f4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR10MB2162; x-ms-traffictypediagnostic: AM0PR10MB2162: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0066D63CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(346002)(376002)(366004)(136003)(189003)(199004)(110136005)(86362001)(64756008)(76116006)(2906002)(66446008)(68736007)(66476007)(66556008)(55016002)(73956011)(66066001)(71190400001)(71200400001)(2501003)(53936002)(486006)(446003)(11346002)(476003)(8676002)(81156014)(66946007)(8936002)(81166006)(7696005)(76176011)(102836004)(25786009)(33656002)(52536014)(478600001)(7736002)(186003)(3846002)(9686003)(6506007)(74316002)(66574012)(26005)(6116002)(5660300002)(14444005)(6436002)(256004)(99286004)(316002)(305945005)(14454004)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB2162; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ZblmLglI9vhzDPF6ZvrH6PdFtXJ3DKB0HCxgOVZjZauoehieSDeguHTiu6ThE26/+3LVrv7siXXrq0MiOqegHw9rfB8aC7lyy8zwur5iqcHtIeogs/xgaUDszT7KhD0xIxbMvbMWEh3UtsHO50QKahH+831H95QoRWVUv7ZkllQLdFNSuuf1TtZBS6jXd+gTI5imWWvtJfNGn1ysFbXaO5aHJZdqgzEvy4rCHxdHJj7vuVH13YmwFwbFRqDrLjnYRuj4HPYy5fFa4XEljBh0kjSHs37HXRV+iQu86kutn87sTc7tPyryIlaLjKyDjj66gGiIfDM23TyMSQ+Sa7TEDW4fmaUVmjQUNLTkgNV9/ACkGnepQi/ts3DSyVCZM0eU/f4r981JBF2esLWNtCwvzt5+PMfhG/3CIAfT554HTWg= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: b61148a3-111f-4546-0a59-08d6ef1213f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2019 08:43:44.1265 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hendrik.brockhaus@siemens.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2162 Archived-At: Subject: Re: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jun 2019 08:43:50 -0000 PiBUb21hcyBHdXN0YXZzc29uIDx0b21hcy5ndXN0YXZzc29uQHByaW1la2V5LmNvbT4gd3JvdGU6 IA0KPiANCj4gSSdtIG5vdCBzdXJlIHRoYXQgcHJvcGVydGllcyBzdWNoIGFzIHNlbGYtY29udGFp bmVkIHByb3RlY3Rpb24gaXMgYSBnb29kIGZpdCBmb3INCj4gUkVTVCBBUEkuIChvbmUgb2YpIFRo ZSBrZXkgcG9pbnQgKGF0IGxlYXN0IGZvciBtZSkgb2YgUkVTVCBBUEkgaXMgdGhlIGVhc2luZXNz DQo+IG9mIHRlc3RpbmcvZGV2ZWxvcG1lbnQuIFlvdSBjYW4gdXNlIGEgU3dhZ2dlciB3ZWIgcGFn ZSB0byB0ZXN0IHRoZSBBUEkNCj4gZGlyZWN0bHkgZnJvbSBhIGJyb3dzZXIsIGFuZCBnZXQgY29w eS1wYXN0ZSBjdXJsIGNvbW1hbmRzIHRvIHJ1biBpbiBhIHNjcmlwdC4NCj4gRXJyb3IgcmVzcG9u c2VzIGFyZSBzaW1wbGUsIGh1bWFuIHJlYWRhYmxlIEpTT04uDQoNCkkgZG8gbm90IGZlZWwgdGhh dCB0aGlzIGNvbnRyYWRpY3RzIHdpdGggc2VsZi1jb250YWluZWQgbWVzc2FnZSBwcm90ZWN0aW9u LiBBdCBsZWFzdCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBzaG91bGQgd29yaywgb3IgYW0gSSB3cm9u Zz8NCg0KPiBVc2luZyBDTVAsIGZvciBleGFtcGxlLCBhcyBiYXNlIHdpbGwgbm90IG1ha2UgdGhp cyBwb3NzaWJsZS4gQ01QIHdvcmtzIHdlbGwNCj4gYXMgaXQgaXMgaW1obywgYW5kIEkgZG9uJ3Qg dGhpbmsgaXQgd2lsbCBiZWNvbWUgZWFzaWVyIHRvIHVzZSB3aXRoIGEgbmV3DQo+IHRyYW5zcG9y dC4gVGhlIEhUVFAgdHJhbnNwb3J0IGl0c2VsZiBvZiBDTVAgaXMgZWFzeSBlbm91Z2ggKEkgbGlr ZSBpdCkuDQo+IA0KPiBPZiBjb3Vyc2UgUEtDUyMxMCByZXF1ZXN0IGFuZCBjZXJ0aWZpY2F0ZXMv Q1JMcyBhcmUgc2VsZi1jb250YWluZWQNCj4gcHJvdGVjdGVkLCBidXQgdGhlcmUgaXMgbm90aGlu ZyBzaW1pbGFyIGZvciBzYXkgcmV2b2NhdGlvbiByZXF1ZXN0cy4NCg0KQSBDTVAgcnIgbWVzc2Fn ZSBpcyBhIHNlbGYtY29udGFpbmVkIHJldm9jYXRpb24gbWVzc2FnZS4gSXNuJ3QgaXQgc2ltaWxh ciB0byBQS0NTIzEwLCBjZXJ0aWZpY2F0ZSBhbmQgQ1JMPyBNYXkgYmUgaXQgbmVlZHMgdG8gYmUg YWRhcHRlZCBvciB0YWlsb3JlZC4gDQoNCj4gU2ltcGxlIHVzZSBjYXNlcyBjYW4gdXNlIHNpbXBs ZSBwcm90b2NvbHMsIGJ1dCBpdCB3aWxsIGJlIGhhcmQgSSB0aGluayB0bw0KPiBzdXBwb3J0IGNv bXBsZXggdXNlIGNhc2VzIHPhuoNpdGggc3VjaC4gVGhpcyBpcyB3aGVyZSBDTVAgc2hpbmVzLCBm b3INCj4gY29tcGxleCB1c2UgY2FzZXMsIGFuZCBJIGhhdmUgbm8gYW1iaXRpb24gdG8gcmVwbGFj ZSBDTVAuDQoNCkFncmVlLiBUaGF0IGlzIHdoeSBJIGxpa2UgdG8gZGVmaW5lIHRoZSB1c2UgY2Fz ZXMgZmlyc3QgOi0pDQoNCk1vc3Qgc2ltcGxlIHVzZSBjYXNlIHJlcXVpcmUgYSB0cnVzdGVkIGZp cnN0IGhvcC4gRm9yIG1hbnkgc2NlbmFyaW9zIHRoaXMgYXNzdW1wdGlvbiBkb2VzIG5vdCBob2xk IHRydWUuIFRoYXQgaXMgd2h5IEkgd291bGQgbGlrZSB0byBoYXZlIHNvbWUgZW5kLXRvLWVuZCBp bnRlZ3JpdHkgcHJvdGVjdGlvbi4NCkluIGEgbG90IG9mIGluZHVzdHJpYWwgZW52aXJvbm1lbnRz IG1lc3NhZ2VzIG5lZWQgdG8gYmUgdHJhbnNwb3J0ZWQgaW4gYSBzdG9yZS1hbmQtZm9yd2FyZCBm YXNoaW9uIGR1ZSB0byBuZXR3b3JrIHNlcGFyYXRpb24gb3IgcmVxdWlyZWQgZXhwbGljaXQgYWRt aW4gYXBwcm92YWwuIFRoYXQgaXMgd2h5IEkgbGlrZSBzZWxmLWNvbnRhaW5lZCBtZXNzYWdlIGlu dGVncml0eSBwcm90ZWN0aW9uLg0KDQpIZW5kcmlrDQoNCj4gT24gMjAxOS0wNi0xMiAwNzo0OSwg QnJvY2toYXVzLCBIZW5kcmlrIHdyb3RlOg0KPiA+PiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitp ZXRmQHNhbmRlbG1hbi5jYT4gIHdyb3RlOg0KPiA+Pg0KPiA+PiBCcm9ja2hhdXMsIEhlbmRyaWsg PGhlbmRyaWsuYnJvY2toYXVzQHNpZW1lbnMuY29tPiB3cm90ZToNCj4gPj4gICAgID4gSSB0aGlu ayB3ZSBuZWVkIHRvIGZpcnN0IGNvbGxlY3QgdGhlIHJlcXVpcmVkIGNlcnRpZmljYXRlIG1hbmFn ZW1lbnQNCj4gPj4gICAgID4gdXNlIGNhc2VzIGFuZCBjaGVjayBpZiB0aGV5IGFyZSBhZGRyZXNz ZWQgYnkgZXhpc3RpbmcgcHJvdG9jb2xzLg0KPiA+Pg0KPiA+PiBJIGRvbid0IHdhbnQgdG8gZG8g dGhhdC4gIEl0J3MgYm9pbGluZyB0aGUgb2NlYW4uDQo+ID4NCj4gPiBJTUhPIGtub3dpbmcgYWJv dXQgdGhlIHVzZXMgY2FzZXMgd2Ugd2FudCB0byBhZGRyZXNzIGlzIG5vdCAgJ2JvaWxpbmcgdGhl DQo+IG9jZWFuJy4gSWYgd2Ugd2FudCB0byBjb21lIHVwIHdpdGggYSBzb2x1dGlvbiB0aGF0IGZp dHMgb3VyIG5lZWRzLCB3ZSBzaG91bGQNCj4gZG8gdGhpcy4gT3RoZXIgdmljZSB3ZSBjb21lIHVw IHdpdGggYSBzb2x1dGlvbiB0aGF0IGxvb2tzIG5pY2UsIGJ1dCBjYW5ub3QgYmUNCj4gdXNlZCBm b3IgbWFqb3IgdXNlIGNhc2VzLiBMaWtlIEVTVCBpcyBhbiBpbnRlcmVzdGluZyBhcHByb2FjaCBm b3IgdGhlIGxhc3QgbWlsZSwNCj4gYnV0IGRvZXMgbm90IG9mZmVyIHJldm9jYXRpb24sIHNlbGYt Y29udGFpbmVkIG1lc3NhZ2VzIGFuZCBlbmQtdG8tZW5kDQo+IHNlY3VyaXR5LiBBbGwgYXJlIHJl cXVpcmVkIGluIG1vcmUgY29tcGxleCBzY2VuYXJpb3MuDQo+ID4NCj4gPiBJIHNlZSB0aGUgZm9s bG93aW5nIHJlcXVpcmVtZW50cy4NCj4gPiAtIEVucm9sbG1lbnQsIHVwZGF0ZSB1bmQgcmV2b2Nh dGlvbg0KPiA+IC0gTG9jYWwgYW5kIGNlbnRyYWwga2V5IGdlbmVyYXRpb24NCj4gPiAtIENvbmZp cm1hdGlvbiBvZiBjZXJ0aWZpY2F0ZSBlbnJvbGxtZW50L3VwZGF0ZQ0KPiA+IC0gUG9sbGluZyBm b3IgZGVsYXllZCBkZWxpdmVyeQ0KPiA+IC0gU29tZSBnZW5lcmFsIG1lc3NhZ2VzIGxpa2UgR2V0 Q1NSUGFyYW0gYW5kIFJvb3RDQUNlcnRVcGFkYXRlDQo+ID4gLSBBcHByb3ZhbCBvZiByZXF1ZXN0 IGJ5IGludGVybWVkaWF0ZSBSQXMsIGUuZy4gYnkgYWRkaW5nIGFkZGl0aW9uYWwNCj4gPiBzaWdu YXR1cmVzDQo+ID4gLSBTZWN1cml0eSBmZWF0dXJlcw0KPiA+ICAgLiBTZWxmLWNvbnRhaW5lZCBw cm90ZWN0aW9uIG9mIHJlcXVlc3RzL3Jlc3BvbnNlcyAoZW5kLXRvLWVuZCBzZWN1cml0eSkNCj4g PiAgIC4gUHJvb2Ytb2YtcG9zc2Vzc2lvbg0KPiA+ICAgLiBQcm9vZi1vZi1pZGVudGl0eSwgZS5n LiBzaWduYXR1cmUsIEhNQUMNCj4gPiAgIC4gUmVwbGF5IHByb3RlY3Rpb24sIGUuZy4gbm9uY2Vz DQo+ID4gICAuIFRpbWVsaW5lc3MsIGUuZy4gdGltZXN0YW1wcw0KPiA+DQo+ID4gU28gdGhlcmUg aXMgbm8gc3VycHJpc2UuIEJ1dCBzb21lIGZlYXR1cmVzIGxpa2Ugc2VsZi1jb250YWlucyBtZXNz YWdlcw0KPiB0b2dldGhlciB3aXRoIGFwcHJvdmFsIG9mIGFuIFJBIGlzIG5vdCBhdmFpbGFibGUg aW4gcHJvdG9jb2xzIGxpa2UgQUNNRSBhbmQNCj4gRVNULiBTbyB3ZSBjYW4gZGlzY3VzcyBleHRl bmRpbmcgdGhlc2UsIG9yIHdlIHV0aWxpemUgYW4gZXhpc3RpbmcgcHJvdG9jb2wgbGlrZQ0KPiBD TVAgdGhhdCBhbHJlYWR5IG9mZmVycyB0aGUgYWJvdmUgYW5kIGFkYXB0IGl0cyB0cmFuc3BvcnQg YW5kIG1lc3NhZ2VzIGZsb3cNCj4gdG8gUkVTVC4NCg== From nobody Wed Jun 12 05:30:06 2019 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 5C7171201AE for ; Wed, 12 Jun 2019 05:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 tAJJ-qYr0fYN for ; Wed, 12 Jun 2019 05:30:01 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7E41201B0 for ; Wed, 12 Jun 2019 05:30:00 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x5CCR5m4001182; Wed, 12 Jun 2019 13:29:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=s59vzD3xKFxARQgZo74h3YuWFCJKicKuw68mtiIKczI=; b=b0oMetwqoLeFtQgjVPZg3Y49lXjqqQl1StrMZUajVZPzlGNlw489Mm991x/G66O7yQiO 6x4wkfSTu94KEIrqqCuGQL35d/iU7sg7piLoRYjtswvYeoJLcNdqGlaZqRn8vMIsmVMS cpiDznGSU0iwztZrSIBA0iu3RBBe/64060W0J9/nmgAEeqyjX3GudJvZbf998ubXc52N hOwtrEzjrvBHjqr7dsLyHr1bLGF9SDrweAyY6gGlGsDf9naQmf7e41FP6Lb8HMTwxA7/ XbwboMjXMwp8xFlZ6FSYpWBa+46cL+0wAFOn30yVHlQh1fLs0FryIpMpgwztaNg7C4It Jw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2t2mabar3r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Jun 2019 13:29:58 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x5CCHvKF023840; Wed, 12 Jun 2019 08:29:57 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2t08bwu0hk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 12 Jun 2019 08:29:56 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 12 Jun 2019 08:29:56 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([::1]) by usma1ex-dag1mb3.msg.corp.akamai.com ([fe80::9049:d725:bf4b:d545%18]) with mapi id 15.00.1473.003; Wed, 12 Jun 2019 08:29:56 -0400 From: "Salz, Rich" To: "Brockhaus, Hendrik" , Michael Richardson , "spasm@ietf.org" Thread-Topic: [lamps] Interest to standardize PKI REST APIs? Thread-Index: AQHVGHCubVVgCDqctkmtGReH7tQ+IaaQvXOAgAAr9ACABu4NAIAALL+A Date: Wed, 12 Jun 2019 12:29:55 +0000 Message-ID: <978DF65B-7356-4D46-AE0B-BA6E468869F6@akamai.com> References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> <6992.1559937612@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.213] Content-Type: text/plain; charset="utf-8" Content-ID: <86F12B3591A8F64084471D25932FE772@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-12_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=1 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=1 mlxscore=1 mlxlogscore=205 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906120084 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-12_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=247 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906120086 Archived-At: Subject: Re: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jun 2019 12:30:03 -0000 PiAgICBTbyB0aGVyZSBpcyBubyBzdXJwcmlzZS4gQnV0IHNvbWUgZmVhdHVyZXMgbGlrZSBzZWxm LWNvbnRhaW5zIG1lc3NhZ2VzIHRvZ2V0aGVyIHdpdGggYXBwcm92YWwgb2YgYW4gUkEgaXMgbm90 IGF2YWlsYWJsZSBpbiBwcm90b2NvbHMgbGlrZSBBQ01FIGFuZCBFU1QuIFNvIHdlIGNhbiBkaXNj dXNzIGV4dGVuZGluZyB0aGVzZSwgb3Igd2UgdXRpbGl6ZSBhbiBleGlzdGluZyBwcm90b2NvbCBs aWtlIENNUCB0aGF0IGFscmVhZHkgb2ZmZXJzIHRoZSBhYm92ZSBhbmQgYWRhcHQgaXRzIHRyYW5z cG9ydCBhbmQgbWVzc2FnZXMgZmxvdyB0byBSRVNULg0KDQpBZGRpbmcgdGhpcyBraW5kIG9mIHRo aW5nIHRvIEFDTUUsIGFzIGEgbmV3IGNoYWxsZW5nZSBhbmQgcmVzcG9uc2UsIGlzIHZlcnkgc3Ry YWlnaHRmb3J3YXJkLg0KDQpBbHNvLCBsb29rIGF0IHRoZSBBQ01FICJTVEFSIiBkb2N1bWVudHMg d2hpY2ggaGFuZGxlIFJBLWxpa2UgZGVsZWdhdGlvbi4NCg0K From nobody Wed Jun 12 11:18:13 2019 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 73B60120280 for ; Wed, 12 Jun 2019 11:18:09 -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_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PHvo9iRgURM for ; Wed, 12 Jun 2019 11:18:05 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 26F11120236 for ; Wed, 12 Jun 2019 11:18:05 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id A07A43741042 for ; Wed, 12 Jun 2019 18:18:04 +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 wWfLhTjezC3C for ; Wed, 12 Jun 2019 14:18:03 -0400 (EDT) Received: from Maxs-MacBook-Pro.local (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 C93F53741025 for ; Wed, 12 Jun 2019 14:18:02 -0400 (EDT) To: spasm@ietf.org References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> From: "Dr. Pala" Message-ID: <23b41fcd-29e7-eb80-a397-e619072cd0fc@openca.org> Date: Wed, 12 Jun 2019 12:18:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------865391C4A6C2095F879DFAE0" Content-Language: en-US Archived-At: Subject: Re: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jun 2019 18:18:11 -0000 This is a multi-part message in MIME format. --------------865391C4A6C2095F879DFAE0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Tomas, all, I have not followed all the thread - however, it seems to me we already have what is being proposed. ACME is a web-oriented protocol that works for low-volume/low-efficiency issuance of certificates and works well for the Web PKI(s). Similarly, CMP and CMS allow for full management of credentials (although they require the client to be know what type of credentials are needed on the device). One thing I do not like about ACME and EST in particular (and probably about what you are proposing here), it is their dependency on the transport protocol - this is usually a very bad idea that prevents abstracting from the specific transport media, therefore limiting your options and require IP connectivity. From this point of view, I do not really see the need to define "yet another HTTP-based way to transfer the same information" - ACME already duplicated so much of the work we already have done 20 years ago with no relevant benefits besides being more inefficient, lacking all the more traditional controls, and not providing much benefits from an automation standpoint. Let's try to avoid doing the same mistake again :D I also would like to draw your attention on some work that is going on in some other WGs. In particular, we are working in the EMU WG to provide a EAP-Based method for credentials management (EAP-CREDS currently NOT a WG document, but we hope it will be adopted - https://datatracker.ietf.org/doc/draft-pala-eap-creds/) - you might find some inspiration for ideas there - we provide a minimal protocol for handling different types of secrets and the possibility to encapsulate your own protocol (e.g., an existing one like CMP or a proprietary one). Maybe this approach might inspire some further ideas in case you still want to pursue :D Last but not least, I think that if any standardization is needed (instead of "yet another API to do the same thing") is in the /*interface to your Cryptographic API*/. This is, I think, much more interesting (and needed). Today, I think, one of the main issue we have is to be able to integrate crypto libraries and being able to switch across platforms. Especially if you work in a application-level layer (maybe with JS or another interpreted language), you might have noticed that the support for the security primitives (and advanced functionalities) is not very well implemented. Moreover, porting to a different Crypto Service Provider is usually a nightmare... Why not working on a Standard API for Cryptographic Libraries instead ? Similarly to what we did for LDAP, this could provide the portability for applications (and programming frameworks) that we really need. We started a Mailing List sometime ago - but did not have the time to move forward with real work. If you are interested, please let me know. Just my 2 cents.... Cheers, Max P.S.: Last thing - as soon as we are done updating the CMS interface in LibPKI we will probably add support for either CMP or CMC. Maybe this is also relevant to your effort... :D On 6/7/19 11:22 AM, Brockhaus, Hendrik wrote: > Hi Tomas > > I fully understand your pain implementing many different proprietary APIs and I also dislike such proprietary APIs for certificate management. Typically such proprietary APIs or protocols lack the desired security features a certificate management protocol developed by an IETF Security WG offer. > That is the reason to enhance the usability of existing standards like CMP. This may also hold true for the request for RESTful APIs especially from cloud developer. > > I think we need to first collect the required certificate management use cases and check if they are addressed by existing protocols. > Then I see two approaches: > - Develop a new certificate management protocol using standard functionality of REST frameworks and learn from or even copy parts from existing protocols. > - Take an existing certificate management protocol, e.g. CMP, adapt the transport to REST APIs and adapt the transaction concept slightly to allow a state-less server. > As already said, I dislike to develop further certificate management protocols. I think there are enough around already. Therefor I would prefer the second approach. But finally the solution must be acceptable to the target audience of developers asking for REST APIs for certificate management. > > Are there also other opinions in the WG? > > Hendrik > >> -----Ursprüngliche Nachricht----- >> Von: Spasm Im Auftrag von Tomas Gustavsson >> Gesendet: Samstag, 1. Juni 2019 13:54 >> An: spasm@ietf.org >> Betreff: [lamps] Interest to standardize PKI REST APIs? >> >> Hi, >> >> This is a continuation of a topic that appeared in another thread, that I chose >> to start another thread about to not diverge the original thread. (original >> thread [lamps] Support for working on the lightweight CMP profile). Consider >> this an exploratory discussion. >> >> - Background: >> Today RESTful APIs are popular due to the simplicity of implementation on >> the client and on the server. I myself has worked with implementation on >> servers and clients for a range of standard APIs (such as SCEP, CMP, EST, >> ACME, PKCS#11 and more). I also find REST APIs engaging to work with as >> you don't need any special client software. If implementing in Java you just >> go at it with the standard API, if scripting you just use curl, etc. You also >> typically get easy to parse error messages back in JSON format. Very nice and >> easy. >> >> - Benefits of standard APIs >> Using standard APIs you get less lock-in effects. Less lock-in is typically good >> for the whole industry and use base long-term. Using standard APIs an end >> user can replace various components (clients, RA, >> CA) in their system to other vendors if they so desire. We have seen this >> work in practice, replacing CA technology components transparently for the >> rest of the system, quick and cost effective. >> IETF has been very good at producing industry wide standards used across >> multiple verticals. >> >> - Current REST-like protocols >> In lamps/pkix we have a couple of RESTlike APIs today. >> ACME for enrolling server certificates. A protocol for a specific purpose, but >> gaining popularity due to the easiness of implementing clients (often as >> scripts). >> EST is perhaps not a strict REST API but can be used in a similar form on the >> client side. All you need is openssl and curl to use it from the client side. >> >> - Current limitations >> In many deployments there are three components: client - RA - CA. EST and >> ACME typically runs on the client-RA side. EST also runs on the RA-CA side in >> simpler use cases. For more complex use cases, where say revocation is also >> needed it's more common to use CMP or a proprietary SOAP or REST API on >> the RA-CA side. Just to make this single point, the current REST-like APIs does >> not have revoke (EST has full-CMC method but that makes it complete non- >> REST-like and harder to implement). >> >> - Current "full" REST APIs >> Various products have REST APIs. These are proprietary (completely natural >> as there are no standards) and thus clients/RAs/CAs suffer from having to >> implements multiple REST APIs in order to be interoperable with various >> vendors. >> >> - Probe: >> Do others see the need/interest to standardize a more "full" REST API? >> We see requests and customer interest for REST APIs. Some of the >> requested REST functionality could very well be standardized, while some are >> more product specific and could be harder. >> >> Do others see the same? >> >> - Disclosure: >> I work for PrimeKey, a vendor who implements the (open source) CA >> software EJBCA. >> >> Regards, >> Tomas >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww >> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik. >> brockhaus%40siemens.com%7Cdf45bd27b9c241677a3a08d6e687d111%7C38a >> e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636949868334006281& >> sdata=rUYwh%2BPG4ZIdPzUYSWBOv1OvDb23N7fdHbyUOCup1dw%3D&am >> p;reserved=0 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------865391C4A6C2095F879DFAE0 Content-Type: multipart/related; boundary="------------7D53811841225BF2305CC872" --------------7D53811841225BF2305CC872 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Tomas, all,

I have not followed all the thread - however, it seems to me we already have what is being proposed. ACME is a web-oriented protocol that works for low-volume/low-efficiency issuance of certificates and works well for the Web PKI(s). Similarly, CMP and CMS allow for full management of credentials (although they require the client to be know what type of credentials are needed on the device).

One thing I do not like about ACME and EST in particular (and probably about what you are proposing here), it is their dependency on the transport protocol - this is usually a very bad idea that prevents abstracting from the specific transport media, therefore limiting your options and require IP connectivity.

From this point of view, I do not really see the need to define "yet another HTTP-based way to transfer the same information" - ACME already duplicated so much of the work we already have done 20 years ago with no relevant benefits besides being more inefficient, lacking all the more traditional controls, and not providing much benefits from an automation standpoint.

Let's try to avoid doing the same mistake again :D

I also would like to draw your attention on some work that is going on in some other WGs. In particular, we are working in the EMU WG to provide a EAP-Based method for credentials management (EAP-CREDS currently NOT a WG document, but we hope it will be adopted - https://datatracker.ietf.org/doc/draft-pala-eap-creds/) - you might find some inspiration for ideas there - we provide a minimal protocol for handling different types of secrets and the possibility to encapsulate your own protocol (e.g., an existing one like CMP or a proprietary one). Maybe this approach might inspire some further ideas in case you still want to pursue :D

Last but not least, I think that if any standardization is needed (instead of "yet another API to do the same thing") is in the interface to your Cryptographic API. This is, I think, much more interesting (and needed).

Today, I think, one of the main issue we have is to be able to integrate crypto libraries and being able to switch across platforms. Especially if you work in a application-level layer (maybe with JS or another interpreted language), you might have noticed that the support for the security primitives (and advanced functionalities) is not very well implemented. Moreover, porting to a different Crypto Service Provider is usually a nightmare...

Why not working on a Standard API for Cryptographic Libraries instead ? Similarly to what we did for LDAP, this could provide the portability for applications (and programming frameworks) that we really need. We started a Mailing List sometime ago - but did not have the time to move forward with real work. If you are interested, please let me know.

Just my 2 cents....

Cheers,
Max

P.S.: Last thing - as soon as we are done updating the CMS interface in LibPKI we will probably add support for either CMP or CMC. Maybe this is also relevant to your effort... :D

On 6/7/19 11:22 AM, Brockhaus, Hendrik wrote:
Hi Tomas

I fully understand your pain implementing many different proprietary APIs and I also dislike such proprietary APIs for certificate management. Typically such proprietary APIs or protocols lack the desired security features a certificate management protocol developed by an IETF Security WG offer.
That is the reason to enhance the usability of existing standards like CMP. This may also hold true for the request for RESTful APIs especially from cloud developer.

I think we need to first collect the required certificate management use cases and check if they are addressed by existing protocols.
Then I see two approaches:
- Develop a new certificate management protocol using standard functionality of REST frameworks and learn from or even copy parts from existing protocols. 
- Take an existing certificate management protocol, e.g. CMP, adapt the transport to REST APIs and adapt the transaction concept slightly to allow a state-less server.
As already said, I dislike to develop further certificate management protocols. I think there are enough around already. Therefor I would prefer the second approach. But finally the solution must be acceptable to the target audience of developers asking for REST APIs for certificate management.

Are there also other opinions in the WG?

Hendrik


-----Ursprüngliche Nachricht-----
Von: Spasm <spasm-bounces@ietf.org> Im Auftrag von Tomas Gustavsson
Gesendet: Samstag, 1. Juni 2019 13:54
An: spasm@ietf.org
Betreff: [lamps] Interest to standardize PKI REST APIs?

Hi,

This is a continuation of a topic that appeared in another thread, that I chose
to start another thread about to not diverge the original thread. (original
thread [lamps] Support for working on the lightweight CMP profile). Consider
this an exploratory discussion.

- Background:
Today RESTful APIs are popular due to the simplicity of implementation on
the client and on the server. I myself has worked with implementation on
servers and clients for a range of standard APIs (such as SCEP, CMP, EST,
ACME, PKCS#11 and more). I also find REST APIs engaging to work with as
you don't need any special client software. If implementing in Java you just
go at it with the standard API, if scripting you just use curl, etc. You also
typically get easy to parse error messages back in JSON format. Very nice and
easy.

- Benefits of standard APIs
Using standard APIs you get less lock-in effects. Less lock-in is typically good
for the whole industry and use base long-term. Using standard APIs an end
user can replace various components (clients, RA,
CA) in their system to other vendors if they so desire. We have seen this
work in practice, replacing CA technology components transparently for the
rest of the system, quick and cost effective.
IETF has been very good at producing industry wide standards used across
multiple verticals.

- Current REST-like protocols
In lamps/pkix we have a couple of RESTlike APIs today.
ACME for enrolling server certificates. A protocol for a specific purpose, but
gaining popularity due to the easiness of implementing clients (often as
scripts).
EST is perhaps not a strict REST API but can be used in a similar form on the
client side. All you need is openssl and curl to use it from the client side.

- Current limitations
In many deployments there are three components: client - RA - CA. EST and
ACME typically runs on the client-RA side. EST also runs on the RA-CA side in
simpler use cases. For more complex use cases, where say revocation is also
needed it's more common to use CMP or a proprietary SOAP or REST API on
the RA-CA side. Just to make this single point, the current REST-like APIs does
not have revoke (EST has full-CMC method but that makes it complete non-
REST-like and harder to implement).

- Current "full" REST APIs
Various products have REST APIs. These are proprietary (completely natural
as there are no standards) and thus clients/RAs/CAs suffer from having to
implements multiple REST APIs in order to be interoperable with various
vendors.

- Probe:
Do others see the need/interest to standardize a more "full" REST API?
We see requests and customer interest for REST APIs. Some of the
requested REST functionality could very well be standardized, while some are
more product specific and could be harder.

Do others see the same?

- Disclosure:
I work for PrimeKey, a vendor who implements the (open source) CA
software EJBCA.

Regards,
Tomas

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=02%7C01%7Chendrik.
brockhaus%40siemens.com%7Cdf45bd27b9c241677a3a08d6e687d111%7C38a
e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636949868334006281&amp;
sdata=rUYwh%2BPG4ZIdPzUYSWBOv1OvDb23N7fdHbyUOCup1dw%3D&am
p;reserved=0

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------7D53811841225BF2305CC872 Content-Type: image/png; name="kcagijffakcibplm.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="kcagijffakcibplm.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= --------------7D53811841225BF2305CC872-- --------------865391C4A6C2095F879DFAE0-- From nobody Wed Jun 12 13:33:56 2019 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 6094F120114 for ; Wed, 12 Jun 2019 13:33:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xdB5ktmVB5Q for ; Wed, 12 Jun 2019 13:33:53 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4671C12012C for ; Wed, 12 Jun 2019 13:33:53 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x5CKXpdU044893 for ; Wed, 12 Jun 2019 16:33:52 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x5CKXpdU044893 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1560371632; bh=MId2JI0ve41aMYNF/d0bW129LTl599yTaIwwZhKgzN8=; h=From:To:CC:Subject:Date:From; b=jny7ND+jW4FieXap5VcSv+1dcam7H4z0mB1zZYqSDeMYQcUtw82FPrqd7z6//Crss lDBHW34PRu2k8ayzf6gcxY5uTF66lY1zee0gmVMcN3/ZgzIBNGGAJtCiEZw3pXiLxo VhxucKLFEYint//g4RitiUgi2+Syv+Zer9cclEKk= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x5CKXkp0011573 for ; Wed, 12 Jun 2019 16:33:46 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Wed, 12 Jun 2019 16:33:46 -0400 From: Roman Danyliw To: "spasm@ietf.org" CC: Roman Danyliw Thread-Topic: AD Review: draft-ietf-lamps-cms-shakes-10 Thread-Index: AdUhXDrxK89BkN2JRRKFfOI84yckXw== Date: Wed, 12 Jun 2019 20:33:46 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3390A6A@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lamps] AD Review: draft-ietf-lamps-cms-shakes-10 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jun 2019 20:33:55 -0000 Hi! The following is my AD review of draft-lamps-cms-shakes-10: (1) Section 5. Isn't the request to IANA for OID assignment for id-RSASSA-= PSS-SHAKE128, id-RSASSA-PSS-SHAKE256, id-ecdsa-with-shake128, id-ecdsa-with= -shake256 a duplicate of what is in draft-ietf-lamps-pkix-shake? =3D=3D[ Editorial=20 (2) Editorial feedback on draft-ietf-lamps-pkix-shake applies here too: ** Header. Drop "RFC" from the updates line in the header - s/RFC3370/3370= / ** Section 1. Adding the reference of "(Appendix A.1 [SHA3])" for the sent= ence about "second preimage resistance strengths" ** Section 4.2.1. s/hash and mask generating algorithm and trailer and sal= t are/hash, mask generating algorithm, trailer, and salt are/ ** Section 4.2.1. Expand MGF on first use (which is at the end of Section = 2 but not as an acronym) (3) Section 3. Per the EDNOTE, I agree. It seems confusing to say that id= -RSASSA-PSS-SHAKE128, id-RSASSA-PSS-SHAKE256, id-ecdsa-with-shake128, id-ec= dsa-with-shake256 are being defined in this draft. Why not include a refer= ence to draft-ietf-lamps-pkix-shake (the same way there is one to shake-nis= t-oids)? (3) Section 3. Per id-KmacWithSHAKE128/256, provide a reference on where t= hese were defined and reuse the language used above that "we include them h= ere for convenience." (4) Section 4.2. Recommend precision in naming the fields: s/Signature values are located in the SignerInfo signature field of SignedD= ata and countersignature/ Signature values are located in the SignerInfo signature field of SignedDa= ta content type and countersignature attribute./ (5) Section 4.2.1. There appears to be an extra use of the word hash in th= is sentence: s/The hash algorithm to hash a message being signed and the hash and the ha= sh algorithm as the mask generation function used in RSASSA-PSS MUST be the= same, SHAKE128 or SHAKE256 respectively./ The hash algorithm to hash a message being signed and the hash algorithm as= the mask generation function used in RSASSA-PSS MUST be the same, SHAKE128= or SHAKE256 respectively. =20 Thanks, Roman From nobody Wed Jun 12 14:02:05 2019 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 DF3A5120178 for ; Wed, 12 Jun 2019 14:02:02 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 hdCFRKIN7-al for ; Wed, 12 Jun 2019 14:02:00 -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 68955120164 for ; Wed, 12 Jun 2019 14:02:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 74F57300A91 for ; Wed, 12 Jun 2019 16:42:42 -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 uoljywpfnGUL for ; Wed, 12 Jun 2019 16:42:41 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 8522930024B; Wed, 12 Jun 2019 16:42:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3390A6A@marathon> Date: Wed, 12 Jun 2019 17:01:58 -0400 Cc: "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <115F9F9E-5219-4627-87A5-9268315FED49@vigilsec.com> References: <359EC4B99E040048A7131E0F4E113AFC01B3390A6A@marathon> To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] AD Review: draft-ietf-lamps-cms-shakes-10 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jun 2019 21:02:03 -0000 Roman: > The following is my AD review of draft-lamps-cms-shakes-10: >=20 > (1) Section 5. Isn't the request to IANA for OID assignment for = id-RSASSA-PSS-SHAKE128, id-RSASSA-PSS-SHAKE256, id-ecdsa-with-shake128, = id-ecdsa-with-shake256 a duplicate of what is in = draft-ietf-lamps-pkix-shake? Yes, this is the same request. The OIDs, once assigned, need to appear = in both documents. Russ From nobody Wed Jun 12 23:45:13 2019 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 22F3712023D for ; Wed, 12 Jun 2019 23:45:10 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=HDgCv8UB; dkim=pass (1024-bit key) header.d=primekey.com header.b=HDgCv8UB 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 jbtpBMAW0bPc for ; Wed, 12 Jun 2019 23:45:06 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1970B120219 for ; Wed, 12 Jun 2019 23:45:05 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 2FA7C6AA0090 for ; Thu, 13 Jun 2019 08:44:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1560408297; bh=EnMH/15pFlVnMh76TuB+eonk2OHbW60stroYNG4F/4I=; h=Subject:To:References:From:Date:In-Reply-To:From; b=HDgCv8UB5ieQ1iD2aoNT+GQDkQBhOfkAHOY+0yDksOmrFoAKBAdw4RwH4nE8wVT7E cv8AIU/7cnVlY8dAaSAxAtz5JYOju+3CVnMebY4ofty1X0Ei4Se3HsAC5YzMdPO84N ANrMEhb/qgIjSSzjss+3bQi8cgfV1xEZOZ6VV3JQ= Received: from [10.11.0.9] (gatekeeper.primekey.se [84.55.121.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 8192A6AA008F for ; Thu, 13 Jun 2019 08:44:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1560408297; bh=EnMH/15pFlVnMh76TuB+eonk2OHbW60stroYNG4F/4I=; h=Subject:To:References:From:Date:In-Reply-To:From; b=HDgCv8UB5ieQ1iD2aoNT+GQDkQBhOfkAHOY+0yDksOmrFoAKBAdw4RwH4nE8wVT7E cv8AIU/7cnVlY8dAaSAxAtz5JYOju+3CVnMebY4ofty1X0Ei4Se3HsAC5YzMdPO84N ANrMEhb/qgIjSSzjss+3bQi8cgfV1xEZOZ6VV3JQ= To: spasm@ietf.org References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> <12129.1559329924@localhost> <7f83213b-2e63-57f5-5a1a-956d47b58683@primekey.com> <23b41fcd-29e7-eb80-a397-e619072cd0fc@openca.org> From: Tomas Gustavsson Openpgp: preference=signencrypt Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= mQENBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAG0MFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPokB NwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5uQENBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAGJAR8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <4dceb42d-c91a-b0de-743b-889632daf46c@primekey.com> Date: Thu, 13 Jun 2019 08:45:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <23b41fcd-29e7-eb80-a397-e619072cd0fc@openca.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] Interest to standardize PKI REST APIs? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 06:45:10 -0000 On 2019-06-12 20:18, Dr. Pala wrote: > Hi Tomas, all, > > I have not followed all the thread - however, it seems to me we already > have what is being proposed. ACME is a web-oriented protocol that works > for low-volume/low-efficiency issuance of certificates and works well > for the Web PKI(s). Similarly, CMP and CMS allow for full management of > credentials (although they require the client to be know what type of > credentials are needed on the device). > > One thing I do not like about ACME and EST in particular (and probably > about what you are proposing here), it is their dependency on the > transport protocol - this is usually a very bad idea that prevents > abstracting from the specific transport media, therefore limiting your > options and require IP connectivity. > > From this point of view, I do not really see the need to define "yet > another HTTP-based way to transfer the same information" - ACME already > duplicated so much of the work we already have done 20 years ago with no > relevant benefits besides being more inefficient, lacking all the more > traditional controls, and not providing much benefits from an automation > standpoint. > > Let's try to avoid doing the same mistake again :D I think it's about using the right tool for the right jobs, and a full toolbox is needed :-) Simply looking at the usage of ACME I think it's clear that it does provide some standardization benefits, for this/these use cases. Otherwise we would not see the quick uptake and use I believe. So some benefits there must be. There will be many REST APIs created, within IETF or not. With a little luck there may be some harmonization driven by market needs. > I also would like to draw your attention on some work that is going on > in some other WGs. In particular, we are working in the EMU WG to > provide a EAP-Based method for credentials management (EAP-CREDS > currently NOT a WG document, but we hope it will be adopted - > https://datatracker.ietf.org/doc/draft-pala-eap-creds/) - you might find > some inspiration for ideas there - we provide a minimal protocol for > handling different types of secrets and the possibility to encapsulate > your own protocol (e.g., an existing one like CMP or a proprietary one). > Maybe this approach might inspire some further ideas in case you still > want to pursue :D > > Last but not least, I think that if any standardization is needed > (instead of "yet another API to do the same thing") is in the > /*interface to your Cryptographic API*/. This is, I think, much more > interesting (and needed). > > Today, I think, one of the main issue we have is to be able to integrate > crypto libraries and being able to switch across platforms. Especially > if you work in a application-level layer (maybe with JS or another > interpreted language), you might have noticed that the support for the > security primitives (and advanced functionalities) is not very well > implemented. Moreover, porting to a different Crypto Service Provider is > usually a nightmare... > > Why not working on a Standard API for Cryptographic Libraries instead ? > Similarly to what we did for LDAP, this could provide the portability > for applications (and programming frameworks) that we really need. We > started a Mailing List sometime ago - but did not have the time to move > forward with real work. If you are interested, please let me know. All platforms/OS/programming languages have their standards. This will be hard to sell. Something that would be very useful (from my usage) is a new standard API for HSMs. PKCS#11 have been ruling this area for decades, but large fragmentation is happening now (let's hope a bit on PKCS#11 v3). Also not a topic I want to spend the rest of my days on though, it will be a lengthy process and a tough sale... > > Just my 2 cents.... > > Cheers, > Max > > P.S.: Last thing - as soon as we are done updating the CMS interface in > LibPKI we will probably add support for either CMP or CMC. Maybe this is > also relevant to your effort... :D > > On 6/7/19 11:22 AM, Brockhaus, Hendrik wrote: >> Hi Tomas >> >> I fully understand your pain implementing many different proprietary APIs and I also dislike such proprietary APIs for certificate management. Typically such proprietary APIs or protocols lack the desired security features a certificate management protocol developed by an IETF Security WG offer. >> That is the reason to enhance the usability of existing standards like CMP. This may also hold true for the request for RESTful APIs especially from cloud developer. >> >> I think we need to first collect the required certificate management use cases and check if they are addressed by existing protocols. >> Then I see two approaches: >> - Develop a new certificate management protocol using standard functionality of REST frameworks and learn from or even copy parts from existing protocols. >> - Take an existing certificate management protocol, e.g. CMP, adapt the transport to REST APIs and adapt the transaction concept slightly to allow a state-less server. >> As already said, I dislike to develop further certificate management protocols. I think there are enough around already. Therefor I would prefer the second approach. But finally the solution must be acceptable to the target audience of developers asking for REST APIs for certificate management. >> >> Are there also other opinions in the WG? >> >> Hendrik >> >>> -----Ursprüngliche Nachricht----- >>> Von: Spasm Im Auftrag von Tomas Gustavsson >>> Gesendet: Samstag, 1. Juni 2019 13:54 >>> An: spasm@ietf.org >>> Betreff: [lamps] Interest to standardize PKI REST APIs? >>> >>> Hi, >>> >>> This is a continuation of a topic that appeared in another thread, that I chose >>> to start another thread about to not diverge the original thread. (original >>> thread [lamps] Support for working on the lightweight CMP profile). Consider >>> this an exploratory discussion. >>> >>> - Background: >>> Today RESTful APIs are popular due to the simplicity of implementation on >>> the client and on the server. I myself has worked with implementation on >>> servers and clients for a range of standard APIs (such as SCEP, CMP, EST, >>> ACME, PKCS#11 and more). I also find REST APIs engaging to work with as >>> you don't need any special client software. If implementing in Java you just >>> go at it with the standard API, if scripting you just use curl, etc. You also >>> typically get easy to parse error messages back in JSON format. Very nice and >>> easy. >>> >>> - Benefits of standard APIs >>> Using standard APIs you get less lock-in effects. Less lock-in is typically good >>> for the whole industry and use base long-term. Using standard APIs an end >>> user can replace various components (clients, RA, >>> CA) in their system to other vendors if they so desire. We have seen this >>> work in practice, replacing CA technology components transparently for the >>> rest of the system, quick and cost effective. >>> IETF has been very good at producing industry wide standards used across >>> multiple verticals. >>> >>> - Current REST-like protocols >>> In lamps/pkix we have a couple of RESTlike APIs today. >>> ACME for enrolling server certificates. A protocol for a specific purpose, but >>> gaining popularity due to the easiness of implementing clients (often as >>> scripts). >>> EST is perhaps not a strict REST API but can be used in a similar form on the >>> client side. All you need is openssl and curl to use it from the client side. >>> >>> - Current limitations >>> In many deployments there are three components: client - RA - CA. EST and >>> ACME typically runs on the client-RA side. EST also runs on the RA-CA side in >>> simpler use cases. For more complex use cases, where say revocation is also >>> needed it's more common to use CMP or a proprietary SOAP or REST API on >>> the RA-CA side. Just to make this single point, the current REST-like APIs does >>> not have revoke (EST has full-CMC method but that makes it complete non- >>> REST-like and harder to implement). >>> >>> - Current "full" REST APIs >>> Various products have REST APIs. These are proprietary (completely natural >>> as there are no standards) and thus clients/RAs/CAs suffer from having to >>> implements multiple REST APIs in order to be interoperable with various >>> vendors. >>> >>> - Probe: >>> Do others see the need/interest to standardize a more "full" REST API? >>> We see requests and customer interest for REST APIs. Some of the >>> requested REST functionality could very well be standardized, while some are >>> more product specific and could be harder. >>> >>> Do others see the same? >>> >>> - Disclosure: >>> I work for PrimeKey, a vendor who implements the (open source) CA >>> software EJBCA. >>> >>> Regards, >>> Tomas >>> >>> _______________________________________________ >>> Spasm mailing list >>> Spasm@ietf.org >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww >>> ..ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik. >>> brockhaus%40siemens.com%7Cdf45bd27b9c241677a3a08d6e687d111%7C38a >>> e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636949868334006281& >>> sdata=rUYwh%2BPG4ZIdPzUYSWBOv1OvDb23N7fdHbyUOCup1dw%3D&am >>> p;reserved=0 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > OpenCA Logo > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Thu Jun 13 13:49:31 2019 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 448C41204EB; Thu, 13 Jun 2019 13:49:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rdd@cert.org, lamps-chairs@ietf.org, Russ Housley , housley@vigilsec.com, spasm@ietf.org, The IESG , draft-ietf-lamps-rfc6844bis@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156045895327.12531.4711133726736014377.idtracker@ietfa.amsl.com> Date: Thu, 13 Jun 2019 13:49:13 -0700 Archived-At: Subject: [lamps] Protocol Action: 'DNS Certification Authority Authorization (CAA) Resource Record' to Proposed Standard (draft-ietf-lamps-rfc6844bis-07.txt) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 20:49:14 -0000 The IESG has approved the following document: - 'DNS Certification Authority Authorization (CAA) Resource Record' (draft-ietf-lamps-rfc6844bis-07.txt) as Proposed Standard This document is the product of the Limited Additional Mechanisms for PKIX and SMIME Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6844bis/ Technical Summary The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. Working Group Summary There is consensus for this document in the LAMPS WG. Document Quality S/MIME has wide support, and several implementers have said that they will implement this specification. The CA/Browser Forum has been very vocal that they are planning to require CAs to implement it, so that community has reviewed it carefully. Personnel Russ Housley is the document shepherd. Roman Danyliw is the responsible area director. From nobody Thu Jun 13 23:24:26 2019 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 A03E71200B5 for ; Thu, 13 Jun 2019 23:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4kiiiXVuqNd for ; Thu, 13 Jun 2019 23:24:22 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (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 945B81200F6 for ; Thu, 13 Jun 2019 23:24:18 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id x5E6OGm1019341 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 14 Jun 2019 08:24:16 +0200 Received: from DEFTHW99ERLMSX.ww902.siemens.net (defthw99erlmsx.ww902.siemens.net [139.22.70.136]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id x5E6OFOg023798 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 14 Jun 2019 08:24:16 +0200 Received: from DEFTHW99ER8MSX.ww902.siemens.net (139.22.70.73) by DEFTHW99ERLMSX.ww902.siemens.net (139.22.70.136) with Microsoft SMTP Server (TLS) id 14.3.435.0; Fri, 14 Jun 2019 08:24:15 +0200 Received: from DENBGAT9EJ5MSX.ww902.siemens.net ([169.254.12.220]) by DEFTHW99ER8MSX.ww902.siemens.net ([139.22.70.73]) with mapi id 14.03.0435.000; Fri, 14 Jun 2019 08:24:14 +0200 From: "Fries, Steffen" To: "spasm@ietf.org" Thread-Topic: Charter discussion Thread-Index: AdUieMNE0ThLDuQQTsGvDFcsSaas7A== Date: Fri, 14 Jun 2019 06:24:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified x-originating-ip: [139.22.70.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lamps] Charter discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jun 2019 06:24:25 -0000 Hi, Just a short question regarding the charter discussion. Based on the discus= sion on the mailing list I was not sure if the discussion is stuck or if th= e charter has been finalized already. The status on https://datatracker.iet= f.org/doc/charter-ietf-lamps/ states approved, but note all of the recently= discussed points made it into the charter. Based on the discussion regardi= ng lightweight-profile for CMP I had the impression there was sufficient in= terest. Does it mean it is rejected for the current charter? Best regards Steffen From nobody Fri Jun 14 12:11:23 2019 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 96F8112011C for ; Fri, 14 Jun 2019 12:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 header.b=LsNh3eHd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=F5MsUzSu 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_hNa4zwbrRN for ; Fri, 14 Jun 2019 12:11:18 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3548C120058 for ; Fri, 14 Jun 2019 12:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3258; q=dns/txt; s=iport; t=1560539478; x=1561749078; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fwnwFZ4jbtozkRKTwzcHGJ0EJ+8zT603XjXQAV+DD1g=; b=LsNh3eHd0JWBerT9qrByGbn4bl4GsQqQ/eZcGKKIGzuOWh4rppjBAJ1k 08JAXyBYREoGegBTb1jD2RkFkBNGgertsFznzdsH9A+kqGF1+x+FIKv/4 tes5fK8Jte0h7s2Va/b4Efq0e5VaofjJpQL3c5JZqQY6hrbiZbcqpdJWm I=; IronPort-PHdr: =?us-ascii?q?9a23=3AzwoNmxL4HbgSoCutbdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFX4JfvyZiozNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAADT8ANd/4UNJK1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBPVADalUgBAsoh10DhFKKEEqCDZc1gS6BJAN?= =?us-ascii?q?UCQEBAQwBARgNCAIBAYRAAoJMIzQJDgEDAQEEAQECAQRtHAyFSgEBAQEDAQE?= =?us-ascii?q?QKAYBASwMCwQCAQgOAwQBAR8QJwsdCAEBBAESCBqDAYFqAx0BAgyeCgKBOIh?= =?us-ascii?q?fgiKCeQEBBYEyAYNLGIIPAwaBNAGLXBeBQD+BEUaCTD6CYQEBAoFhgzqCJot?= =?us-ascii?q?cnXwJAoIQhkiNJJcyjRyHII88AgQCBAUCDgEBBYFPOIFYcBU7gmwTgXwLARe?= =?us-ascii?q?DTYUUhT9yCoEfjygBAQ?= X-IronPort-AV: E=Sophos;i="5.63,373,1557187200"; d="scan'208";a="288038293" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jun 2019 19:11:16 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x5EJBGxq013338 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Jun 2019 19:11:16 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 14 Jun 2019 14:11:16 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 14 Jun 2019 15:11:15 -0400 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 14 Jun 2019 15:11:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KqrkC9z47nZF3QKfDS6VEd9e15R94nkI62IXJUwRLWs=; b=F5MsUzSu18RwPQY6Djg3UPIMlbwToSxsfj8HrejiCEhpAC6mNnP6cr1A+SB5cmj0cWr+G4kLFjNxTkxlaU02osq0gH0JND25zaSkKLO0KALA7tOukJmBcWlLgzUVg/XkW7YhELZmqzHREuP2Xiv760r+7E+bjy2WKt/H/L/iaNI= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.244.29) by BN7PR11MB2626.namprd11.prod.outlook.com (52.135.244.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Fri, 14 Jun 2019 19:11:14 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::89af:3fb4:eae5:18b2]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::89af:3fb4:eae5:18b2%7]) with mapi id 15.20.1987.013; Fri, 14 Jun 2019 19:11:14 +0000 From: "Panos Kampanakis (pkampana)" To: Roman Danyliw , "spasm@ietf.org" Thread-Topic: AD Review: draft-ietf-lamps-cms-shakes-10 Thread-Index: AdUhXDrxK89BkN2JRRKFfOI84yckXwBhq97A Date: Fri, 14 Jun 2019 19:11:12 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01B3390A6A@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3390A6A@marathon> 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=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1004::26] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4f1c5e6c-ff6c-48eb-6001-08d6f0fc11ca x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2626; x-ms-traffictypediagnostic: BN7PR11MB2626: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2276; x-forefront-prvs: 0068C7E410 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(366004)(376002)(136003)(189003)(199004)(13464003)(2501003)(73956011)(186003)(229853002)(8676002)(7696005)(66946007)(74316002)(33656002)(6506007)(53546011)(478600001)(102836004)(76176011)(5660300002)(81166006)(86362001)(14454004)(81156014)(8936002)(966005)(99286004)(446003)(110136005)(316002)(68736007)(6116002)(305945005)(52536014)(11346002)(66556008)(476003)(46003)(6246003)(14444005)(66446008)(6436002)(7736002)(25786009)(486006)(71190400001)(6306002)(71200400001)(55016002)(76116006)(64756008)(9686003)(256004)(53936002)(66476007)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2626; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hc/osns3TUMJT5p1VgxkHC5iZ5EcRPnRYYjuAfRsAyECXfQV6vGkvamexGdCx0yGNWyhrnrocB09uTDIz4Yx/h2YLD8QEAx+qlpq8mAiI2RuhcNpt18PgIAdNhv8KcB1umn0K/i8CVOxOuMit+nXOISdjECDl7sx3mdLvq5mY0cLAozQB3WQvdBD4R3JzlkMqLZuo+fRB9afj5HCxate90Z4fdTjOEdIgHZryj/vR1y7+o5hqarNgZ837+pcPexmgTRPv43oCIv/e8q2rQRwWGJBEmYT48J4Kynsf04tHSB5n3uAqvBs9FUA7KEZfrU666tOzLdVolvthEV9PokDPjJGP5fD2CJNBQqmq9fclqCnFtbVa+suhTYSNyYNSPfd4V2Y0rN4O/Vl8CSkYIEMtIQ6w3EC9x+chcLBBNALZYg= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4f1c5e6c-ff6c-48eb-6001-08d6f0fc11ca X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2019 19:11:13.8145 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkampana@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2626 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [lamps] AD Review: draft-ietf-lamps-cms-shakes-10 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jun 2019 19:11:23 -0000 Hi Roman, Thank you again. All addressed. The diffs are here https://github.com/csost= o-pk/adding-shake-to-pkix/commit/0efc652142d355944585b4c6d8e7d512a68d69b9=20 The specific details of the fixes are in the github issue https://github.co= m/csosto-pk/adding-shake-to-pkix/issues/45#issuecomment-501801167=20 One basic comment is that the OIDs defined in the PKIX draft are reused in = this one, but I don't request them in the IANA considerations sections any = more since they will be defined in the other RFC already. So let's try to p= ublish the PKIX one first and the CMS after that.=20 I am planning upload this new iteration early next week unless there are mo= re comments.=20 Rgs, Panos -----Original Message----- From: Spasm On Behalf Of Roman Danyliw Sent: Wednesday, June 12, 2019 4:34 PM To: spasm@ietf.org Cc: Roman Danyliw Subject: [lamps] AD Review: draft-ietf-lamps-cms-shakes-10 Hi! The following is my AD review of draft-lamps-cms-shakes-10: (1) Section 5. Isn't the request to IANA for OID assignment for id-RSASSA-= PSS-SHAKE128, id-RSASSA-PSS-SHAKE256, id-ecdsa-with-shake128, id-ecdsa-with= -shake256 a duplicate of what is in draft-ietf-lamps-pkix-shake? =3D=3D[ Editorial=20 (2) Editorial feedback on draft-ietf-lamps-pkix-shake applies here too: ** Header. Drop "RFC" from the updates line in the header - s/RFC3370/3370= / ** Section 1. Adding the reference of "(Appendix A.1 [SHA3])" for the sent= ence about "second preimage resistance strengths" ** Section 4.2.1. s/hash and mask generating algorithm and trailer and sal= t are/hash, mask generating algorithm, trailer, and salt are/ ** Section 4.2.1. Expand MGF on first use (which is at the end of Section = 2 but not as an acronym) (3) Section 3. Per the EDNOTE, I agree. It seems confusing to say that id= -RSASSA-PSS-SHAKE128, id-RSASSA-PSS-SHAKE256, id-ecdsa-with-shake128, id-ec= dsa-with-shake256 are being defined in this draft. Why not include a refer= ence to draft-ietf-lamps-pkix-shake (the same way there is one to shake-nis= t-oids)? (3) Section 3. Per id-KmacWithSHAKE128/256, provide a reference on where t= hese were defined and reuse the language used above that "we include them h= ere for convenience." (4) Section 4.2. Recommend precision in naming the fields: s/Signature values are located in the SignerInfo signature field of SignedD= ata and countersignature/ Signature values are located in the SignerInfo s= ignature field of SignedData content type and countersignature attribute./ (5) Section 4.2.1. There appears to be an extra use of the word hash in th= is sentence: s/The hash algorithm to hash a message being signed and the hash and the ha= sh algorithm as the mask generation function used in RSASSA-PSS MUST be the= same, SHAKE128 or SHAKE256 respectively./ The hash algorithm to hash a message being signed and the hash algorithm as= the mask generation function used in RSASSA-PSS MUST be the same, SHAKE128= or SHAKE256 respectively. =20 Thanks, Roman _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Jun 14 14:26:48 2019 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 93844120228; Fri, 14 Jun 2019 14:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96J1yTPzNeU4; Fri, 14 Jun 2019 14:26:43 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51AE5120225; Fri, 14 Jun 2019 14:26:42 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5ELQcBZ020932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Jun 2019 17:26:40 -0400 Date: Fri, 14 Jun 2019 16:26:37 -0500 From: Benjamin Kaduk To: Russ Housley Cc: IESG , SPASM Message-ID: <20190614212637.GV52381@kduck.mit.edu> References: <155916984601.5535.15415810479866156115.idtracker@ietfa.amsl.com> <83521276-738B-4298-A36D-B3C04E11A05C@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jun 2019 21:26:47 -0000 Hi Russ, On Tue, Jun 11, 2019 at 12:34:35PM -0400, Russ Housley wrote: > Ben: > > I have not heard back from you. Please let me know if the proposed way forward would resolve your DISCUSS position. Sorry; it was a busy couple weeks for my personal life. > Russ > > > > On May 31, 2019, at 1:03 PM, Russ Housley wrote: > > > > Ben: > > > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> After further reflection, I think we need to resurrect the discussion > >> sparked by DKG's last-call review. Specifically, in Section 5 when we > >> consider the case that there is not a directory service/repository > >> available, we give guidance to "the recipient" and "recipients". But in > >> at least some cases, there are two tiers of recipients/relying parties, > >> that have different properties, as in the web PKI situation. > >> Specifically, web server operators rely on root CAs to certify the > >> certificates that they present to TLS clients. But we also consider the > >> TLS clients themselves, which may not have a direct path to receiving > >> the updated root CA self-signed certificate, and because of the > >> different ways these different types of recipient rely on root CA > >> information, the order in which they update can cause breakage. We do > >> not necessarily need to present a clear solution that will always avoid > >> this breakage, but I do think we need to at least discuss the > >> possibility of such scenarios. > >> > >> To consider a concrete case, consider a system with a TLS client ("A"), > >> a TLS server ("B"), and the root CA ("C"). C issues (potentially via > >> intermediates) an end-entity certificate for B, and we consider a case > >> where A initiates TLS connections to B. Initially, C has the root > >> CA/key at C1, and is initiating a transition to C2; before the > >> transition both A and B have C1 in their trusted store. When A receives > >> C2, it can perform the requisite validation and add C2 to its trust > >> store for use potentially validating incoming certificate chains. When > >> B receives C2, it can similarly perform the requisite validation and add > >> C2 to its trust store, but B's trust store is used for validating > >> *outgoing* certificate chains, not (just) incoming ones. If B were to > >> keep C2 in its trust store and construct an outgoing certificate chain > >> based on C2 (and omitting oldWithNew and newWithOld), before A has > >> received C2, then the TLS handshake fails! > >> > >> If A had access to C2, or to oldWithnew/NewWithOld, then it would still > >> be able to validate B's certificate chain, but this document (and RFC > >> 4210) do not give guidance that B should transmit newWithOld to A, > >> leaving open this scenario for breakage. > >> > >> My current inclination is to add some text to this document acknowleding > >> the potential for a chain of relying parties, and recommending that the > >> "intermediate parties" in the scenario make newWithOld/oldWithNew available until > >> the notAfter time from oldWithNew, but I am of course open to further > >> discussion/suggestions. > > > > I think that the document is fairly clear that there can be some failure if there is not a repository or directory service. However, while thinking about this over night, I realized that we could also point to the the Subject Information Access certificate extension in RFC 5280, Section 4.2.2.2. I don't really feel like that clear picture is getting conveyed, though. (Which is not to say that adding text about this extension is a bad idea, of course!) Focusing on the Operational Considerations, and taking an example: Guidance on the transition from one trust anchor to another is available in Section 4.4 of [RFC4210]. In particular, the oldWithNew and newWithOld advice ensures that relying parties are able to validate certificates issued under the current Root CA certificate and the next generation Root CA certificate throughout the transition. [...] To me, this comes across as saying that the existence of oldWithNew and newWithOld takes care of everything and "ensures that relying parties are able to validate certificates". Perhaps the subtlety lies in the definition of "relying party" -- RFC 4210 is of course pretty well steeped in the repository/directory service setup. It's also interesting to me to note, though, that RFC 4120 talks about the entities that need to worry about getting the CA public keys as being the entities that themselves have certificates (e.g., "typically be easily achieved when these end entities' certificates expire"). While that's a valid use case, it does seem a bit divorced from the (e.g., Web) case where the entity that needs the CA public key does not have a certificate, such as when it's a browser. > > The id-ad-caRepository OID is used when the subject is a CA that > > publishes certificates it issues in a repository. The accessLocation > > field is defined as a GeneralName, which can take several forms. > > > > ... > > > > Where the information is available via HTTP or FTP, accessLocation > > MUST be a uniformResourceIdentifier and the URI MUST point to either > > a single DER encoded certificate as specified in [RFC2585] or a > > collection of certificates in a BER or DER encoded "certs-only" CMS > > message as specified in [RFC2797]. > > > > I am willing to RECOMMEND the inclusion of this extension and posting the oldWithNew and newWithOld so that they can be fetched using the "certs-only" (simple PKI response). This format would allow certificates to be added and removed from the bag of certificates over time. That does seem worth doing. I think what would best help move the document forward right now would be for you to point me at the existing text that is "fairly clear that there can be some failure if there is not a repository or directory service.", since I seem to have missed it. Text that matches that description should be enough to resolve the Discuss point -- we don't need to bend over backwards to satisfy the Web PKI case when the mechanism works fine as-is in other use cases. > >> Separately, I just want to quickly check that the id-ce-hashOfRootKey > >> OID has been properly allocated and recorded, as I couldn't find > >> evidence to indicate that in a quick search. I assume this is the > >> origin of the CTIA acknowledgment that Alissa mentions, but there's not > >> quite enough there to connect the dots. > > > > CTIA allocated the OID for the ASN.1 module and the OID for the certificate extension from their arc. In response to Alissa's comment, I suggested an additional sentence for the Acknowledgements to make this clear. I did see that after I balloted; it looks great. > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> Section 1.1 > >> > >> Please use the boilerplate from RFC 8174 (yes, I read the shepherd writeup). > > > > Already fixed in my edit buffer. > > > >> Section 1.2 > >> > >> side note: this claim about "always encoded with DER" seems a bit > >> optimistic unless scoped down to a specific context. > > > > X.509 and RFC 5280 require the DER encoding for the signature computation and the signature validation. If someone uses a different encoding somewhere along the way, it needs to be put back in DER form for the signature to validate. > > > > How about: > > > > Certificates [RFC5280] use ASN.1 [X680]; Distinguished Encoding Rules > > (DER) [X690] are REQUIRED for certificate signing and validation. That avoids the issue I was worried about, though at the risk of using normative language to restate a normative requirement from a different document. > >> Section 5 > >> > >> After issuing the oldWithNew and newWithOld certificates, the Root CA > >> MUST stop using the old private key to sign certificates. > >> > >> Isn't this only relevant for newWithOld? We don't need to use the old > >> private key to sign certificates to make a certification of the old key > >> signed by the new key. > > > > This is a statement about when to stop using the old private key. But, indeed, you are correct: > > > > After issuing the newWithOld certificate, the Root CA MUST stop using > > the old private key to sign certificates. > > > >> Changing names from one generation to another can lead to confusion > >> when reviewing the history of a trust anchor store. To assist with > >> such review, a recipient MAY create an audit entry to capture the old > >> and replacement self-signed certificates. > >> > >> It seems like there may be non-name changes that might also cause > >> confusion (or worse); do we want to mention this possibility and/or the > >> recipient's duty to check for unexpected changes? > > > > This was a recommendation from DKC in the thread that you reference in your DISCUSS comments. I do not know of any relying part software that keeps the audit log of changes to the trust store. Many software update programs, for example, update the trust anchor store without creating such an audit. I am not sure that building further on this concept is desirable. I'm happy to leave this alone. > >> Section 6 > >> > >> I think some explicit guidance is needed about there being a critical > >> operational issue in the (unexpected) case of the cryptographic > >> breakdown of the hash function used to compute HashedRootKey. The > >> current discussion of needing a hash function that is preimage-resistant > >> is good, of course, but some indication of the consequences if a has > >> function becomes bad during the course of use (or a bad hash function is > >> chosen initially) seems to be in order. > > > > How about adding this sentence to the end of that paragraph: > > > > If the employed hash function is broken after the Root CA publishes > > the self-signed certificate with the HashOfRootKey certificate > > extension, an attacker would be able to trick the recipient into > > installing the incorrect next generation certificate in the trust > > anchor store. Wonderful; thanks! > >> I also agree with the secdir reviewer that some guidance about how to > >> know that the first trasition is complete would be nice (in the absence > >> of the RFC 4210 transition process), but understand that such guidance > >> is hard to give. > > > > I do not have great advice, but there is a hint: > > > > Queries for the CRLs associated with certificates that are > > subordinate to the self-signed certificate can give some > > indication for the number of relying parties that are still > > actively using the self-signed certificates. Ah, that is fairly clever. Thanks, Ben From nobody Mon Jun 17 09:58:28 2019 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 D1687120136; Mon, 17 Jun 2019 09:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ak2LfH9lnilV; Mon, 17 Jun 2019 09:58:17 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FAE41200E3; Mon, 17 Jun 2019 09:58:16 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [75.98.19.133]) by relay.sandelman.ca (Postfix) with ESMTPS id C6E941F450; Mon, 17 Jun 2019 16:58:14 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id CB0EF3810; Mon, 17 Jun 2019 12:58:24 -0400 (EDT) From: Michael Richardson to: spasm@ietf.org, anima@ietf.org In-reply-to: <10505.1560789112@dooku.sandelman.ca> References: <6535.1560786935@dooku.sandelman.ca> <10505.1560789112@dooku.sandelman.ca> Comments: In-reply-to Michael Richardson message dated "Mon, 17 Jun 2019 12:31:52 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 17 Jun 2019 12:58:24 -0400 Message-ID: <12718.1560790704@dooku.sandelman.ca> Archived-At: Subject: Re: [lamps] [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jun 2019 16:58:20 -0000 --=-=-= Content-Type: text/plain Resending a third time, with correct LAMPS ML name of "SPASM" (no trailing S!). My sincere appologies. I have posted the draft https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030est-clarify/ this morning. It attempts to address the errata posted by Sean Turner in 2017 on RFC7030. Specifically the use of Content-Type-Encoding (CTE) and base64. You can see my other query to httpbis at: https://mailarchive.ietf.org/arch/msg/httpbisa/m4l4G_lHKfQVfSeAn7IxReUioD0 In doing BRSKI (draft-ietf-anima-bootstrapping-keyinfra) interop testing we had a number of confusions about whether or things are base64 encoded, and if they are always base64 encoded, why send the CTE header, and if BRSKI is binary or base64 encoded! Given that RFC7030 is somewhat well deployed, acting on the errata that Sean Turner noted is a bit difficult! (As a process thing, it's a problem that his 2017 errata seems to have gone into /dev/null). I am posting the core of the proposal at the bottom of this email. It tries to leverage the Postel doctrine in a way. Some questions/issues: 1) does this belong in secdispatch? 2) is this appropriate for LAMPS? 3) independant submission seems wrong. 4) ANIMA BRSKI needs to clarify things itself, and I will add a section on this, but I'm hesistant to add a normative reference here. I have an idea of appropriate text that I will post on Tuesday. Getting clarity here is really the most important thing for me. 5) I don't have a simple answer for the /csrattrs API. Maybe it needs to be solved by creating a new end point. or it could be done with Accept: header. ps: it's ironic to me, this is perhaps something that could also be solved by versioning the API in the URL. For the other three methods, when the client is aware that this is an amended server then it SHOULD send the POST request in binary form (DER-encoded), and omit the Content-Transfer-Encoding header. How the client knows what kind of server it is dealing with is communicating with is detailed in the next section. An amended server, when it receives a request that has no Content- Transfer-Encoding header, or has a Content-Transfer-Encoding header with the "binary" attribute, MUST respond in the same binary format. When an amended server receives a request in CTE-base64 form, then it MAY respond in kind. It is reasonable for a server to be configured to ignore or fail requests of this form, either via run-time configuration, or via a compile-time option. A main reason to do this is to avoid a permutation that requires testing in the future when no legacy EST clients are expected to connect. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- [[End of PGP Signed Part]] _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0HxrAACgkQlUzhVv38 QpC+zgf/QPmRfr9t1sVZO/CGyDIHoN4ODQkn7cAOpemhep3YD0NJsWxhHI9oQ9o7 0wR4JUoDtAmtg7wR/+zmOSRRu1I4lZNXVCXdDJzqjIgceUAbwcacoyFkX2bQW3NH 8cm1jiuaUm/dblzxMvAkMSquLnXXBlaQ+VlU8yG64sBcM6A01JLVGg4wke6W8whJ deNiEYXT0KxsiQnyPy9M3Mk0QuYbRt6F+9GL+NjqbXlJfHXXWrJ41Xct8mwCwO60 yMxqdC4+mP30d3F7IiWqOjmY+kopsxwFdYFsqWLqqZVNQyLp1sOJ5Kwrxc4hGJXr 7t5B/bMiU4HAJXCs+7ARlkHNp4RCiw== =nSk0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 17 18:23:58 2019 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 B4D2212034F; Mon, 17 Jun 2019 18:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hMVyqCSxGyE; Mon, 17 Jun 2019 18:23:48 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4D6120344; Mon, 17 Jun 2019 18:23:47 -0700 (PDT) Received: from dooku.sandelman.ca (static-68-179-115-177.ptr.terago.net [68.179.115.177]) by relay.sandelman.ca (Postfix) with ESMTPS id 879651F450; Tue, 18 Jun 2019 01:23:45 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 0D69948CE; Mon, 17 Jun 2019 21:23:29 -0400 (EDT) From: Michael Richardson To: Anima WG , spasm@ietf.org In-reply-to: References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> <909.1560436148@localhost> <8921.1560788417@dooku.sandelman.ca> Comments: In-reply-to Brian E Carpenter message dated "Tue, 18 Jun 2019 08:44:43 +1200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 17 Jun 2019 21:23:29 -0400 Message-ID: <10970.1560821009@dooku.sandelman.ca> Archived-At: Subject: Re: [lamps] [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Jun 2019 01:23:50 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > On 18-Jun-19 05:18, Panos Kampanakis (pkampana) wrote: >>> So effectively, the CTE header has effectively been dropped, but the >>> payload is now assumed to be base64, regardless. This suggests that >>> we can not use the CTE header as a signal. > I went and looked at RFC4648 for my own education, and then spent a few > minutes trying to design a Turing machine that can distinguish a binary > bit string from a base64 bit string. Fail. You can determine that a bit > string is definitely not base64 if it contains at least one character > outside the base64 alphabet, but not the converse. So it needs a > signal. Not having a signal would be wide open to malicious misuse, > IMHO. Indicating the length of the payload would be enough, I think. So I conclude that we can't patch RFC7030. We can drop the Content-Transfer-Encoding headers (and it seems that many have done that anyway), but we are stuck with a base64 encoded payload for the four end-points that 7030 describes. We could create new end-points that are not base64 encoded, but that does not seem that important. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0IPRAACgkQlUzhVv38 QpCY/gf+JhgBBvJAo1ve6cD4zTY2mgohlRuF/mYkQ4FW4Hp74IP6K5Bjb9kMrqMe VclwLow8BqjIo5UgY9th+W0FaTJnnrHPxpRE0TpIAOP83zlKfX+X1ZPRMYn0ACSW EgIjAGNi2Yl55ZO9yeRG9LNN6kIfF2/HB2DHDHb+IYDQlM/XKIqtAYr1Sm2MPsTm oXfThJzjqRdDt7xVEQ4skVcz3fmY46C/t2LDaaqxGjjHMDKdYmxV6zdrgTaOq3G1 MdEN2nQ34uYBOy8gtom6IUg3ibfRUHPdw0FRE7F75GfiGOt8/KQb4mT4vfMkEWD8 dOgNYiipBywjmV2eDjdRm6ORpnTz7Q== =P9Uc -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 17 19:14:19 2019 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 033EE120234; Mon, 17 Jun 2019 19:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkQdRe5sNpRo; Mon, 17 Jun 2019 19:14:16 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E13B12003F; Mon, 17 Jun 2019 19:14:15 -0700 (PDT) Received: from dooku.sandelman.ca (ipv6.dooku.sandelman.ca [IPv6:2607:f0b0:f:6::1]) by relay.sandelman.ca (Postfix) with ESMTPS id 3C9E31F450; Tue, 18 Jun 2019 02:14:13 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 3DB4948CE; Mon, 17 Jun 2019 22:14:23 -0400 (EDT) From: Michael Richardson to: spasm@ietf.org, anima@ietf.org In-reply-to: <12718.1560790704@dooku.sandelman.ca> References: <6535.1560786935@dooku.sandelman.ca> <10505.1560789112@dooku.sandelman.ca> <12718.1560790704@dooku.sandelman.ca> Comments: In-reply-to Michael Richardson message dated "Mon, 17 Jun 2019 12:58:24 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 17 Jun 2019 22:14:23 -0400 Message-ID: <15737.1560824063@dooku.sandelman.ca> Archived-At: Subject: Re: [lamps] [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Jun 2019 02:14:18 -0000 --=-=-= Content-Type: text/plain I have posted a -01 version of the document at: https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030est-clarify/ Instead of trying to turn it binary, I just enshrine that the payload is base64 encoded DER: This document updates [RFC7030] to require the POST request and payload response of all endpoints in to be [RFC4648] section 4 Base64 encoded DER. This format is to be used regardless of whether there is any Content-Transfer-Encoding header, and any value in that header is to be ignored. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0ISP4ACgkQlUzhVv38 QpBLcQgAhHpfDEswz3AFrhFEtoYSu03MA6TPBZQjaSD7Sm7pyTFW5P82UH9/ZNkt ieWP6vsi8CmV6J/W5QO9FBTrWBR53DjmKjCFIjFLVIpHMaXbTw6Cwo5tzDrMS2a2 HMacAiLrPDVmVMpWakh6xPqG/9gaPrZaIiPcLZhEz+D1mkkZb75d8Z2jvo0O24eu HrSJzYVewWtP4l+lx9dg42yHmG791TsLDzZbijIRG3JRpdzPtBcV7Cc7A/+HUx5+ fX6sYYK281Y+Guj//BwDU+SV9F1B8bP3VZYjKLnHBowsWE47a8ijbXRO7mZnE0KP Zfei+2lPTg5aLbTElazijJeogXTGEw== =jZTg -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 17 19:34:35 2019 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 77931120336; Mon, 17 Jun 2019 19:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lz6V6h9YfKk4; Mon, 17 Jun 2019 19:34:26 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9124A1200F8; Mon, 17 Jun 2019 19:34:25 -0700 (PDT) Received: from dooku.sandelman.ca (ipv6.dooku.sandelman.ca [IPv6:2607:f0b0:f:6::1]) by relay.sandelman.ca (Postfix) with ESMTPS id 6471B1F450; Tue, 18 Jun 2019 02:34:23 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 5697848CE; Mon, 17 Jun 2019 22:34:33 -0400 (EDT) From: Michael Richardson to: Anima WG , spasm@ietf.org In-reply-to: <10970.1560821009@dooku.sandelman.ca> References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> <909.1560436148@localhost> <8921.1560788417@dooku.sandelman.ca> <10970.1560821009@dooku.sandelman.ca> Comments: In-reply-to Michael Richardson message dated "Mon, 17 Jun 2019 21:23:29 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 17 Jun 2019 22:34:33 -0400 Message-ID: <18219.1560825273@dooku.sandelman.ca> Archived-At: Subject: Re: [lamps] [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Jun 2019 02:34:28 -0000 --=-=-= Content-Type: text/plain > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and > Approach WG of the IETF. > Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) > Filename : draft-ietf-anima-bootstrapping-keyinfra-22.txt > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-22 I have added a section 6: 6. Clarification of transfer-encoding [RFC7030] defines it's endpoints to include a "Content-Transfer- Encoding" heading, and the payloads to be [RFC4648] Base64 encoded DER. When used within BRSKI, the original RFC7030 EST endpoints remain Base64 encoded, but the new BRSKI end points which send and receive binary artifacts (specifically, ../voucherrequest) are binary. That is, no encoding is used. In the BRSKI context, the EST "Content-Transfer-Encoding" header if present, SHOULD be ignored. This header does not need to included. I have not made an informative reference to ietf-lamps-rfc7030est-clarify yet. I will stop now for awhile, to wait for consensus to catch up :-) I think that this change needs a WG Consensus Call, and some discussion with area director. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0ITbUACgkQlUzhVv38 QpARMAf+J+cZApxqfNCs0Vrr8fzCje8rwX5tovHvXDD5sxrDwKe0WpunW6giAfDq pMCC0nDnsBLcVzDJg9z09KDBLYHBFlhFMREg0FJ43Ny9Jv4un66ZcqegahzGrNfV N7eH4yov/ZCDb+xAVC9HulaM+/zlnW590uzCz8q9+aGM147kayc21AJl/hjZ/bMD pLflaMz4PZix5GPWmB1xUmsUXdyc8AXEMkQFifS7ENi+FbH3cUy2tv+LfJDFWAJf 553V7N0wGMrxBmFyTdFH13JK2kxNqJh+2kEM6po2Z8C5FuaLrD71Z+wpJ58Qm7ts bnrA7uqhZGMT2X+PJ+28HfiDw1bL0g== =tZQ/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 17 21:07:50 2019 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 3255312004A; Mon, 17 Jun 2019 21:07:48 -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.98.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <156083086816.22385.9247884517180140929@ietfa.amsl.com> Date: Mon, 17 Jun 2019 21:07:48 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-11.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Jun 2019 04:07:48 -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 : Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS) Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-cms-shakes-11.txt Pages : 17 Date : 2019-06-17 Abstract: This document describes the conventions for using the SHAKE family of hash functions with the Cryptographic Message Syntax (CMS) as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms, as message digests and message authentication codes. The conventions for the associated signer public keys in CMS are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-11 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-shakes-11 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 Jun 17 21:17:45 2019 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 E56B2120073 for ; Mon, 17 Jun 2019 21:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 header.b=Nuixfma+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=SfhvFPKO 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 zeNBOaBCp7q1 for ; Mon, 17 Jun 2019 21:17:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6831200B1 for ; Mon, 17 Jun 2019 21:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2460; q=dns/txt; s=iport; t=1560831462; x=1562041062; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=j1cLfhjUVJWLOX9p4P1LJdNv1wlkCjFsQFqVztXGM3E=; b=Nuixfma+oWrDowSOjwCRGbuTtvb8kVTNLaM7QZMwiTbgX/LkdRug+TNu uwMMSicC9eejZGS55hLOeGHMGFs7vubcKSR+0C4d7YZIt6ThHUTs0tqEQ gOO+LlnFWX675E96V+pqDBcddHBN5TkLdouiTMMnsemXmnKXVFfUT4mKM 8=; IronPort-PHdr: =?us-ascii?q?9a23=3A4+sKwhXVxoiZDdvaUsYkskKcEI/V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankiH81HTFZj9lmwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAAB+ZAhd/5ldJa1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgT1QA2pVIAQLKIddA4RSihJKgg2XNoEugSQDVAkBAQEMAQE?= =?us-ascii?q?YDQgCAQGEQAKCTCM0CQ4BAwEBBAEBAgEEbRwBC4VKAQEBBAEBECgGAQEsDAs?= =?us-ascii?q?EAgEIEQQBAR4BECcLHQgCBBMIGoMBgWoDHQECDJ1qAoE4iF+CIoJ5AQEFgTY?= =?us-ascii?q?CDkGCdxiCEAmBNAGLXReBQD+BEUaCTD6CYQEBAgEBFoEgKYM6giapXwkCghC?= =?us-ascii?q?GSI0lgidphhqOBo0dgSyFdot5g0gCBAIEBQIOAQEFgVA4gVhwFRohgmwJCoF?= =?us-ascii?q?8CxiDTYUUhT9yAYEojGKCUgEB?= X-IronPort-AV: E=Sophos;i="5.63,387,1557187200"; d="scan'208";a="574389413" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Jun 2019 04:17:40 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5I4Hesm013288 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 18 Jun 2019 04:17:40 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Jun 2019 23:17:40 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Jun 2019 23:17:39 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 17 Jun 2019 23:17:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vO6l2uaIDk2onJtWGiN6OwWRQoPVvH0HjjjWAAqIUQo=; b=SfhvFPKO5o86JaNp34b89eaNfq06gAiMpHl1n/cnERDCINTTIpd7fS+Yb8esKDzvem7jfzMMP4vnojaI0MicFaJC1/SS+oJtNlGIX53WAuTp8+RJdL5JhGmQKRN3G6GPEo0yzTMm4ij8FGSrhDOcqEfEVszIgIvO1ukv+VrcOBQ= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.244.29) by BN7PR11MB2723.namprd11.prod.outlook.com (52.135.245.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Tue, 18 Jun 2019 04:17:38 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::89af:3fb4:eae5:18b2]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::89af:3fb4:eae5:18b2%7]) with mapi id 15.20.1987.014; Tue, 18 Jun 2019 04:17:38 +0000 From: "Panos Kampanakis (pkampana)" To: "spasm@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-11.txt Thread-Index: AQHVJYtxhzLEWcuQN0GgvtVjkrGRs6agy/Hg Date: Tue, 18 Jun 2019 04:17:38 +0000 Message-ID: References: <156083086816.22385.9247884517180140929@ietfa.amsl.com> In-Reply-To: <156083086816.22385.9247884517180140929@ietfa.amsl.com> 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=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1005::8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 33fa76af-4f09-404f-0267-08d6f3a3e5f7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2723; x-ms-traffictypediagnostic: BN7PR11MB2723: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 007271867D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(136003)(39860400002)(376002)(396003)(53754006)(199004)(189003)(13464003)(76116006)(446003)(8936002)(5640700003)(81166006)(2906002)(11346002)(68736007)(316002)(46003)(1730700003)(478600001)(8676002)(81156014)(86362001)(7736002)(476003)(6116002)(73956011)(6246003)(66446008)(305945005)(64756008)(66556008)(66476007)(66946007)(256004)(14444005)(14454004)(53936002)(25786009)(2501003)(76176011)(6916009)(486006)(2351001)(52536014)(5660300002)(74316002)(33656002)(186003)(66574012)(9686003)(6306002)(71200400001)(6436002)(102836004)(99286004)(7696005)(53546011)(71190400001)(55016002)(6506007)(966005)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2723; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: KkcINlFJ6x43DihJRSRN6c/HrOFCHZPzZ8X+5vv3p0AOj3EFYgfWG3nymZnegPtkEDsSHMlSV4ej+Ssw0DpLLNc+5zoM7iePWVC2Pe0ewkHZ7UBnhvTjU9Hzh2HmQ9XDJOVQ3C4FFNBfq7cyZY3mcHqSINgZHLhb/QP/9fGYUaR/EOervMY1xiEGhCgd0HotdWwErRlCWKZuCv6uNReNi8BOSgyqY0W6JiUPUQLfFfSDwCXq6BPsj9Xqy52lfygPXAWG0+3rPUuIaE4sQBhv5okjMqlH79IZyDOOPLgf7q/LaTAEArQcQI3o1Znfp6mDQCbPlIzA5qUSvX76snP21i+VBxIT0pSjFMAGPFBYJxPftXlWG/B2VeyYpLRxWmJyCeOTxpdeREwqdxwNoDl/Ab1aZRzV+xTmA0qOo4zwemg= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 33fa76af-4f09-404f-0267-08d6f3a3e5f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2019 04:17:38.0954 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkampana@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2723 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-11.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Jun 2019 04:17:44 -0000 Hi all,=20 This update addresses Roman's AD review from last week.=20 The summary of the review and the fixes is here https://github.com/csosto-p= k/adding-shake-to-pkix/issues/45#issuecomment-501801167 .=20 The diff from the previous version is here https://tools.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-lamps-cms-shakes-11.txt=20 The goal is to standardize the PKIX SHAKEs draft first so we don't need to = keep the OIDs in the IANA considerations of this draft as well.=20 Thanks, Panos -----Original Message----- From: Spasm On Behalf Of internet-drafts@ietf.org Sent: Tuesday, June 18, 2019 12:08 AM To: i-d-announce@ietf.org Cc: spasm@ietf.org Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-11.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 : Use of the SHAKE One-way Hash Functions in the Cr= yptographic Message Syntax (CMS) Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-cms-shakes-11.txt Pages : 17 Date : 2019-06-17 Abstract: This document describes the conventions for using the SHAKE family of hash functions with the Cryptographic Message Syntax (CMS) as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms, as message digests and message authentication codes. The conventions for the associated signer public keys in CMS are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-11 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-shakes-11 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 From nobody Tue Jun 18 15:12:45 2019 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 38560120301; Tue, 18 Jun 2019 15:12:35 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRR4rRY8N0zY; Tue, 18 Jun 2019 15:12:33 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5272A1202ED; Tue, 18 Jun 2019 15:12:32 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [209.82.62.2]) by relay.sandelman.ca (Postfix) with ESMTPS id C01F61F450; Tue, 18 Jun 2019 22:12:30 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id CA4681328; Tue, 18 Jun 2019 18:12:33 -0400 (EDT) From: Michael Richardson To: anima@ietf.org, spasm@ietf.org In-reply-to: <156086304414.8416.1010829894869123324.idtracker@ietfa.amsl.com> References: <156086304414.8416.1010829894869123324.idtracker@ietfa.amsl.com> Comments: In-reply-to internet-drafts@ietf.org message dated "Tue, 18 Jun 2019 06:04:04 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Tue, 18 Jun 2019 18:12:33 -0400 Message-ID: <5700.1560895953@dooku.sandelman.ca> Archived-At: Subject: Re: [lamps] New Version Notification for draft-richardson-lamps-rfc7030est-clarify-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Jun 2019 22:12:35 -0000 -------- --=-=-= Content-Type: text/plain internet-drafts@ietf.org wrote: > A new version of I-D, draft-richardson-lamps-rfc7030est-clarify-02.txt > has been successfully submitted by Michael Richardson and posted to the > IETF repository. > Diff: > https://www.ietf.org/rfcdiff?url2=draft-richardson-lamps-rfc7030est-clarify-02 This version does not attempt to bring binary objects at all to EST. It just notes that the CTE header does not belong, should not be sent, should be ignored, and that the payload is base64, and shall always be. The GRASP registration is dropped, since there is no need for clients to know about different generations of EST servers. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0JYdEACgkQlUzhVv38 QpBtdAf9HEmUTobeosdALwi8aAH4AB3Wj3d/8GeIVvw5Schk9PcoAo51ODd+YEdZ YRw9Svov/HWm3lZWi0GZ7oudnbFHmCXl9k1qJXP7+A3i3N6igQtZ2ZhetvofVNd0 /fQxmFebwwe4BU9yuRAvILewMxV1ll9EtxIACdxCJHvz538wLtgpn/bwviC1Fuq9 9oIab1Mfo6N7kJTDMMAl/BQw942FcglQm4D+yi5ykrrY0lgIX9ig6BxHiCKoLI/E xLXD0Ia4wudXnM7EkihPDvFZqBTAUeGDcTOJNFBu4tCelhiuHevlUL2TQj6fXGh+ xDPNWhUzZ/muobkgLLSLNffOMJiLNA== =DmkS -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 18 18:15:19 2019 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 E5BEB12034A; Tue, 18 Jun 2019 18:15:10 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evIzwroXg_KC; Tue, 18 Jun 2019 18:15:08 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771E31201F3; Tue, 18 Jun 2019 18:15:08 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Jun 2019 18:15:02 -0700 From: Jim Schaad To: 'Michael Richardson' , , References: <6535.1560786935@dooku.sandelman.ca> <10505.1560789112@dooku.sandelman.ca> <12718.1560790704@dooku.sandelman.ca> In-Reply-To: <12718.1560790704@dooku.sandelman.ca> Date: Tue, 18 Jun 2019 18:15:00 -0700 Message-ID: <040a01d5263c$6c51efa0$44f5cee0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJb28LO5lo2KeiH1QNaqQhKxPp0VgIQkln/AZkBSSGld1fWQA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Jun 2019 01:15:11 -0000 -----Original Message----- From: Spasm On Behalf Of Michael Richardson Sent: Monday, June 17, 2019 9:58 AM To: spasm@ietf.org; anima@ietf.org Subject: Re: [lamps] [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI Resending a third time, with correct LAMPS ML name of "SPASM" (no trailing S!). My sincere appologies. I have posted the draft https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030est-clarify/ this morning. It attempts to address the errata posted by Sean Turner in 2017 on RFC7030. Specifically the use of Content-Type-Encoding (CTE) and base64. You can see my other query to httpbis at: https://mailarchive.ietf.org/arch/msg/httpbisa/m4l4G_lHKfQVfSeAn7IxReUioD0 In doing BRSKI (draft-ietf-anima-bootstrapping-keyinfra) interop testing we had a number of confusions about whether or things are base64 encoded, and if they are always base64 encoded, why send the CTE header, and if BRSKI is binary or base64 encoded! Given that RFC7030 is somewhat well deployed, acting on the errata that Sean Turner noted is a bit difficult! (As a process thing, it's a problem that his 2017 errata seems to have gone into /dev/null). I am posting the core of the proposal at the bottom of this email. It tries to leverage the Postel doctrine in a way. Some questions/issues: 1) does this belong in secdispatch? [JLS] I would say yes if only because that is the "new process" that is being used. 2) is this appropriate for LAMPS? [JLS] If I was running secdispatch this is where I would send it. 3) independant submission seems wrong. [JLS] An Individual submission would be ok (direct to AD). However an Independent submission is a complete non-starter. Cannot update a standards track document via the ISE. Jim 4) ANIMA BRSKI needs to clarify things itself, and I will add a section on this, but I'm hesistant to add a normative reference here. I have an idea of appropriate text that I will post on Tuesday. Getting clarity here is really the most important thing for me. 5) I don't have a simple answer for the /csrattrs API. Maybe it needs to be solved by creating a new end point. or it could be done with Accept: header. ps: it's ironic to me, this is perhaps something that could also be solved by versioning the API in the URL. For the other three methods, when the client is aware that this is an amended server then it SHOULD send the POST request in binary form (DER-encoded), and omit the Content-Transfer-Encoding header. How the client knows what kind of server it is dealing with is communicating with is detailed in the next section. An amended server, when it receives a request that has no Content- Transfer-Encoding header, or has a Content-Transfer-Encoding header with the "binary" attribute, MUST respond in the same binary format. When an amended server receives a request in CTE-base64 form, then it MAY respond in kind. It is reasonable for a server to be configured to ignore or fail requests of this form, either via run-time configuration, or via a compile-time option. A main reason to do this is to avoid a permutation that requires testing in the future when no legacy EST clients are expected to connect. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- [[End of PGP Signed Part]] _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Wed Jun 19 04:53:44 2019 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 99FD712004A for ; Wed, 19 Jun 2019 04:53:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHla8KkWbkGs for ; Wed, 19 Jun 2019 04:53:39 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD91120071 for ; Wed, 19 Jun 2019 04:53:39 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x5JBrb2K008304; Wed, 19 Jun 2019 07:53:37 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x5JBrb2K008304 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1560945217; bh=3tC1BLFddlZfz3j0FHstLMiacIyDc6wqzsQFD7foZfw=; h=From:To:Subject:Date:References:In-Reply-To:From; b=KFgm4sUsRkDJEvfqliIod4YuZsXp6QYFcG2ZvlXmD96HWVVKRi2FQbeeghtOTNM4m CmEDtunRi3s+GBpavB3kEmz8r/t4p8k8NZYUxp0e7CETtad19w13NZ32MjkZ9W2AfM 9ypqtKCEMvkjSAi/N7KWEjsAvUcWfv57L7xcwr64= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x5JBrbXE018202; Wed, 19 Jun 2019 07:53:37 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Wed, 19 Jun 2019 07:53:36 -0400 From: Roman Danyliw To: "Panos Kampanakis (pkampana)" , "spasm@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-11.txt Thread-Index: AQHVJYtoZoN94U1ypU+kaixiTTB7sKahEX0AgAHHx+A= Date: Wed, 19 Jun 2019 11:53:35 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B339B9D0@marathon> References: <156083086816.22385.9247884517180140929@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-11.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Jun 2019 11:53:43 -0000 Hi Panos! Thanks for this quick revision. One final questions based on this recent u= pdate. -10 said:=20 This section defines six new object identifiers (OIDs) for using SHAKE128 and SHAKE256 in CMS. -11 said:=20 This section defines four new object identifiers (OIDs) for using SHAKE128 and SHAKE256 in CMS. Final nit. I'm not tracking the change from four to six. As I read the IA= NA section, only one new OID is being defined by this draft for the new CMS= module (i.e., "TBD" per Appendix B). TBD1 - TBD4 as referenced in Section= 1 are actually being defined by draft-ietf-lamps-pkix-shake. The other fo= ur OIDs come from [shake-nist-oids]. Therefore, I don't see how "this sect= ion defines" anything. Doesn't this section "identify _eight_ OIDs for usi= ng ... in CMS"? Also, I say eight because I'm not sure why OIDs in [shake-n= ist-oids] are different than the yet to be defined OIDs from draft-ietf-lam= ps-pkix-shake. Roman=20 > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Panos > Kampanakis (pkampana) > Sent: Tuesday, June 18, 2019 12:18 AM > To: spasm@ietf.org > Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-11.txt >=20 > Hi all, >=20 > This update addresses Roman's AD review from last week. >=20 > The summary of the review and the fixes is here https://github.com/csosto= - > pk/adding-shake-to-pkix/issues/45#issuecomment-501801167 . >=20 > The diff from the previous version is here > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-shakes-11.txt >=20 > The goal is to standardize the PKIX SHAKEs draft first so we don't need t= o > keep the OIDs in the IANA considerations of this draft as well. >=20 > Thanks, > Panos >=20 >=20 > -----Original Message----- > From: Spasm On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, June 18, 2019 12:08 AM > To: i-d-announce@ietf.org > Cc: spasm@ietf.org > Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-11.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Limited Additional Mechanisms for PKIX a= nd > SMIME WG of the IETF. >=20 > Title : Use of the SHAKE One-way Hash Functions in the > Cryptographic Message Syntax (CMS) > Authors : Panos Kampanakis > Quynh Dang > Filename : draft-ietf-lamps-cms-shakes-11.txt > Pages : 17 > Date : 2019-06-17 >=20 > Abstract: > This document describes the conventions for using the SHAKE family of > hash functions with the Cryptographic Message Syntax (CMS) as one-way > hash functions with the RSA Probabilistic signature and ECDSA > signature algorithms, as message digests and message authentication > codes. The conventions for the associated signer public keys in CMS > are also described. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-11 > https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-11 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-shakes-11 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Jun 19 07:57:15 2019 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 23E49120131; Wed, 19 Jun 2019 07:57:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.98.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: rdd@cert.org, draft-ietf-lamps-cms-shakes@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156095623307.12245.3181587948820065170.idtracker@ietfa.amsl.com> Date: Wed, 19 Jun 2019 07:57:13 -0700 Archived-At: Subject: [lamps] Last Call: (Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS)) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 19 Jun 2019 14:57:13 -0000 The IESG has received a request from the Limited Additional Mechanisms for PKIX and SMIME WG (lamps) to consider the following document: - 'Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-07-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the conventions for using the SHAKE family of hash functions with the Cryptographic Message Syntax (CMS) as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms, as message digests and message authentication codes. The conventions for the associated signer public keys in CMS are also described. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream) From nobody Wed Jun 19 20:46:00 2019 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 EA3B112016B for ; Wed, 19 Jun 2019 20:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 header.b=B49kZ6H8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0K1h3dyt 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 uvz8LZxEApH7 for ; Wed, 19 Jun 2019 20:45:57 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182AB120072 for ; Wed, 19 Jun 2019 20:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4658; q=dns/txt; s=iport; t=1561002356; x=1562211956; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=4v++HGVc8g/iDrlXb0xBf9eO/DUJ5X79ro5WjnuRzDQ=; b=B49kZ6H8mLitUL49cAKxMVFOiYULeFL3qYR8zJtR/r9zxRZnpTVY3b0+ II8swQ8pl+Qi5aYRdvQs4mb9ncIv8ayLl1iLiKBotmxpbjAb/xq2tPJSU Vyyu7F5J8tZdK/cDkVfuiUUqMlzyrtrqwEmRW5HTvVJMZ6RvPiOIQBbRl I=; IronPort-PHdr: =?us-ascii?q?9a23=3AKlMfyRAeFby4AmXIaeLVUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNP3jajQzGs1qX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAAB/AAtd/5pdJa1cChwBAQEEAQE?= =?us-ascii?q?HBAEBgVMHAQELAYFDKScDalUgBAsoh10DhFKKDkqCDZc3gS6BJANUCQEBAQw?= =?us-ascii?q?BARgLCgIBAYRAAoJYIzQJDgEDAQEEAQECAQVtijcMhUoBAQEEAQEQKAYBASw?= =?us-ascii?q?MCwQCAQgOAwQBAR4BCQcnCxQJCAIEARIIGoMBgWoDHQECDKIWAoE4iF+CIoJ?= =?us-ascii?q?5AQEFgTYCDkGCehiCEAmBNAGLXReBQD+BEUaCTD6CYQEBAgEBFoEcBCmDOoI?= =?us-ascii?q?mnAeNaQkCghGGSI0ogidqhh+ECol/jSCBLIUlVYt/g0gCBAIEBQIOAQEFgVA?= =?us-ascii?q?4gVhwFRohgmwJgjgLAReBAgEIgkKFFIU/cgGBKItbglIBAQ?= X-IronPort-AV: E=Sophos;i="5.63,395,1557187200"; d="scan'208";a="576034136" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jun 2019 03:45:55 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x5K3jt4a017826 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Jun 2019 03:45:55 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Jun 2019 22:45:54 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Jun 2019 23:45:54 -0400 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 19 Jun 2019 22:45:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0T48UPgk5u3aapvJjchuW5kBc9uSK0hOCZccduuILok=; b=0K1h3dyt8P28dMMSdtS9jHYZx5JA0uN8unAFJYTedLcZ1vlvM7KsCXfKQwTIBmgSI8QRVq8tIk7IR8k95qiSnvP38GOvdAgV6QCzWg3pe7M75WgHL9c0KQXmMgbyJz5xq5muLYBdLx9GvaXcYuIMWlgsGIYB3xVhhfMFP5QQuXg= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.244.29) by BN7PR11MB2707.namprd11.prod.outlook.com (52.135.245.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Thu, 20 Jun 2019 03:45:52 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::89af:3fb4:eae5:18b2]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::89af:3fb4:eae5:18b2%7]) with mapi id 15.20.1987.014; Thu, 20 Jun 2019 03:45:52 +0000 From: "Panos Kampanakis (pkampana)" To: Roman Danyliw , "spasm@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-11.txt Thread-Index: AQHVJYtxhzLEWcuQN0GgvtVjkrGRs6agy/HggAIUN4CAAQmwkA== Date: Thu, 20 Jun 2019 03:45:52 +0000 Message-ID: References: <156083086816.22385.9247884517180140929@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B339B9D0@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B339B9D0@marathon> 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=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1005::247] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d210fcc7-7932-4e08-81c1-08d6f531cadf x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2707; x-ms-traffictypediagnostic: BN7PR11MB2707: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0074BBE012 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(376002)(136003)(366004)(346002)(53754006)(13464003)(199004)(189003)(8936002)(305945005)(99286004)(7736002)(81156014)(6246003)(446003)(6506007)(25786009)(5660300002)(110136005)(81166006)(52536014)(8676002)(71190400001)(86362001)(53546011)(14444005)(74316002)(76176011)(7696005)(256004)(71200400001)(316002)(46003)(6436002)(55016002)(6306002)(2906002)(478600001)(66574012)(68736007)(9686003)(966005)(53936002)(33656002)(14454004)(66556008)(486006)(66446008)(64756008)(2501003)(186003)(11346002)(66476007)(73956011)(229853002)(102836004)(76116006)(66946007)(6116002)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2707; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: T36C8cEYF1VrkIwWB4owoDyVICBzf8hAX2+F+npJYbtyfiyHnaPXqbm6cRemcCu/KN8R9dQjgDw1S7uSBlVSlfWz8wvdgdDNtLR6djehj7xFUsQBUQ9V54MmbqUDdta/NbVsCP6nJZWDsLlYjM5fzzxS2VGTdN12tAlB9PAG1dVka371mtGPp7ugXdbNCSl8ev0wJsLIe3nX6F7yvym/QOMbN1SAC9GkGMxcl2stkPFDqkX2FzrffesALJtGcIzNViVVCjdvyWzuzNWiruXBe//5iv9WsjVQpxeqVgpFfUi4thQ5MfoKaoRiwBsvqGmnSp7+AqTt+gNPgl6wSGOFPeX+n7eevIWhzf2OJcD40mhFMPlvJQ5spHrv+5IdvrYDfyxaubvvZYkkxre8V3di5NG5uvgPuC0MmnBtdNxXE88= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d210fcc7-7932-4e08-81c1-08d6f531cadf X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2019 03:45:52.4832 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkampana@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2707 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-11.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 20 Jun 2019 03:46:00 -0000 You are right Roman. I thought I went back and addressed all similar nits, = but I missed that. Yes, were not defining the eight OIDS, we are identifyin= g them.=20 " This section identifies eight new object identifiers (OIDs)=20 for using SHAKE128 and SHAKE256 in CMS." I updated it, but I will wait a bit before I upload again.=20 Panos -----Original Message----- From: Roman Danyliw =20 Sent: Wednesday, June 19, 2019 7:54 AM To: Panos Kampanakis (pkampana) ; spasm@ietf.org Subject: RE: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-11.txt Hi Panos! Thanks for this quick revision. One final questions based on this recent u= pdate. -10 said:=20 This section defines six new object identifiers (OIDs) for using SHAKE128 and SHAKE256 in CMS. -11 said:=20 This section defines four new object identifiers (OIDs) for using SHAKE128 and SHAKE256 in CMS. Final nit. I'm not tracking the change from four to six. As I read the IA= NA section, only one new OID is being defined by this draft for the new CMS= module (i.e., "TBD" per Appendix B). TBD1 - TBD4 as referenced in Section= 1 are actually being defined by draft-ietf-lamps-pkix-shake. The other fo= ur OIDs come from [shake-nist-oids]. Therefore, I don't see how "this sect= ion defines" anything. Doesn't this section "identify _eight_ OIDs for usi= ng ... in CMS"? Also, I say eight because I'm not sure why OIDs in [shake-n= ist-oids] are different than the yet to be defined OIDs from draft-ietf-lam= ps-pkix-shake. Roman=20 > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Panos=20 > Kampanakis (pkampana) > Sent: Tuesday, June 18, 2019 12:18 AM > To: spasm@ietf.org > Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-11.txt >=20 > Hi all, >=20 > This update addresses Roman's AD review from last week. >=20 > The summary of the review and the fixes is here=20 > https://github.com/csosto- > pk/adding-shake-to-pkix/issues/45#issuecomment-501801167 . >=20 > The diff from the previous version is here=20 > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-shakes-11.txt >=20 > The goal is to standardize the PKIX SHAKEs draft first so we don't=20 > need to keep the OIDs in the IANA considerations of this draft as well. >=20 > Thanks, > Panos >=20 >=20 > -----Original Message----- > From: Spasm On Behalf Of internet-=20 > drafts@ietf.org > Sent: Tuesday, June 18, 2019 12:08 AM > To: i-d-announce@ietf.org > Cc: spasm@ietf.org > Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-11.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Limited Additional Mechanisms for=20 > PKIX and SMIME WG of the IETF. >=20 > Title : Use of the SHAKE One-way Hash Functions in the > Cryptographic Message Syntax (CMS) > Authors : Panos Kampanakis > Quynh Dang > Filename : draft-ietf-lamps-cms-shakes-11.txt > Pages : 17 > Date : 2019-06-17 >=20 > Abstract: > This document describes the conventions for using the SHAKE family of > hash functions with the Cryptographic Message Syntax (CMS) as one-way > hash functions with the RSA Probabilistic signature and ECDSA > signature algorithms, as message digests and message authentication > codes. The conventions for the associated signer public keys in CMS > are also described. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-11 > https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-11 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-shakes-11 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Jun 21 08:30:59 2019 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 F089912032D; Fri, 21 Jun 2019 08:30:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vijay Gurbani via Datatracker To: Cc: spasm@ietf.org, draft-ietf-lamps-cms-shakes.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Vijay Gurbani Message-ID: <156113105092.16969.17846588336503024855@ietfa.amsl.com> Date: Fri, 21 Jun 2019 08:30:50 -0700 Archived-At: Subject: [lamps] Genart last call review of draft-ietf-lamps-cms-shakes-11 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jun 2019 15:30:51 -0000 Reviewer: Vijay Gurbani 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-cms-shakes-?? Reviewer: Vijay K. Gurbani Review Date: 2019-06-21 IETF LC End Date: 2019-07-03 IESG Telechat date: Not scheduled for a telechat Summary: This draft is ready for publication as a standards track document. Major issues: 0 Minor issues: 0 Nits/editorial comments: 0 From nobody Sat Jun 22 09:52:10 2019 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 8CFAD120048; Sat, 22 Jun 2019 09:52:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Watson Ladd via Datatracker To: Cc: spasm@ietf.org, draft-ietf-lamps-cms-shakes.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Watson Ladd Message-ID: <156122232142.16338.1971827361341363218@ietfa.amsl.com> Date: Sat, 22 Jun 2019 09:52:01 -0700 Archived-At: Subject: [lamps] Secdir last call review of draft-ietf-lamps-cms-shakes-11 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jun 2019 16:52:02 -0000 Reviewer: Watson Ladd Review result: Ready I have looked at this document as part of the secdir LC review and it looks fine. From nobody Mon Jun 24 02:57:00 2019 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 B209112010D; Mon, 24 Jun 2019 02:56:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-lamps-pkix-shake@ietf.org, Russ Housley , lamps-chairs@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <156137021272.17807.9800083931896313607.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2019 02:56:52 -0700 Archived-At: Subject: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-pkix-shake-11: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 24 Jun 2019 09:56:53 -0000 Barry Leiba has entered the following ballot position for draft-ietf-lamps-pkix-shake-11: 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-pkix-shake/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I just have some editorial comments, all minor: General: Whenever you use "respectively", throughout the document, it needs a comma before; it also needs a comma after unless it's at the end of a sentence. There are also some cases where you use "respectively" incorrectly, and I've noted those below. -- Section 2 -- A set of nits: In "several cryptographic algorithms which use", make it "that" instead of "which"... better anyway, but especially with the subsequent "which" (that should have a comma before it). You need a comma after "SHA3-512". "d-bits-long" needs both hyphens. "second-preimage-resistance" is a compound modifier and needs two hyphens (two instances here). The comma after "And" doesn't belong. -- Section 5.1 -- Conforming client implementations that process RSASSA-PSS or ECDSA with SHAKE signatures when processing certificates and CRLs MUST recognize the corresponding OIDs. I find the double "process" a little hard to parse. Do you mean this?: NEW Conforming client implementations that process certificates and CRLs using RSASSA-PSS or ECDSA with SHAKE MUST recognize the corresponding OIDs. END -- Section 5.1.1 -- The hash algorithm to hash a message being signed and the hash algorithm as the mask generation function used in RSASSA-PSS MUST be the same, SHAKE128 or SHAKE256 respectively. There's something wrong here, and I think it's the "respectively." I think you're saying that the two algorithms must be the same as each other, but "respectively" says that the first must be 128 and the second must be 256. I think you want this instead: NEW The hash algorithm to hash a message being signed and the hash algorithm as the mask generation function used in RSASSA-PSS MUST be the same: both SHAKE128 or both SHAKE256. END The "respectively" in the sentence following that is also wrong; please rephrase that one as well (and "output length" should NOT be hyphenated). In the final paragraph, "The RSASSA-PSS saltLength MUST be 32 or 64 bytes respectively," is wrong (you can't really inherit the context from another paragraph); you need to say something like, "The RSASSA-PSS saltLength MUST be 32 or 64 bytes for id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256, respectively." Probably better to say, "The RSASSA-PSS saltLength MUST be 32 bytes for id-RSASSA-PSS-SHAKE128 or 64 bytes for id-RSASSA-PSS-SHAKE256." -- Section 5.1.2 -- It is RECOMMENDED that conforming CA implementations that generate ECDSA with SHAKE signatures in certificates or CRLs generate such signatures with a deterministically generated, non-random k in accordance with all the requirements specified in [RFC6979]. Take or leave this one as you please, but I find the passive voice both more confusing and unnecessary in this sentence (because you do have a clear subject already), and I think this is easier to read: NEW Conforming CA implementations that generate ECDSA with SHAKE signatures in certificates or CRLs SHOULD generate such signatures with a deterministically generated, non-random k in accordance with all the requirements specified in [RFC6979]. END Later in that paragraph, two instances of "these standards" and one of "the standards" seem to refer to [X9.62] and [SEC1], so I think it should say "those standards" (to make it clear that you're not talking about any standards defined in *this* document). From nobody Mon Jun 24 03:18:25 2019 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 537E6120130 for ; Mon, 24 Jun 2019 03:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4g_Qh-FydWF for ; Mon, 24 Jun 2019 03:18:22 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) (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 52F1D120247 for ; Mon, 24 Jun 2019 03:18:22 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id x5OAIGmu018526 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 24 Jun 2019 12:18:16 +0200 Received: from DEFTHW99ERMMSX.ww902.siemens.net (defthw99ermmsx.ww902.siemens.net [139.22.70.142]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id x5OAIEWl003014 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 24 Jun 2019 12:18:14 +0200 Received: from DENBGAT9ERKMSX.ww902.siemens.net (139.22.70.145) by DEFTHW99ERMMSX.ww902.siemens.net (139.22.70.142) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 24 Jun 2019 12:18:13 +0200 Received: from DENBGAT9EJ5MSX.ww902.siemens.net ([169.254.12.220]) by DENBGAT9ERKMSX.ww902.siemens.net ([139.22.70.145]) with mapi id 14.03.0439.000; Mon, 24 Jun 2019 12:18:13 +0200 From: "Fries, Steffen" To: Russ Housley , Tim Hollebeek CC: "spasm@ietf.org" Thread-Topic: Charter discussion Thread-Index: AdUieMNE0ThLDuQQTsGvDFcsSaas7AH/Exwg Date: Mon, 24 Jun 2019 10:18:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified x-originating-ip: [139.22.70.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Charter discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 24 Jun 2019 10:18:24 -0000 Hi Russ, hi Tim, I just wanted to ask you regarding my previous email targeting the status o= f the charter discussion. I was not quite sure what the outcome was on the = discussion of the lightweight CMP profile. There was discussion on the mail= ing list in favor and also not in favor but also support regarding implemen= tation. As the discussion suddenly stopped, I'm unsure about the sate and t= he way forward. Do you have any update or any suggestion on how to come to = a conclusion? Best regards Steffen > -----Original Message----- > From: Spasm On Behalf Of [ext] Fries, Steffen > Sent: Freitag, 14. Juni 2019 08:24 > To: spasm@ietf.org > Subject: [lamps] Charter discussion >=20 > Hi, >=20 > Just a short question regarding the charter discussion. Based on the disc= ussion on the mailing list I was not sure if the discussion is > stuck or if the charter has been finalized already. The status on https:/= /datatracker.ietf.org/doc/charter-ietf-lamps/ states approved, > but note all of the recently discussed points made it into the charter. B= ased on the discussion regarding lightweight-profile for CMP I > had the impression there was sufficient interest. Does it mean it is reje= cted for the current charter? >=20 > Best regards > Steffen >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Jun 24 08:33:48 2019 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 9F8A0120419 for ; Mon, 24 Jun 2019 08:33:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 bwh7-PnApFq2 for ; Mon, 24 Jun 2019 08:33:44 -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 8B7A21201CB for ; Mon, 24 Jun 2019 08:33:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6DEEB300AF7 for ; Mon, 24 Jun 2019 11:14:26 -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 xncCVFIRVhqY for ; Mon, 24 Jun 2019 11:14:24 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 82F6F300260; Mon, 24 Jun 2019 11:14:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: Date: Mon, 24 Jun 2019 11:33:41 -0400 Cc: Tim Hollebeek Content-Transfer-Encoding: quoted-printable Message-Id: <5B469693-37A8-4735-AE62-0A31A4C3F5AF@vigilsec.com> References: To: "Fries, Steffen" , "spasm@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Charter discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 24 Jun 2019 15:33:47 -0000 Steffen: By my review of the responses, six people are in support of work on a = CMP profile, four people are willing to review, three people plan to = implement, and one person is opposed to this being added to the charter = of the WG. I was hoping for greater support, but I think we should discuss proposed = charter text at the face-to-face session in Montreal. Hopefully the = discussion will encourage others to volunteer to work on the document. Russ > On Jun 24, 2019, at 6:18 AM, Fries, Steffen = wrote: >=20 > Hi Russ, hi Tim, >=20 > I just wanted to ask you regarding my previous email targeting the = status of the charter discussion. I was not quite sure what the outcome = was on the discussion of the lightweight CMP profile. There was = discussion on the mailing list in favor and also not in favor but also = support regarding implementation. As the discussion suddenly stopped, = I'm unsure about the sate and the way forward. Do you have any update or = any suggestion on how to come to a conclusion? >=20 > Best regards > Steffen >=20 >> -----Original Message----- >> From: Spasm On Behalf Of [ext] Fries, = Steffen >> Sent: Freitag, 14. Juni 2019 08:24 >> To: spasm@ietf.org >> Subject: [lamps] Charter discussion >>=20 >> Hi, >>=20 >> Just a short question regarding the charter discussion. Based on the = discussion on the mailing list I was not sure if the discussion is >> stuck or if the charter has been finalized already. The status on = https://datatracker.ietf.org/doc/charter-ietf-lamps/ states approved, >> but note all of the recently discussed points made it into the = charter. Based on the discussion regarding lightweight-profile for CMP I >> had the impression there was sufficient interest. Does it mean it is = rejected for the current charter? >>=20 >> Best regards >> Steffen >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Jun 24 10:03:27 2019 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 C365212066A; Mon, 24 Jun 2019 10:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 header.b=lezqL4QN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=n/kVAcaM 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 orwxHDKvfrRa; Mon, 24 Jun 2019 10:03:15 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBEF4120018; Mon, 24 Jun 2019 10:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5268; q=dns/txt; s=iport; t=1561395794; x=1562605394; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5nIeLyh2fJ+GkYzNt8ddvUBdniorwCtEbUOREqTaGxQ=; b=lezqL4QNGeZR6dpmbVS0/IQWY3r21ni0c+8+9R7QcQqjL4AY/q0m1zid r9hnyoPZ7e2giL7KkFLHdEvLWrkHgmVlLCheybN4pRqNMcfh1huaOe5Hg A2w8M+UOuvxLMLE/N14Ng1ORPsFSTdhDI2q6P6Jt+BzZgaz1Rkd6Rf8iC Q=; IronPort-PHdr: =?us-ascii?q?9a23=3ASGGO6BOb4zsvpIlXgBUl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjjL/fvdyU8FexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAAAtARFd/5BdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVQIBAQEBAQsBgUNQA2pVIAQLKAqHUwOOYYJblziBLhS?= =?us-ascii?q?BEANUCQEBAQwBARgNCAIBAYRAAoJtIzYHDgEDAQEEAQECAQVtijcMhUoBAQE?= =?us-ascii?q?EAQEQKAYBASwLAQsEAgEIEQQBAR8QJwsdCAIEAQ0FCBqDAYFqAx0BAgyYNQK?= =?us-ascii?q?BOIhfgiKCeQEBBYEyARNBgnQYghEDBoE0AYtdF4FAP4ERRoJMPoJhAQEBAQE?= =?us-ascii?q?BgSoBEgEhMIMKgiaMAJAcjXEJAoIUhk2NMIIohw2ECooIjSaHL49UAgQCBAU?= =?us-ascii?q?CDgEBBYFXDCVnWBEIcBU7gmwTgi4JAhgUgzmFFIU/cgEJgR+MBYEiAYEgAQE?= X-IronPort-AV: E=Sophos;i="5.63,412,1557187200"; d="scan'208";a="584214943" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2019 17:01:48 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x5OH1m8S008240 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Jun 2019 17:01:48 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 24 Jun 2019 12:01:47 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 24 Jun 2019 13:01:46 -0400 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 24 Jun 2019 13:01:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zSfBxtjNqayIlWHmkNv1Lx6aN7YdbovhZLSdfSffuYo=; b=n/kVAcaMmdY39lVRyy1U5xaxGRg51RQkG6TxxOZMpXSE9NI8LxnELnKP9LzY+/U1QPxukPghXySK9HQPD/b4gMBCHwiOrPKqB26zVAG/THcOvYFwNBuDpQNl9OE/iLqR/3+JAzg25iXZXBC0q+3kOIlSSwZ6QLcxk4F95FQhg+s= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.244.29) by BN7PR11MB2675.namprd11.prod.outlook.com (52.135.245.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Mon, 24 Jun 2019 17:01:44 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b1dc:fd0d:e540:67aa]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b1dc:fd0d:e540:67aa%7]) with mapi id 15.20.2008.014; Mon, 24 Jun 2019 17:01:44 +0000 From: "Panos Kampanakis (pkampana)" To: Barry Leiba , The IESG CC: "spasm@ietf.org" , Russ Housley , "lamps-chairs@ietf.org" Thread-Topic: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-pkix-shake-11: (with COMMENT) Thread-Index: AQHVKnM3b3wMTtHEzkGiRfSMqj79/qarBsvQ Date: Mon, 24 Jun 2019 17:01:44 +0000 Message-ID: References: <156137021272.17807.9800083931896313607.idtracker@ietfa.amsl.com> In-Reply-To: <156137021272.17807.9800083931896313607.idtracker@ietfa.amsl.com> 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=pkampana@cisco.com; x-originating-ip: [173.38.117.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 27296cb0-4111-43f4-d807-08d6f8c5a312 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2675; x-ms-traffictypediagnostic: BN7PR11MB2675: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 007814487B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(136003)(346002)(366004)(376002)(13464003)(52314003)(189003)(199004)(66556008)(4326008)(76116006)(99286004)(73956011)(66476007)(53936002)(64756008)(66446008)(6116002)(3846002)(66066001)(476003)(5660300002)(446003)(2906002)(316002)(186003)(66946007)(11346002)(110136005)(54906003)(305945005)(966005)(6246003)(6436002)(6306002)(9686003)(8676002)(25786009)(478600001)(55016002)(7736002)(71190400001)(81166006)(256004)(71200400001)(74316002)(8936002)(7696005)(26005)(6506007)(76176011)(53546011)(486006)(52536014)(33656002)(68736007)(81156014)(14454004)(86362001)(229853002)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2675; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: e5RwggSEZuR505Soq1xdAoadScu0TiCGI2OCg+GLvQ/i5IglNI5MPsn4irC9pxiqjwOkEPKULB449nc1OsQQJK3CNOvR7skY9klhrim0Ycj8lPzYbNnXzwJgpxRH+zm77URMfjCAl8sE9VMrzeBcElWu8pyA13ds4+RQuvh6/6g3KCdRu87qk/jZfVlCu8lDUqifkJdsqERPHwBs0cW9h10VUpFosukVeiaxtCd2LxGiSb+ClcovhQ263mGlfQd4c+LoPZs9TI+Mk8i8a35JL5oqjSqvg2LYqFgBpLgtzHgqd9Goetxp73kl7mVp+77qESo9QFIJT6O4JQ42Bg5r0vL+FYCFDKp+ZmaFy7ptFbNqeNi2mvjFtKm+Z7Y8fpfLdgmhsJVVh8dySEZrEhH4iHOBWUhl4Pd9zs7oreQQxvs= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 27296cb0-4111-43f4-d807-08d6f8c5a312 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2019 17:01:44.7191 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkampana@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2675 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-pkix-shake-11: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 24 Jun 2019 17:03:18 -0000 Thank you Barry. I logged the issue here https://github.com/csosto-pk/adding-shake-to-pkix/i= ssues/46 and the fixes to your feedback are documented here https://github.= com/csosto-pk/adding-shake-to-pkix/issues/46#issuecomment-505091119 The dif= fs are in https://github.com/csosto-pk/adding-shake-to-pkix/commit/ca1c0738= 67c403e0ed0ed0f84e394ea9757bc37d=20 I will reupload the docs at the end of the week.=20 Rgs, Panos -----Original Message----- From: Spasm On Behalf Of Barry Leiba via Datatrack= er Sent: Monday, June 24, 2019 5:57 AM To: The IESG Cc: spasm@ietf.org; Russ Housley ; draft-ietf-lamps-p= kix-shake@ietf.org; lamps-chairs@ietf.org Subject: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-pkix-shake-= 11: (with COMMENT) Barry Leiba has entered the following ballot position for draft-ietf-lamps-pkix-shake-11: 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 introduc= tory 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-pkix-shake/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I just have some editorial comments, all minor: General: Whenever you use "respectively", throughout the document, it needs a comma = before; it also needs a comma after unless it's at the end of a sentence.=20 There are also some cases where you use "respectively" incorrectly, and I'v= e noted those below. -- Section 2 -- A set of nits: In "several cryptographic algorithms which use", make it "that" instead of = "which"... better anyway, but especially with the subsequent "which" (that = should have a comma before it). You need a comma after "SHA3-512". "d-bits-long" needs both hyphens. "second-preimage-resistance" is a compound modifier and needs two hyphens (= two instances here). The comma after "And" doesn't belong. -- Section 5.1 -- Conforming client implementations that process RSASSA-PSS or ECDSA with SHAKE signatures when processing certificates and CRLs MUST recognize the corresponding OIDs. I find the double "process" a little hard to parse. Do you mean this?: NEW Conforming client implementations that process certificates and CRLs using RSASSA-P= SS or ECDSA with SHAKE MUST recognize the corresponding OIDs. END -- Section 5.1.1 -- The hash algorithm to hash a message being signed and the hash algorithm as the mask generation function used in RSASSA-PSS MUST be the same, SHAKE128 or SHAKE256 respectively. There's something wrong here, and I think it's the "respectively." I think= you're saying that the two algorithms must be the same as each other, but = "respectively" says that the first must be 128 and the second must be 256. = I think you want this instead: NEW The hash algorithm to hash a message being signed and the hash algorithm as the mask generation function used in RSASSA-PSS MUST be the same: both SHAKE128 or both SHAKE256. END The "respectively" in the sentence following that is also wrong; please rep= hrase that one as well (and "output length" should NOT be hyphenated). In the final paragraph, "The RSASSA-PSS saltLength MUST be 32 or 64 bytes r= espectively," is wrong (you can't really inherit the context from another p= aragraph); you need to say something like, "The RSASSA-PSS saltLength MUST = be 32 or 64 bytes for id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256, respec= tively." Probably better to say, "The RSASSA-PSS saltLength MUST be 32 byt= es for id-RSASSA-PSS-SHAKE128 or 64 bytes for id-RSASSA-PSS-SHAKE256." -- Section 5.1.2 -- It is RECOMMENDED that conforming CA implementations that generate ECDSA with SHAKE signatures in certificates or CRLs generate such signatures with a deterministically generated, non-random k in accordance with all the requirements specified in [RFC6979]. Take or leave this one as you please, but I find the passive voice both mor= e confusing and unnecessary in this sentence (because you do have a clear s= ubject already), and I think this is easier to read: NEW Conforming CA implementations that generate ECDSA with SHAKE signatures in certificates or CRLs SHOULD generate such signatures with a deterministically generated, non-random k in accordance with all the requirements specified in [RFC6979]. END Later in that paragraph, two instances of "these standards" and one of "the= standards" seem to refer to [X9.62] and [SEC1], so I think it should say "= those standards" (to make it clear that you're not talking about any standa= rds defined in *this* document). _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Jun 24 11:41:12 2019 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 AAD63120059; Mon, 24 Jun 2019 11:41:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-lamps-pkix-shake@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156140166968.17780.4781257860683054457.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2019 11:41:09 -0700 Archived-At: Subject: [lamps] Benjamin Kaduk's Yes on draft-ietf-lamps-pkix-shake-11: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 24 Jun 2019 18:41:10 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-pkix-shake-11: Yes 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-pkix-shake/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document; I only have editorial-nit-level comments. Section 2 This document describes cryptographic algorithm identifiers for several cryptographic algorithms which use variable length output SHAKE functions introduced in [SHA3] which can be used with the Internet X.509 Certificate and CRL profile [RFC5280]. nit(?): Is "describes" or "defines" more appropriate? (Given that NIST has already allocated some of the OIDs in question, I could go either way.) I'd also suggest further rewording, perhaps as: This document defines cryptographic algorithm identifiers for several cryptographic algorithms that use the variable length output SHAKE functions introduced in [SHA3]; these algorithms can be used with the Internet X.509 Certificate and CRL profile [RFC5280]. -- This specification describes the identifiers for SHAKEs to be used in X.509 and their meaning. nit: this seems pretty redundant with the first paragraph of the section. Section 5.1 Signatures are used in a number of different ASN.1 structures. As shown in the ASN.1 representation from [RFC5280] below, an X.509 certificate a signature is encoded with an algorithm identifier in the signatureAlgorithm attribute and a signatureValue attribute that contains the actual signature. nit: "an X.509 certificate a signature is encoded" is not grammatical; I think there's a missing "in" at the start? The identifiers defined in Section 4 can be used as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence Certificate and the signature field in the sequence tbsCertificate in X.509 [RFC5280]. [...] nit: I'm a bit confused by the usage "sequence tbsCertificate" -- the name of the ASN.1 SEQUENCE is TBSCertificate, with tbsCertificate reflecting the field name for this sequence as it appears in the Certificate. (Contrariwise, "the sequence Certificate" makes sense to me, as that is the type name of an ASN.1 SEQUENCE.) I do note that the sentence "This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertificate (Section 4.1.2.3" appears in RFC 5280, which includes the same phrasing. Section 5.1.1 The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 4 is used, the encoding MUST omit the parameters field. [...] Is this requirement redundant with the one in Section 4? (Similarly in Section 5.1.2.) The hash algorithm to hash a message being signed and the hash algorithm as the mask generation function used in RSASSA-PSS MUST be the same, SHAKE128 or SHAKE256 respectively. [...] nit: I think just "as" is not the right grammar, here, and we want "used as" instead. SHAKE128 and id-RSASSA-PSS-SHAKE256 respectively. The mgfSeed is the seed from which mask is generated, an octet string [RFC8017]. As explained in Step 9 of section 9.1.1 of [RFC8017], the output length of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256 respectively. Thus when SHAKE is used as the MGF, the SHAKE output length maskLen is (n - 264) or (n - 520) bits respectively. For example, when RSA modulus n is 2048, the output length of SHAKE128 or SHAKE256 as the MGF will be 1784 or 1528-bits when id-RSASSA-PSS- SHAKE128 or id-RSASSA-PSS-SHAKE256 is used respectively. nit: Absent some external requirement for the RSA modulus to be a multiple of 8 bits (that I have forgotten about), it seems we need to be more careful about transtioning from the byte length of the MGF output to the bit length of SHAKE output needed, as the ceil() function will vary with the modulus of n base 8. Section 5.2 is an OID and optionally associated parameters. The conventions and encoding for RSASSA-PSS and ECDSA public keys algorithm identifiers are as specified in Section 2.3 of [RFC3279], Section 3.1 of [RFC4055] and Section 2.1 of [RFC5480]. I think this might be better if it calls out sections 2.3.1 and 2.3.5 of RFC 3279 explicitly rather than globbing in a bunch of unrelated subsections. The identifier parameters, as explained in Section 4, MUST be absent. This feels like the fourth time we've said that parameters are absent... Appendix A nit: Does "Deterministic" need to be in the comments for the ECDSA smime capabilities? It's not really something the peer can verify. From nobody Mon Jun 24 15:51:34 2019 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 68D891201EC; Mon, 24 Jun 2019 15:51:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern via Datatracker To: Cc: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-pkix-shake.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Joel Halpern Message-ID: <156141668638.17567.6233014246559174910@ietfa.amsl.com> Date: Mon, 24 Jun 2019 15:51:26 -0700 Archived-At: Subject: [lamps] Genart telechat review of draft-ietf-lamps-pkix-shake-11 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 24 Jun 2019 22:51:26 -0000 Reviewer: Joel Halpern 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-lamps-pkix-shake-11 Reviewer: Joel Halpern Review Date: 2019-06-24 IETF LC End Date: None IESG Telechat date: 2019-06-27 Summary: This document is ready for publication as a Proposed Standard My thanks to those involved for addressing my comments. Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A From nobody Mon Jun 24 23:07:45 2019 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 62AF3120230 for ; Mon, 24 Jun 2019 23:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtWK2H5vtimC for ; Mon, 24 Jun 2019 23:07:37 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (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 665C3120223 for ; Mon, 24 Jun 2019 23:07:37 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id x5P67ULv004973 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Jun 2019 08:07:31 +0200 Received: from DEFTHW99ERIMSX.ww902.siemens.net (defthw99erimsx.ww902.siemens.net [139.22.70.134]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id x5P67Uuu029457 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Jun 2019 08:07:30 +0200 Received: from DEFTHW99ERTMSX.ww902.siemens.net (139.22.70.200) by DEFTHW99ERIMSX.ww902.siemens.net (139.22.70.134) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 25 Jun 2019 08:07:30 +0200 Received: from DENBGAT9EJ5MSX.ww902.siemens.net ([169.254.12.220]) by DEFTHW99ERTMSX.ww902.siemens.net ([139.22.70.200]) with mapi id 14.03.0439.000; Tue, 25 Jun 2019 08:07:28 +0200 From: "Fries, Steffen" To: Russ Housley , "spasm@ietf.org" CC: Tim Hollebeek Thread-Topic: [lamps] Charter discussion Thread-Index: AdUieMNE0ThLDuQQTsGvDFcsSaas7AH/ExwgAAcYAIAAIo1ssA== Date: Tue, 25 Jun 2019 06:07:28 +0000 Message-ID: References: <5B469693-37A8-4735-AE62-0A31A4C3F5AF@vigilsec.com> In-Reply-To: <5B469693-37A8-4735-AE62-0A31A4C3F5AF@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified x-originating-ip: [139.22.70.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Charter discussion X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jun 2019 06:07:40 -0000 Hi Russ, Thank you for the update. I totally agree, a direct discussion about it is = probably the best. The applicability of the proposed approach specifically = in industrial use cases should foster more interest. Best regards Steffen > -----Original Message----- > From: Spasm On Behalf Of Russ Housley > Sent: Montag, 24. Juni 2019 17:34 > To: Fries, Steffen (CT RDA CST) ; spasm@ietf.o= rg > Cc: Tim Hollebeek > Subject: Re: [lamps] Charter discussion >=20 > Steffen: >=20 > By my review of the responses, six people are in support of work on a CMP= profile, four people are willing to review, three people > plan to implement, and one person is opposed to this being added to the c= harter of the WG. >=20 > I was hoping for greater support, but I think we should discuss proposed = charter text at the face-to-face session in Montreal. > Hopefully the discussion will encourage others to volunteer to work on th= e document. >=20 > Russ >=20 >=20 > > On Jun 24, 2019, at 6:18 AM, Fries, Steffen = wrote: > > > > Hi Russ, hi Tim, > > > > I just wanted to ask you regarding my previous email targeting the stat= us of the charter discussion. I was not quite sure what the > outcome was on the discussion of the lightweight CMP profile. There was d= iscussion on the mailing list in favor and also not in favor > but also support regarding implementation. As the discussion suddenly sto= pped, I'm unsure about the sate and the way forward. Do > you have any update or any suggestion on how to come to a conclusion? > > > > Best regards > > Steffen > > > >> -----Original Message----- > >> From: Spasm On Behalf Of [ext] Fries, > >> Steffen > >> Sent: Freitag, 14. Juni 2019 08:24 > >> To: spasm@ietf.org > >> Subject: [lamps] Charter discussion > >> > >> Hi, > >> > >> Just a short question regarding the charter discussion. Based on the > >> discussion on the mailing list I was not sure if the discussion is > >> stuck or if the charter has been finalized already. The status on > >> https://datatracker.ietf.org/doc/charter-ietf-lamps/ states approved, = but note all of the recently discussed points made it into the > charter. Based on the discussion regarding lightweight-profile for CMP I = had the impression there was sufficient interest. Does it mean > it is rejected for the current charter? > >> > >> Best regards > >> Steffen > >> > >> _______________________________________________ > >> Spasm mailing list > >> Spasm@ietf.org > >> https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Jun 25 00:43:52 2019 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 44C07120121; Tue, 25 Jun 2019 00:43:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-lamps-pkix-shake@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156144862226.22755.5941558703193888438.idtracker@ietfa.amsl.com> Date: Tue, 25 Jun 2019 00:43:42 -0700 Archived-At: Subject: [lamps] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-lamps-pkix-shake-11=3A_=28with_COMMENT=29?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jun 2019 07:43:43 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-lamps-pkix-shake-11: 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-pkix-shake/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you all for the work put into this document. == COMMENTS == -- Section 1 / Change log -- May I assume that the issues by the two reviews of -08 are solved in -11 ? -- Section 4 -- == NITS == -- Abstract -- Just wondering why CRL acronym is expanded while SHAKE & ECDSA are not. -- section 6 -- Also wondering why in some IANA entries "SHAKE" is in lower case while in others in upper case. From nobody Tue Jun 25 09:27:57 2019 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 C971F1207C0; Tue, 25 Jun 2019 09:27:42 -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, 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=cooperw.in header.b=xGAWwBPF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lPF5Vl/J 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 xeyO4UNIel6Q; Tue, 25 Jun 2019 09:27:40 -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 4F64B120135; Tue, 25 Jun 2019 09:27:37 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9F72F22398; Tue, 25 Jun 2019 12:27:36 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 25 Jun 2019 12:27:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=7 SqyTIVkQiRYK8nHDSf7W+ugSTPQyn3kcVIjTMCJQEc=; b=xGAWwBPFgF/YbPk4N IhESROeKsT+73dOwvPkwO1iZHxtGCbbED60q2BC2Urnlmw3fExmr4Bcp9fL/1i44 PxetvBXTODraTVqfXehpCsK9JdhqxWohbiLIz4tNln/AjyEcT8v4vnwAqnu3DB2U m9LPLC6urevkPZyd18cgZ1AwWzEGpfrQHe1Bp2WIyLKm+NASjFc0wOHXmldsGV6g /DjyLVt/vHbTEn6oHKDfslHq7fGJW7OS2+XmFJfOqfr1KqnVrHjmeZzFp5lwdr12 x5sBJDSKwqIAoEjKwQahkygPD4q6GfloSb21//zMlQ4lJerCDpyIkeQnFMhKdglQ 3kWvw== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=7SqyTIVkQiRYK8nHDSf7W+ugSTPQyn3kcVIjTMCJQ Ec=; b=lPF5Vl/JSd/xj9oiRelqoUwpKrF0iChjtCwL0k6QnUhjAq10sIIoGKiP9 pUB9yjHHDwGAGLIdKhujuOowr5Oe8Ne6GtOkF+iiVsqbyNDdljaGR+4hiBrR9EaX TDCGzQo86h8ApXWo49tZGxNL8jVRwGE7bJ+Y98G7wSZ2ZFceZ13HIozFiOcyaNMG +uSlQ12+TBIvthBSfERv+Vm+C9LUXEYS5reqFHurpYUo9y4I+e8AlSlxg5AgW6eb clO1Klo/D/hlDCIDze101Qab7NZ7EO3egNlgpCQT4ZpYvZ1oLAsZ5ghoLRHg53Hy h9s3hnAloQ8FV4WXivqpKgLE0cM8A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeggdellecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepuddtkedrhedurddutddurdelkeenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id B2E4E380083; Tue, 25 Jun 2019 12:27:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: Date: Tue, 25 Jun 2019 12:27:34 -0400 Cc: Russ Housley , spasm@ietf.org, IETF Gen-ART , IETF , draft-ietf-lamps-pkix-shake.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7916915C-76F6-4884-A0D4-FFAA2ABEEA21@cooperw.in> References: <155393972295.3950.3582710869606616692@ietfa.amsl.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] [Gen-art] Genart last call review of draft-ietf-lamps-pkix-shake-08 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jun 2019 16:27:43 -0000 Joel, thanks for your reviews. I entered a No Objection ballot. I trust = that the identifier assignments will work out with NIST. Alissa > On Mar 31, 2019, at 1:28 AM, Joel M. Halpern = wrote: >=20 > Maybe a note that the assignment will take place once the drafts are = approved, and that the RFC should coordiante with the authors and NIST = on this? (I presume we have done this before, and we do not have the = problem we have in some other cases of "no number until RFC" / "no RFC = until number".) >=20 > Yours, > Joel >=20 > On 3/31/19 1:21 AM, Russ Housley wrote: >>> On Mar 30, 2019, at 5:55 AM, Joel Halpern via Datatracker = wrote: >>>=20 >>> Reviewer: Joel Halpern >>> Review result: Almost 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 treat these comments just >>> like any other last call comments. >>>=20 >>> For more information, please see the FAQ at >>>=20 >>> . >>>=20 >>> Document: draft-ietf-lamps-pkix-shake-08 >>> Reviewer: Joel Halpern >>> Review Date: 2019-03-30 >>> IETF LC End Date: 2019-04-10 >>> IESG Telechat date: Not scheduled for a telechat >>>=20 >>> Summary: This document is almost ready for publication as a Proposed = Standard >>>=20 >>> Major issues: >>> One of the key points of this RFC seems to be to assign the = identifiers for >>> the use of the two SHAKE variants. It is thus confusing that the >>> identifiers end with "TBD", and thus are not defined in this = document. >> They will be assigned by NIST once they are sure that these are the = identifiers that we want. This is much the same as we do when IANA is = ti assign the identifier. >> Russ >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Jun 25 09:28:56 2019 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 C226A120825; Tue, 25 Jun 2019 09:28: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, 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=joelhalpern.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 gLlQQlj-9z1d; Tue, 25 Jun 2019 09:28:39 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 2F42F120821; Tue, 25 Jun 2019 09:28:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 45YBRp6ZYYzYmPN; Tue, 25 Jun 2019 09:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1561480118; bh=kKzyPXYbGQkrBP8UAbQUVyJs6v0YzBM7KfKd6Vnuwvw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=PtA0ZzXluPIa1J0aHrL9wWK36oF5t7vU6vrSQaGSAtcCiewXCisnueG7sKk61z5JN pI1Qp528wtbKh087wEglXYBlbiSBX1fYPJDwJpGIKdGCdUEhpgYeXsMO39YG46AY2p 1ynplSEoDGSHu8ly5MKV9NadDC1XtaPqk1Q/rxew= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 45YBRn5jvWzYlLK; Tue, 25 Jun 2019 09:28:37 -0700 (PDT) To: Alissa Cooper Cc: Russ Housley , spasm@ietf.org, IETF Gen-ART , IETF , draft-ietf-lamps-pkix-shake.all@ietf.org References: <155393972295.3950.3582710869606616692@ietfa.amsl.com> <7916915C-76F6-4884-A0D4-FFAA2ABEEA21@cooperw.in> From: "Joel M. Halpern" Message-ID: <55e454fa-0076-557f-b5b0-0f9dc0e91fdb@joelhalpern.com> Date: Tue, 25 Jun 2019 12:28:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <7916915C-76F6-4884-A0D4-FFAA2ABEEA21@cooperw.in> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] [Gen-art] Genart last call review of draft-ietf-lamps-pkix-shake-08 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jun 2019 16:28:41 -0000 The latest version (which I reviewed yesterday) has the assignments. Joel On 6/25/19 12:27 PM, Alissa Cooper wrote: > Joel, thanks for your reviews. I entered a No Objection ballot. I trust that the identifier assignments will work out with NIST. > > Alissa > >> On Mar 31, 2019, at 1:28 AM, Joel M. Halpern wrote: >> >> Maybe a note that the assignment will take place once the drafts are approved, and that the RFC should coordiante with the authors and NIST on this? (I presume we have done this before, and we do not have the problem we have in some other cases of "no number until RFC" / "no RFC until number".) >> >> Yours, >> Joel >> >> On 3/31/19 1:21 AM, Russ Housley wrote: >>>> On Mar 30, 2019, at 5:55 AM, Joel Halpern via Datatracker wrote: >>>> >>>> Reviewer: Joel Halpern >>>> Review result: Almost 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-pkix-shake-08 >>>> Reviewer: Joel Halpern >>>> Review Date: 2019-03-30 >>>> IETF LC End Date: 2019-04-10 >>>> IESG Telechat date: Not scheduled for a telechat >>>> >>>> Summary: This document is almost ready for publication as a Proposed Standard >>>> >>>> Major issues: >>>> One of the key points of this RFC seems to be to assign the identifiers for >>>> the use of the two SHAKE variants. It is thus confusing that the >>>> identifiers end with "TBD", and thus are not defined in this document. >>> They will be assigned by NIST once they are sure that these are the identifiers that we want. This is much the same as we do when IANA is ti assign the identifier. >>> Russ >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art > From nobody Tue Jun 25 09:34:54 2019 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 18FF6120411; Tue, 25 Jun 2019 09:34:47 -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, 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=cooperw.in header.b=ssqHgC54; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=h9JzUy8t 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 cyy_c4Ybe68a; Tue, 25 Jun 2019 09:34:45 -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 1E81B120322; Tue, 25 Jun 2019 09:34:45 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 460D8224B4; Tue, 25 Jun 2019 12:34:44 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 25 Jun 2019 12:34:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=j v7/sP4a1Be3M47+I8oypNCVzJueFbnryTnDujE25oA=; b=ssqHgC54dJGoQoaVG 0soN+r89fCsX00A1p2eJbcX8XPQhrMF0YVc1MdTKkXe48oukpWsSMIwj1hiBaMsQ zokDR+VVLFLvHRRo/aPmy0hZnWJ4WHrojHyYRofmJeqDhKPUSdMSH387KQk5jDqv CpQSrzg3Ufilc1UBiAK2U8BAVCidNlzmNNkJMRK0m7Q8DJDhY458BgxEZf+C7dw0 TApvWyd1oTc6DHJnmP9FA1i3+bC7p+13Q6eMZVTZpZqaQMOQHCEdR3YNmNSDYfhj 1uIBKUU7QdyFpdg+/gB5Xcz7/e2JQSqJPUDP2L3M+8OMFq4nU1lRa521hbQCzAW/ sS1BA== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=jv7/sP4a1Be3M47+I8oypNCVzJueFbnryTnDujE25 oA=; b=h9JzUy8tmWZI+n/2TD/r74pQbiE0xv2BKZBTaLg3hsGCyCFsXIDixovTC P/Xd/SkHpXPNmxihMQTzRxzz2V4jYhAzejLvHuJTeEzbDrMlyWVcGQMX2swd+JW9 itOSB21foCtrhVnunHPQ+t75aLIjWGEAoiil4DxWrVusYpiqACjptn8dfJeR0Xch Bb1C8RPGUNUTN/UtMwOPNpAHrNJxjl7nXrEJfjTv1Ql+Lo7s2TsCJZQLBKpVC+bI 74xgBneZx/OGw00yCibPyVwnav5MGJtuMa0JXIRsL4qA5yfQWa1B1TfCtleeMN9z tdVOFixKfDStCm+2NQjvpDZS5zb0Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeggddutdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedutdekrdehuddruddtuddrleeknecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 77DE4380084; Tue, 25 Jun 2019 12:34:43 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <55e454fa-0076-557f-b5b0-0f9dc0e91fdb@joelhalpern.com> Date: Tue, 25 Jun 2019 12:34:42 -0400 Cc: Russ Housley , spasm@ietf.org, IETF Gen-ART , IETF , draft-ietf-lamps-pkix-shake.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155393972295.3950.3582710869606616692@ietfa.amsl.com> <7916915C-76F6-4884-A0D4-FFAA2ABEEA21@cooperw.in> <55e454fa-0076-557f-b5b0-0f9dc0e91fdb@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] [Gen-art] Genart last call review of draft-ietf-lamps-pkix-shake-08 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jun 2019 16:34:47 -0000 Apologies, I thought the concern remained about the TBD identifiers in = the document. Alissa > On Jun 25, 2019, at 12:28 PM, Joel M. Halpern = wrote: >=20 > The latest version (which I reviewed yesterday) has the assignments. > Joel >=20 > On 6/25/19 12:27 PM, Alissa Cooper wrote: >> Joel, thanks for your reviews. I entered a No Objection ballot. I = trust that the identifier assignments will work out with NIST. >> Alissa >>> On Mar 31, 2019, at 1:28 AM, Joel M. Halpern = wrote: >>>=20 >>> Maybe a note that the assignment will take place once the drafts are = approved, and that the RFC should coordiante with the authors and NIST = on this? (I presume we have done this before, and we do not have the = problem we have in some other cases of "no number until RFC" / "no RFC = until number".) >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 3/31/19 1:21 AM, Russ Housley wrote: >>>>> On Mar 30, 2019, at 5:55 AM, Joel Halpern via Datatracker = wrote: >>>>>=20 >>>>> Reviewer: Joel Halpern >>>>> Review result: Almost 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 treat these comments just >>>>> like any other last call comments. >>>>>=20 >>>>> For more information, please see the FAQ at >>>>>=20 >>>>> . >>>>>=20 >>>>> Document: draft-ietf-lamps-pkix-shake-08 >>>>> Reviewer: Joel Halpern >>>>> Review Date: 2019-03-30 >>>>> IETF LC End Date: 2019-04-10 >>>>> IESG Telechat date: Not scheduled for a telechat >>>>>=20 >>>>> Summary: This document is almost ready for publication as a = Proposed Standard >>>>>=20 >>>>> Major issues: >>>>> One of the key points of this RFC seems to be to assign the = identifiers for >>>>> the use of the two SHAKE variants. It is thus confusing that = the >>>>> identifiers end with "TBD", and thus are not defined in this = document. >>>> They will be assigned by NIST once they are sure that these are the = identifiers that we want. This is much the same as we do when IANA is = ti assign the identifier. >>>> Russ >>>=20 >>> _______________________________________________ >>> Gen-art mailing list >>> Gen-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Jun 25 09:48:07 2019 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 8AEA01207EC for ; Tue, 25 Jun 2019 09:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 xHHQccV6csEq for ; Tue, 25 Jun 2019 09:47:54 -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 07915120075 for ; Tue, 25 Jun 2019 09:47:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E3F43300A50 for ; Tue, 25 Jun 2019 12:28:35 -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 q5MaB1HInvml for ; Tue, 25 Jun 2019 12:28:33 -0400 (EDT) Received: from [10.5.245.234] (wsip-98-172-18-41.dc.dc.cox.net [98.172.18.41]) by mail.smeinc.net (Postfix) with ESMTPSA id 0F4943004AF; Tue, 25 Jun 2019 12:28:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: Date: Tue, 25 Jun 2019 12:47:49 -0400 Cc: Joel Halpern , SPASM , IETF Gen-ART , IETF , draft-ietf-lamps-pkix-shake.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <39F7F867-CDE2-478E-8934-7F8017003C75@vigilsec.com> References: <155393972295.3950.3582710869606616692@ietfa.amsl.com> <7916915C-76F6-4884-A0D4-FFAA2ABEEA21@cooperw.in> <55e454fa-0076-557f-b5b0-0f9dc0e91fdb@joelhalpern.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] [Gen-art] Genart last call review of draft-ietf-lamps-pkix-shake-08 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jun 2019 16:47:57 -0000 The remaining TBD identifiers will be assigned by IANA. Russ > On Jun 25, 2019, at 12:34 PM, Alissa Cooper wrote: >=20 > Apologies, I thought the concern remained about the TBD identifiers in = the document. > Alissa >=20 >> On Jun 25, 2019, at 12:28 PM, Joel M. Halpern = wrote: >>=20 >> The latest version (which I reviewed yesterday) has the assignments. >> Joel >>=20 >> On 6/25/19 12:27 PM, Alissa Cooper wrote: >>> Joel, thanks for your reviews. I entered a No Objection ballot. I = trust that the identifier assignments will work out with NIST. >>> Alissa >>>> On Mar 31, 2019, at 1:28 AM, Joel M. Halpern = wrote: >>>>=20 >>>> Maybe a note that the assignment will take place once the drafts = are approved, and that the RFC should coordiante with the authors and = NIST on this? (I presume we have done this before, and we do not have = the problem we have in some other cases of "no number until RFC" / "no = RFC until number".) >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 3/31/19 1:21 AM, Russ Housley wrote: >>>>>> On Mar 30, 2019, at 5:55 AM, Joel Halpern via Datatracker = wrote: >>>>>>=20 >>>>>> Reviewer: Joel Halpern >>>>>> Review result: Almost 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 treat these comments just >>>>>> like any other last call comments. >>>>>>=20 >>>>>> For more information, please see the FAQ at >>>>>>=20 >>>>>> . >>>>>>=20 >>>>>> Document: draft-ietf-lamps-pkix-shake-08 >>>>>> Reviewer: Joel Halpern >>>>>> Review Date: 2019-03-30 >>>>>> IETF LC End Date: 2019-04-10 >>>>>> IESG Telechat date: Not scheduled for a telechat >>>>>>=20 >>>>>> Summary: This document is almost ready for publication as a = Proposed Standard >>>>>>=20 >>>>>> Major issues: >>>>>> One of the key points of this RFC seems to be to assign the = identifiers for >>>>>> the use of the two SHAKE variants. It is thus confusing that = the >>>>>> identifiers end with "TBD", and thus are not defined in this = document. >>>>> They will be assigned by NIST once they are sure that these are = the identifiers that we want. This is much the same as we do when IANA = is ti assign the identifier. >>>>> Russ >>>>=20 >>>> _______________________________________________ >>>> Gen-art mailing list >>>> Gen-art@ietf.org >>>> https://www.ietf.org/mailman/listinfo/gen-art >=20 From nobody Tue Jun 25 11:56:40 2019 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 B4B84120C0D for ; Tue, 25 Jun 2019 11:56:28 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 UGCRtGWLoKS0 for ; Tue, 25 Jun 2019 11:56:27 -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 5D8BE120BD8 for ; Tue, 25 Jun 2019 11:56:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 55D43300AEF for ; Tue, 25 Jun 2019 14:37:05 -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 w4YboDDTRMYv for ; Tue, 25 Jun 2019 14:37:02 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 9887E3004AF; Tue, 25 Jun 2019 14:37:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <20190614212637.GV52381@kduck.mit.edu> Date: Tue, 25 Jun 2019 14:56:19 -0400 Cc: IESG , SPASM Content-Transfer-Encoding: quoted-printable Message-Id: References: <155916984601.5535.15415810479866156115.idtracker@ietfa.amsl.com> <83521276-738B-4298-A36D-B3C04E11A05C@vigilsec.com> <20190614212637.GV52381@kduck.mit.edu> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jun 2019 18:56:32 -0000 Ben: >> I have not heard back from you. Please let me know if the proposed = way forward would resolve your DISCUSS position. >=20 > Sorry; it was a busy couple weeks for my personal life. No worries. I moved a few months ago, no nearly as far as your move, = and it was still quite disruptive. >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> After further reflection, I think we need to resurrect the = discussion >>>> sparked by DKG's last-call review. Specifically, in Section 5 when = we >>>> consider the case that there is not a directory service/repository >>>> available, we give guidance to "the recipient" and "recipients". = But in >>>> at least some cases, there are two tiers of recipients/relying = parties, >>>> that have different properties, as in the web PKI situation. >>>> Specifically, web server operators rely on root CAs to certify the >>>> certificates that they present to TLS clients. But we also = consider the >>>> TLS clients themselves, which may not have a direct path to = receiving >>>> the updated root CA self-signed certificate, and because of the >>>> different ways these different types of recipient rely on root CA >>>> information, the order in which they update can cause breakage. We = do >>>> not necessarily need to present a clear solution that will always = avoid >>>> this breakage, but I do think we need to at least discuss the >>>> possibility of such scenarios. >>>>=20 >>>> To consider a concrete case, consider a system with a TLS client = ("A"), >>>> a TLS server ("B"), and the root CA ("C"). C issues (potentially = via >>>> intermediates) an end-entity certificate for B, and we consider a = case >>>> where A initiates TLS connections to B. Initially, C has the root >>>> CA/key at C1, and is initiating a transition to C2; before the >>>> transition both A and B have C1 in their trusted store. When A = receives >>>> C2, it can perform the requisite validation and add C2 to its trust >>>> store for use potentially validating incoming certificate chains. = When >>>> B receives C2, it can similarly perform the requisite validation = and add >>>> C2 to its trust store, but B's trust store is used for validating >>>> *outgoing* certificate chains, not (just) incoming ones. If B were = to >>>> keep C2 in its trust store and construct an outgoing certificate = chain >>>> based on C2 (and omitting oldWithNew and newWithOld), before A has >>>> received C2, then the TLS handshake fails! >>>>=20 >>>> If A had access to C2, or to oldWithnew/NewWithOld, then it would = still >>>> be able to validate B's certificate chain, but this document (and = RFC >>>> 4210) do not give guidance that B should transmit newWithOld to A, >>>> leaving open this scenario for breakage. >>>>=20 >>>> My current inclination is to add some text to this document = acknowleding >>>> the potential for a chain of relying parties, and recommending that = the >>>> "intermediate parties" in the scenario make newWithOld/oldWithNew = available until >>>> the notAfter time from oldWithNew, but I am of course open to = further >>>> discussion/suggestions. >>>=20 >>> I think that the document is fairly clear that there can be some = failure if there is not a repository or directory service. However, = while thinking about this over night, I realized that we could also = point to the the Subject Information Access certificate extension in RFC = 5280, Section 4.2.2.2. >=20 > I don't really feel like that clear picture is getting conveyed, = though. > (Which is not to say that adding text about this extension is a bad = idea, > of course!) >=20 > Focusing on the Operational Considerations, and taking an example: >=20 > Guidance on the transition from one trust anchor to another is > available in Section 4.4 of [RFC4210]. In particular, the = oldWithNew > and newWithOld advice ensures that relying parties are able to > validate certificates issued under the current Root CA certificate > and the next generation Root CA certificate throughout the > transition. [...] >=20 > To me, this comes across as saying that the existence of oldWithNew = and > newWithOld takes care of everything and "ensures that relying parties = are > able to validate certificates". Perhaps the subtlety lies in the > definition of "relying party" -- RFC 4210 is of course pretty well = steeped > in the repository/directory service setup. It's also interesting to = me to > note, though, that RFC 4120 talks about the entities that need to = worry > about getting the CA public keys as being the entities that themselves = have > certificates (e.g., "typically be easily achieved when these end = entities' > certificates expire"). While that's a valid use case, it does seem a = bit > divorced from the (e.g., Web) case where the entity that needs the CA > public key does not have a certificate, such as when it's a browser. Two paragraphs later the document talk about the distribution of the = certificates: Some enterprise and application-specific environments offer a directory service or certificate repository to make certificate and CRLs available to relying parties. Section 3 in [RFC5280] describes a certificate repository. When a certificate repository is available, the oldWithNew and newWithOld certificates SHOULD be published before the successor to the current Root CA self-signed certificate is released. Recipients that are able to obtain the oldWithNew certificate SHOULD immediately remove the old Root CA self-signed certificate from the trust anchor store. I believe that covers the case where there is a repository. I propose to replace the paragraph after that with one that handles the = non-repository case and points out that the Wen PKI falls in that case. = See below. >>> The id-ad-caRepository OID is used when the subject is a CA that >>> publishes certificates it issues in a repository. The = accessLocation >>> field is defined as a GeneralName, which can take several forms. >>>=20 >>> ... >>>=20 >>> Where the information is available via HTTP or FTP, accessLocation >>> MUST be a uniformResourceIdentifier and the URI MUST point to = either >>> a single DER encoded certificate as specified in [RFC2585] or a >>> collection of certificates in a BER or DER encoded "certs-only" CMS >>> message as specified in [RFC2797]. >>>=20 >>> I am willing to RECOMMEND the inclusion of this extension and = posting the oldWithNew and newWithOld so that they can be fetched using = the "certs-only" (simple PKI response). This format would allow = certificates to be added and removed from the bag of certificates over = time. >=20 > That does seem worth doing. >=20 > I think what would best help move the document forward right now would = be > for you to point me at the existing text that is "fairly clear that = there > can be some failure if there is not a repository or directory = service.", > since I seem to have missed it. Text that matches that description = should > be enough to resolve the Discuss point -- we don't need to bend over > backwards to satisfy the Web PKI case when the mechanism works fine = as-is > in other use cases. Here is the proposed text for the non-repository case. The first = paragraph offers guidance to the Root CA, and the next one offers = guidance to recipients: In environments without such a directory service or repository, like the Web PKI, recipients need a way to obtain the oldWithNew and newWithOld certificates. The Root CA SHOULD include the subject information access extension [RFC5280] with the accessMethod set to id-ad-caRepository and the assessLocation set to the HTTP URL that can be used to fetch a DER-encoded "certs-only" (simple PKI response) message as specified in [RFC5272]. The Root CA SHOULD post the "certs-only" message with the oldWithNew certificate and the newWithOld certificate before the current Root CA self-signed certificate is released. The "certs-only" message format allows certificates to be added and removed from the bag of certificates over time, so the same HTTP URL can be used throughout the lifetime of the Root CA. In environments without such a directory service or repository, recipients SHOULD keep both the old and replacement Root CA self- signed certificates in the trust anchor store for some amount of time to ensure that all end-entity certificates can be validated until they expire. The recipient MAY keep the old Root CA self-signed certificate until all of the certificates in the local cache that are subordinate to it have expired. I have trimmed the rest of the message because those points have been = resolved. Russ From nobody Tue Jun 25 14:29:18 2019 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 D415E1201DA; Tue, 25 Jun 2019 14:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 header.b=Uv4RF/a0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=t4oY5+vU 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 KWCrmmojB1BU; Tue, 25 Jun 2019 14:29:07 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD531201C6; Tue, 25 Jun 2019 14:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3962; q=dns/txt; s=iport; t=1561498146; x=1562707746; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uqyt50cBSwniC99mODR7P3t9TETSYkmYOCcnpHlwAkY=; b=Uv4RF/a0rbk7yd58vIIpRoaj2SQbC9p3HUy7TMdGEfAxYywoNoVKOQVX R0C43if5uIjWdnDQpMIhf/bdsaeXDhCA89RPyMY0mns64PcAub5NOX7sK cD9vEEF1fZDSIx79TvHeh8Ve2TeJoNCSuYZFOfTMjaHtbT3T2uUqy53q+ k=; IronPort-PHdr: =?us-ascii?q?9a23=3AacsgihX2OjOZXxrI1OP/rMUQAzPV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankiH81HTFZj9lmwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAACQkRJd/5tdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAQBAQEBCwGBQ1ADalUgBAsohBWDRwOOY4JblziBLhSBEAN?= =?us-ascii?q?UCQEBAQwBARgLCgIBAYRAAheCXiM1CA4BAwEBBAEBAgEFbYo3DIVKAQEBAQI?= =?us-ascii?q?BAQEQEREMAQEsCwEEBwQCAQgRBAEBAwImAgICJQsVBQMIAgQBDQUIGoMBgWo?= =?us-ascii?q?DDg8BAgyaagKBOIhfcYExgnkBAQWBRkGCfhiCEQMGgQwoAYtdF4FAP4ERRoJ?= =?us-ascii?q?MPoJhAQEBAgGBKgESASGDCDKCJowGgk6bRAkCghWGUI02gimHDo4XgySKBIE?= =?us-ascii?q?whgWPWQIEAgQFAg4BAQWBUQE2Z1gRCHAVO4JsgkE3gzmFFIU/cgGBKIx4gkM?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.63,417,1557187200"; d="scan'208";a="495368572" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jun 2019 21:29:04 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x5PLT5W3018235 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Jun 2019 21:29:05 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Jun 2019 16:29:04 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Jun 2019 17:29:03 -0400 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 25 Jun 2019 17:29:03 -0400 ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=BV7ZQ24/ag9h9nh/A1HWY9fcELEjugUV33eNI9ZJ2PsoTsCPe1Gy+ild+gm6n7AeEk3no8Vn5aygEolKFIJZ+C/nmaqsCZRXDdsE8pVKmPmlToHV/BSNUCEvbzM2XdJpkDlXRw6uNoDQEqWfGboIILulJ5uSp4fy6P3hI5JBUlY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uqyt50cBSwniC99mODR7P3t9TETSYkmYOCcnpHlwAkY=; b=GasvnKzioWxQaDuJO1/69DY3UaDM3FU3OKGizSvnrkjAEAUGiSQ1lzofRrLJswKyf+UqGtf+yXXfQ87hdDu56hzYQ5G036/+lCcLITjkeYN97cGDwFDLM2qw5oNx9XSazQ3i9aFG4OBeukaIAhB2FqrS2vPy7sBn1sWTZ+bpOto= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uqyt50cBSwniC99mODR7P3t9TETSYkmYOCcnpHlwAkY=; b=t4oY5+vUyfEC2ga8FEgQ+sF3uuL88+tiqkvB4FE4BYwWn0TXF3IAVw0XD90LgBmwpbKjXk46wxq3OyFyPjYidRT4889FogstoFqGnTh0Z6lJMULDWkTgr8p2EysZM8/SEP47caoO/T1KGqKksoDnI4Zy4m86RaV6pW3YivvmJw4= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.244.29) by BN7PR11MB2723.namprd11.prod.outlook.com (52.135.245.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Tue, 25 Jun 2019 21:29:01 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b1dc:fd0d:e540:67aa]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b1dc:fd0d:e540:67aa%7]) with mapi id 15.20.2008.014; Tue, 25 Jun 2019 21:29:01 +0000 From: "Panos Kampanakis (pkampana)" To: "Eric Vyncke (evyncke)" , The IESG CC: "spasm@ietf.org" , "housley@vigilsec.com" , "draft-ietf-lamps-pkix-shake@ietf.org" , "lamps-chairs@ietf.org" Thread-Topic: =?utf-8?B?W2xhbXBzXSDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQt?= =?utf-8?Q?ietf-lamps-pkix-shake-11:_(with_COMMENT)?= Thread-Index: AQHVKynAi0DtGYr0LkmVnDKVmuFw7qas3xIA Date: Tue, 25 Jun 2019 21:29:01 +0000 Message-ID: References: <156144862226.22755.5941558703193888438.idtracker@ietfa.amsl.com> In-Reply-To: <156144862226.22755.5941558703193888438.idtracker@ietfa.amsl.com> 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=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1006::3c4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 69cbe1a6-4ab0-4bc9-b346-08d6f9b4241d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2723; x-ms-traffictypediagnostic: BN7PR11MB2723: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0079056367 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(396003)(39860400002)(346002)(376002)(136003)(366004)(54534003)(13464003)(51914003)(199004)(189003)(256004)(81166006)(7736002)(6306002)(6436002)(25786009)(9686003)(55016002)(4326008)(14444005)(2906002)(66574012)(71190400001)(71200400001)(46003)(66476007)(6246003)(478600001)(52536014)(66446008)(64756008)(66556008)(66946007)(73956011)(76116006)(53936002)(229853002)(54906003)(5660300002)(8936002)(316002)(110136005)(224303003)(86362001)(68736007)(14454004)(186003)(966005)(76176011)(6116002)(476003)(99286004)(446003)(11346002)(486006)(53546011)(305945005)(74316002)(81156014)(6506007)(33656002)(102836004)(7696005)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2723; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rgHbw7M2IEUgekUg2GtiCXhBkHFZmI++dBWXzxvjkCQdExbR74+Ygqcuniy57oa6jPgIPIzDotwgYI9SKcdzAzCIv0Ldbry+PGcdoJTr9mQ2y0sA14DYcESCtgrQpWmA2EXgT7cuktww6E96OuJy27TkXR5/tB/S+PCjvBpPKkW1oMkT8Fu2PAreQmfsV3pdlQDZ1bvTqrZQ3zhC0FEk/b2oall90AzOYiqmhlgVSbdYTdntMahp5AholbMR0e5Nk2Rq2Eqd65TbEHTRWk+nKW7oS8l10A4YqpTBD5yYB5biQD21qwlV4kdS5bTs6BD88kyDo+T7t/b6RjuK65RfKVCOwT/M2xK48jpu1C11QeYxHmnb3+EueB5CQlfUGLdMIRY4acCgBeLbVE3vNv9XGVnLHQRLVaH8w3GxaNlXNo0= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 69cbe1a6-4ab0-4bc9-b346-08d6f9b4241d X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2019 21:29:01.2960 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkampana@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2723 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [lamps] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-lamps-pkix-shake-11=3A_=28with_COMMENT=29?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jun 2019 21:29:09 -0000 VGhhbmtzIGZvciB0aGUgcmV2aWV3IEVyaWMuIA0KDQpZb3VyIGZlZWRiYWNrIGFuZCB0aGUgYW5z d2VycyBiZWxvdyBhcmUgYWxzbyBpbiBodHRwczovL2dpdGh1Yi5jb20vY3Nvc3RvLXBrL2FkZGlu Zy1zaGFrZS10by1wa2l4L2lzc3Vlcy80OCANCg0KDQoNCj4gTWF5IEkgYXNzdW1lIHRoYXQgdGhl IGlzc3VlcyBieSB0aGUgdHdvIHJldmlld3Mgb2YgLTA4IGFyZSBzb2x2ZWQgaW4gLTExID8NCg0K WWVzLiBBbmQgdGhlIHVwY29taW5nIHVwZGF0ZSAtMTIgd2lsbCBpbmNsdWRlIGFsbCB0aGUgZml4 ZXMgZm9yIHRoZSBsYXN0IDMgYmFsbG90IHBvc2l0aW9uIHJldmlld3MuIA0KDQo+IEp1c3Qgd29u ZGVyaW5nIHdoeSBDUkwgYWNyb255bSBpcyBleHBhbmRlZCB3aGlsZSBTSEFLRSAmIEVDRFNBIGFy ZSBub3QuDQoNCkdvb2QgcG9pbnQuIFNpbmNlIHdlIGFyZSBpbiB0aGUgYWJzdHJhY3QgSSBtYWRl IGEgY2hhbmdlIGFuZCBrZXB0IENSTCBpbiB0aGVyZSB3aXRob3V0IGV4cGFuZGluZyB0aGUgYWNy b255bS4gQnV0IEkgbWFkZSBzdXJlIGl0IGlzIGV4cGFuZGVkIGluIHRoZSBmaXJzdCBvY2N1cnJl bmNlIG9mIHRoZSBhY3JvbnltIGluIHRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbi4gV2UgZG9uJ3Qg ZXhwYW5kIHRoZSBTSEFLRSBhbmQgRUNEU0Egb3IgUlNBU1NBLVBTUyBiZWNhdXNlIHRoZXNlIGFy ZSBhbGdvcml0aG0gbmFtZXMsIG5vdCBleGFjdGx5IGFiYnJldmlhdGVkIGFjcm9ueW1zLiANCg0K PiBBbHNvIHdvbmRlcmluZyB3aHkgaW4gc29tZSBJQU5BIGVudHJpZXMgIlNIQUtFIiBpcyBpbiBs b3dlciBjYXNlIHdoaWxlIGluIG90aGVycyBpbiB1cHBlciBjYXNlLg0KDQpUaGUgUlNBU1NBLVBT UyBPSURzIGtlcHQgU0hBS0UgaW4gY2FwaXRhbHMgYmVjYXVzZSBpdCBzZWVtZWQgdW5uYXR1cmFs IHRvIHB1dCB0aGVtIGxvd2VyY2FzZSBhZnRlciB0aGUgY2FwaXRhbHMgb2YgUlNBU1NBLVBTUy4g Rm9yIGVjZHNhIHdlIGtlcHQgaXQgbG93ZXJjYXNlIGJlY2F1c2UgdGhhdCBpcyBob3cgdGhlIE9J RHMgbG9va2VkIGluIHRoZSBwYXN0IGZvciBlY2RzYS1zaGEyLiBJdCBpcyBhIGxpdHRsZSBhcmJp dHJhcnksIGJ1dCB0aGF0IGlzIHdoeSB3ZSBtYWRlIHRoZW0gbG9vayBsaWtlIHRoYXQuIA0KDQpU aGUgbmV4dCBpdGVyYXRpb24gd2lsbCBiZSB1cGxvYWRlZCBhdCB0aGUgZW5kIG9mIHRoaXMgd2Vl ayBwcm9iYWJseS4gDQoNClJncywNClBhbm9zDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IFNwYXNtIDxzcGFzbS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Ygw4ly aWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlcg0KU2VudDogVHVlc2RheSwgSnVuZSAyNSwgMjAxOSAz OjQ0IEFNDQpUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogc3Bhc21AaWV0Zi5vcmc7 IGhvdXNsZXlAdmlnaWxzZWMuY29tOyBkcmFmdC1pZXRmLWxhbXBzLXBraXgtc2hha2VAaWV0Zi5v cmc7IGxhbXBzLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogW2xhbXBzXSDDiXJpYyBWeW5ja2Un cyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1sYW1wcy1wa2l4LXNoYWtlLTExOiAod2l0aCBD T01NRU5UKQ0KDQrDiXJpYyBWeW5ja2UgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3Qg cG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLWxhbXBzLXBraXgtc2hha2UtMTE6IE5vIE9iamVjdGlv bg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0 IGFuZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg Q0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwg aG93ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cv c3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQs IGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWxhbXBzLXBraXgtc2hh a2UvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGFu ayB5b3UgYWxsIGZvciB0aGUgd29yayBwdXQgaW50byB0aGlzIGRvY3VtZW50Lg0KDQo9PSBDT01N RU5UUyA9PQ0KDQotLSBTZWN0aW9uIDEgLyBDaGFuZ2UgbG9nIC0tDQoNCk1heSBJIGFzc3VtZSB0 aGF0IHRoZSBpc3N1ZXMgYnkgdGhlIHR3byByZXZpZXdzIG9mIC0wOCBhcmUgc29sdmVkIGluIC0x MSA/DQoNCg0KLS0gU2VjdGlvbiA0IC0tDQoNCj09IE5JVFMgPT0NCg0KLS0gQWJzdHJhY3QgLS0N Cg0KSnVzdCB3b25kZXJpbmcgd2h5IENSTCBhY3JvbnltIGlzIGV4cGFuZGVkIHdoaWxlIFNIQUtF ICYgRUNEU0EgYXJlIG5vdC4NCg0KLS0gc2VjdGlvbiA2IC0tDQoNCkFsc28gd29uZGVyaW5nIHdo eSBpbiBzb21lIElBTkEgZW50cmllcyAiU0hBS0UiIGlzIGluIGxvd2VyIGNhc2Ugd2hpbGUgaW4g b3RoZXJzIGluIHVwcGVyIGNhc2UuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NClNwYXNtIG1haWxpbmcgbGlzdA0KU3Bhc21AaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Bhc20NCg== From nobody Tue Jun 25 20:48:13 2019 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 70464120122; Tue, 25 Jun 2019 20:48:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-lamps-pkix-shake@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <156152088345.31201.14139946948942855775.idtracker@ietfa.amsl.com> Date: Tue, 25 Jun 2019 20:48:03 -0700 Archived-At: Subject: [lamps] Adam Roach's No Objection on draft-ietf-lamps-pkix-shake-11: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jun 2019 03:48:04 -0000 Adam Roach has entered the following ballot position for draft-ietf-lamps-pkix-shake-11: 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-pkix-shake/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors for a well-written and easy to read document. I have only one minor comment. This document updates RFC 3279. It would be helpful if the abstract indicated this fact. (cf. https://www.ietf.org/standards/ids/checklist/ §3.1.D.1) From nobody Thu Jun 27 10:42:18 2019 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 6531F1201DC; Thu, 27 Jun 2019 10:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 header.b=KN+8C8gO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MoS9YG8q 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 j6FIi5Qb40Fo; Thu, 27 Jun 2019 10:42:07 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC90012027B; Thu, 27 Jun 2019 10:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2210; q=dns/txt; s=iport; t=1561657324; x=1562866924; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ETT1wGjVNCOLHp/Ovu7b63+f2QExBmFOlBhugEkTZkA=; b=KN+8C8gOJYtzc0Y8nMdEa3aK5aCFP09WproyzCpALz1xWPgI12MrgmCP osqDpEktg8d2lF1ZMifrsqkxR4UADjNJHKwJ4SSIBktpqe3JQctSFTYsU 1eSYVQcIFvZw5O4e4x6V4GYSyaCAOoK3bSKzYZH1uS275F6y7j1KAEQuc 8=; IronPort-PHdr: =?us-ascii?q?9a23=3APxR4iBEgljtf2JmCqyfgV51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eebpZikiFcJLfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAAAa/xRd/5FdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBQ1ADalUgBAsoCoQPg0cDhFKKCYJblz+BLhS?= =?us-ascii?q?BEANUCQEBAQwBARgLCgIBAYRAAheCaSM0CQ4BAwEBBAEBAgEFbYo3DIVKAQE?= =?us-ascii?q?BBAEBEBERDAEBLAsBCwQCAQgRBAEBAwImAgICJQsVCAgCBAENBQgagwGBagM?= =?us-ascii?q?dAQIMmzMCgTiIYHGBMoJ5AQEFgUZBgwEYghEDBoEMKAGLXheBQD+BEUaCTD6?= =?us-ascii?q?CYQEBAQIBgSoBEgEhFYJzMoImjA+CT5tMCQKCF4ZSjT6CK4cXhAyKEI0phzi?= =?us-ascii?q?PZgIEAgQFAg4BAQWBUDhnWBEIcBU7gjgBM4JBN4M6hRSFP3IBgSiLNYEiAYE?= =?us-ascii?q?gAQE?= X-IronPort-AV: E=Sophos;i="5.63,424,1557187200"; d="scan'208";a="363738013" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jun 2019 17:42:03 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x5RHg3Wk013047 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Jun 2019 17:42:03 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 12:42:02 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 12:42:02 -0500 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 27 Jun 2019 13:42:02 -0400 ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=lCTlxGpxMJcxF5UZPVMezwpAu5Niwh7MkfBrjWhElmyD2AlnCOHf/jnI4XVlSEFut8UX10XpwfGo38JilKc6aKp1udSO/ksUD73vJSg8UsKniVq68C7/XcC/BnrDOnIUkexnCeiOCuIBNBn/N0blQ1EiY6R5wDLru4EQmYupRFo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ETT1wGjVNCOLHp/Ovu7b63+f2QExBmFOlBhugEkTZkA=; b=yFznEeVu3KrwapNIIy57C5mbI2Gxl5izFt/IyevI0wAc2j680r5lmP2aCpst4lvoNfRn9TYvYLYJxn9S3maehr0Em9SMa4kUrizU4VXIvdNDOePuBjur7xkebH3boBMMszAnEPRjRPkyzqXZmVnhYC1hbi1QJP+vJhOsMNw88Io= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ETT1wGjVNCOLHp/Ovu7b63+f2QExBmFOlBhugEkTZkA=; b=MoS9YG8qJgBB0GmtHKIDpdGV+7bO1vDizzWpp2OsIgTn2kDJOF9cACms0aO3h8DmbJ5C6OyTrCx5yIADtz6dTWMx2yoIU8vdZJO7aa3E22l5Byvzk4aD+NEYlGY18NuXSreTOcnHXJc3UIITqFaNYvSt9eNL35DiVoxYk+64wSc= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.244.29) by BN7PR11MB2561.namprd11.prod.outlook.com (52.135.244.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Thu, 27 Jun 2019 17:42:00 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b1dc:fd0d:e540:67aa]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b1dc:fd0d:e540:67aa%7]) with mapi id 15.20.2008.018; Thu, 27 Jun 2019 17:42:00 +0000 From: "Panos Kampanakis (pkampana)" To: Adam Roach , The IESG CC: "spasm@ietf.org" , "housley@vigilsec.com" , "draft-ietf-lamps-pkix-shake@ietf.org" , "lamps-chairs@ietf.org" Thread-Topic: [lamps] Adam Roach's No Objection on draft-ietf-lamps-pkix-shake-11: (with COMMENT) Thread-Index: AQHVK9H/RT1J4oIt3EiYU1cFVB5Mk6avuy2Q Date: Thu, 27 Jun 2019 17:42:00 +0000 Message-ID: References: <156152088345.31201.14139946948942855775.idtracker@ietfa.amsl.com> In-Reply-To: <156152088345.31201.14139946948942855775.idtracker@ietfa.amsl.com> 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=pkampana@cisco.com; x-originating-ip: [173.38.117.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: da902d82-6319-49e2-8bc7-08d6fb26c213 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2561; x-ms-traffictypediagnostic: BN7PR11MB2561: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 008184426E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(136003)(396003)(366004)(189003)(199004)(13464003)(81156014)(66946007)(81166006)(8676002)(110136005)(486006)(33656002)(5660300002)(446003)(53936002)(256004)(6116002)(3846002)(316002)(476003)(68736007)(11346002)(54906003)(8936002)(6306002)(9686003)(186003)(55016002)(52536014)(86362001)(102836004)(7736002)(229853002)(6436002)(26005)(76176011)(99286004)(66446008)(64756008)(14454004)(66556008)(71200400001)(76116006)(74316002)(66476007)(71190400001)(2906002)(478600001)(25786009)(7696005)(6246003)(966005)(4326008)(6506007)(53546011)(305945005)(73956011)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2561; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uVig8VNAxUNOS27IAciYWTzEbCOtxty/IEAiLlyAEjFEhK1WqpEUw6Sn9IH8B9Zka0Hm0Lw023dS042zFVEjOO5A0Bo/MOYYUQ6FqekRmhDZDz9iG5fAu1MI5BE5FprnCggACQiZMi47gFmXh6PIlUnky/OhbrkPatPDzhcshXofN838FhWNbLjhCyqpIPTDVASPQeoEY/kLh7dCQDsfrMDs/GEQNyq8oJ3hLkwtSmedVFSnPZmvx46b+qLTVxXvkcCLmQ/MSlrTdm4CQJb5xS9IKcm8Z6Pz0YQ5Xx90ZXSIWExozWwEwHdOedhucd6wv42ofG2csMWhhWn86SEs8rYUzztedCiKKWcCwE6R3AfOVHw03MDq66ugqNvmjmOKH4e8a4Eayqz/OuqY6/yOqLJpUuFZSvveSRotSgAaGcg= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: da902d82-6319-49e2-8bc7-08d6fb26c213 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 17:42:00.0565 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkampana@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2561 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [lamps] Adam Roach's No Objection on draft-ietf-lamps-pkix-shake-11: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 27 Jun 2019 17:42:09 -0000 VGhhbmtzIEFkYW0uIEdvb2QgcG9pbnQuIEkgZml4ZWQgaW4gdGhlIGFic3RyYWN0cyBvZiBib3Ro IGRvY3MuIA0KSSB3aWxsIHJldXBsb2FkIHRoZSBkcmFmdCB0b21vcnJvdyBwcm9iYWJseS4gDQoN ClBhbm9zDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNwYXNtIDxzcGFz bS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQWRhbSBSb2FjaCB2aWEgRGF0YXRyYWNr ZXINClNlbnQ6IFR1ZXNkYXksIEp1bmUgMjUsIDIwMTkgMTE6NDggUE0NClRvOiBUaGUgSUVTRyA8 aWVzZ0BpZXRmLm9yZz4NCkNjOiBzcGFzbUBpZXRmLm9yZzsgaG91c2xleUB2aWdpbHNlYy5jb207 IGRyYWZ0LWlldGYtbGFtcHMtcGtpeC1zaGFrZUBpZXRmLm9yZzsgbGFtcHMtY2hhaXJzQGlldGYu b3JnDQpTdWJqZWN0OiBbbGFtcHNdIEFkYW0gUm9hY2gncyBObyBPYmplY3Rpb24gb24gZHJhZnQt aWV0Zi1sYW1wcy1wa2l4LXNoYWtlLTExOiAod2l0aCBDT01NRU5UKQ0KDQpBZGFtIFJvYWNoIGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1s YW1wcy1wa2l4LXNoYWtlLTExOiBObyBPYmplY3Rpb24NCg0KV2hlbiByZXNwb25kaW5nLCBwbGVh c2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFk ZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1 dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZl ciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlh Lmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVO VCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBw b3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1sYW1wcy1wa2l4LXNoYWtlLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Q09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhhbmtzIHRvIHRoZSBhdXRob3JzIGZvciBhIHdl bGwtd3JpdHRlbiBhbmQgZWFzeSB0byByZWFkIGRvY3VtZW50LiBJIGhhdmUgb25seSBvbmUgbWlu b3IgY29tbWVudC4NCg0KVGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQyAzMjc5LiBJdCB3b3VsZCBi ZSBoZWxwZnVsIGlmIHRoZSBhYnN0cmFjdCBpbmRpY2F0ZWQgdGhpcyBmYWN0LiAoY2YuIGh0dHBz Oi8vd3d3LmlldGYub3JnL3N0YW5kYXJkcy9pZHMvY2hlY2tsaXN0LyDCpzMuMS5ELjEpDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNwYXNtIG1h aWxpbmcgbGlzdA0KU3Bhc21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc3Bhc20NCg== From nobody Thu Jun 27 17:22:20 2019 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 3FA60120122; Thu, 27 Jun 2019 17:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40jqRFD4AZFR; Thu, 27 Jun 2019 17:22:15 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E39CE1200EF; Thu, 27 Jun 2019 17:22:14 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5S0MAKG023284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Jun 2019 20:22:12 -0400 Date: Thu, 27 Jun 2019 19:22:09 -0500 From: Benjamin Kaduk To: Russ Housley Cc: IESG , SPASM Message-ID: <20190628002208.GQ18345@kduck.mit.edu> References: <155916984601.5535.15415810479866156115.idtracker@ietfa.amsl.com> <83521276-738B-4298-A36D-B3C04E11A05C@vigilsec.com> <20190614212637.GV52381@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 00:22:18 -0000 On Tue, Jun 25, 2019 at 02:56:19PM -0400, Russ Housley wrote: > Ben: > > >> I have not heard back from you. Please let me know if the proposed way forward would resolve your DISCUSS position. > > > > Sorry; it was a busy couple weeks for my personal life. > > No worries. I moved a few months ago, no nearly as far as your move, and it was still quite disruptive. > > > >>>> ---------------------------------------------------------------------- > >>>> DISCUSS: > >>>> ---------------------------------------------------------------------- > >>>> > >>>> After further reflection, I think we need to resurrect the discussion > >>>> sparked by DKG's last-call review. Specifically, in Section 5 when we > >>>> consider the case that there is not a directory service/repository > >>>> available, we give guidance to "the recipient" and "recipients". But in > >>>> at least some cases, there are two tiers of recipients/relying parties, > >>>> that have different properties, as in the web PKI situation. > >>>> Specifically, web server operators rely on root CAs to certify the > >>>> certificates that they present to TLS clients. But we also consider the > >>>> TLS clients themselves, which may not have a direct path to receiving > >>>> the updated root CA self-signed certificate, and because of the > >>>> different ways these different types of recipient rely on root CA > >>>> information, the order in which they update can cause breakage. We do > >>>> not necessarily need to present a clear solution that will always avoid > >>>> this breakage, but I do think we need to at least discuss the > >>>> possibility of such scenarios. > >>>> > >>>> To consider a concrete case, consider a system with a TLS client ("A"), > >>>> a TLS server ("B"), and the root CA ("C"). C issues (potentially via > >>>> intermediates) an end-entity certificate for B, and we consider a case > >>>> where A initiates TLS connections to B. Initially, C has the root > >>>> CA/key at C1, and is initiating a transition to C2; before the > >>>> transition both A and B have C1 in their trusted store. When A receives > >>>> C2, it can perform the requisite validation and add C2 to its trust > >>>> store for use potentially validating incoming certificate chains. When > >>>> B receives C2, it can similarly perform the requisite validation and add > >>>> C2 to its trust store, but B's trust store is used for validating > >>>> *outgoing* certificate chains, not (just) incoming ones. If B were to > >>>> keep C2 in its trust store and construct an outgoing certificate chain > >>>> based on C2 (and omitting oldWithNew and newWithOld), before A has > >>>> received C2, then the TLS handshake fails! > >>>> > >>>> If A had access to C2, or to oldWithnew/NewWithOld, then it would still > >>>> be able to validate B's certificate chain, but this document (and RFC > >>>> 4210) do not give guidance that B should transmit newWithOld to A, > >>>> leaving open this scenario for breakage. > >>>> > >>>> My current inclination is to add some text to this document acknowleding > >>>> the potential for a chain of relying parties, and recommending that the > >>>> "intermediate parties" in the scenario make newWithOld/oldWithNew available until > >>>> the notAfter time from oldWithNew, but I am of course open to further > >>>> discussion/suggestions. > >>> > >>> I think that the document is fairly clear that there can be some failure if there is not a repository or directory service. However, while thinking about this over night, I realized that we could also point to the the Subject Information Access certificate extension in RFC 5280, Section 4.2.2.2. > > > > I don't really feel like that clear picture is getting conveyed, though. > > (Which is not to say that adding text about this extension is a bad idea, > > of course!) > > > > Focusing on the Operational Considerations, and taking an example: > > > > Guidance on the transition from one trust anchor to another is > > available in Section 4.4 of [RFC4210]. In particular, the oldWithNew > > and newWithOld advice ensures that relying parties are able to > > validate certificates issued under the current Root CA certificate > > and the next generation Root CA certificate throughout the > > transition. [...] > > > > To me, this comes across as saying that the existence of oldWithNew and > > newWithOld takes care of everything and "ensures that relying parties are > > able to validate certificates". Perhaps the subtlety lies in the > > definition of "relying party" -- RFC 4210 is of course pretty well steeped > > in the repository/directory service setup. It's also interesting to me to > > note, though, that RFC 4120 talks about the entities that need to worry > > about getting the CA public keys as being the entities that themselves have > > certificates (e.g., "typically be easily achieved when these end entities' > > certificates expire"). While that's a valid use case, it does seem a bit > > divorced from the (e.g., Web) case where the entity that needs the CA > > public key does not have a certificate, such as when it's a browser. > > Two paragraphs later the document talk about the distribution of the certificates: > > Some enterprise and application-specific environments offer a > directory service or certificate repository to make certificate and > CRLs available to relying parties. Section 3 in [RFC5280] describes > a certificate repository. When a certificate repository is > available, the oldWithNew and newWithOld certificates SHOULD be > published before the successor to the current Root CA self-signed > certificate is released. Recipients that are able to obtain the > oldWithNew certificate SHOULD immediately remove the old Root CA > self-signed certificate from the trust anchor store. > > I believe that covers the case where there is a repository. Definitely. > I propose to replace the paragraph after that with one that handles the non-repository case and points out that the Wen PKI falls in that case. See below. > > >>> The id-ad-caRepository OID is used when the subject is a CA that > >>> publishes certificates it issues in a repository. The accessLocation > >>> field is defined as a GeneralName, which can take several forms. > >>> > >>> ... > >>> > >>> Where the information is available via HTTP or FTP, accessLocation > >>> MUST be a uniformResourceIdentifier and the URI MUST point to either > >>> a single DER encoded certificate as specified in [RFC2585] or a > >>> collection of certificates in a BER or DER encoded "certs-only" CMS > >>> message as specified in [RFC2797]. > >>> > >>> I am willing to RECOMMEND the inclusion of this extension and posting the oldWithNew and newWithOld so that they can be fetched using the "certs-only" (simple PKI response). This format would allow certificates to be added and removed from the bag of certificates over time. > > > > That does seem worth doing. > > > > I think what would best help move the document forward right now would be > > for you to point me at the existing text that is "fairly clear that there > > can be some failure if there is not a repository or directory service.", > > since I seem to have missed it. Text that matches that description should > > be enough to resolve the Discuss point -- we don't need to bend over > > backwards to satisfy the Web PKI case when the mechanism works fine as-is > > in other use cases. > > Here is the proposed text for the non-repository case. The first paragraph offers guidance to the Root CA, and the next one offers guidance to recipients: > > In environments without such a directory service or repository, like > the Web PKI, recipients need a way to obtain the oldWithNew and > newWithOld certificates. The Root CA SHOULD include the subject > information access extension [RFC5280] with the accessMethod set to > id-ad-caRepository and the assessLocation set to the HTTP URL that > can be used to fetch a DER-encoded "certs-only" (simple PKI response) > message as specified in [RFC5272]. The Root CA SHOULD post the > "certs-only" message with the oldWithNew certificate and the > newWithOld certificate before the current Root CA self-signed > certificate is released. The "certs-only" message format allows I might be confused, but if "the current Root CA self-signed certificate is released" means that people are using the current root, then this doesn't seem to make much sense -- that requires using the next key to sign OldWithNew before the current key is usable, which seems counter to the point of the flow here. So I think this maybe was supposed to be "successor" instead of "current"? > certificates to be added and removed from the bag of certificates > over time, so the same HTTP URL can be used throughout the lifetime > of the Root CA. > > In environments without such a directory service or repository, > recipients SHOULD keep both the old and replacement Root CA self- > signed certificates in the trust anchor store for some amount of time > to ensure that all end-entity certificates can be validated until > they expire. The recipient MAY keep the old Root CA self-signed > certificate until all of the certificates in the local cache that are > subordinate to it have expired. Modulo the above comment, this should be enough to resolve the Discuss. I think I'm still left a bit unsatisfied by the document since I don't get a clear picture of what roles "recipients" take. Presumably this is to some extent intentional, so as to be relevant in many use cases and not have to finesse distinctions such as the Web PKI's TLS client and end-entity server, but my current understanding still includes different recipients using the root CA for different purposes and getting it in different ways, and there's something of an impedance mismatch between the text of the document and my understanding. I admit the possibility that the document is fine and my understanding wrong, so I don't want to stand in the way of the document moving forward. Thanks, Ben From nobody Thu Jun 27 19:52:18 2019 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 D86A91200EF; Thu, 27 Jun 2019 19:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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 header.b=iFt9RsWc; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MeqZpK4E 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 eaXm5KLVPair; Thu, 27 Jun 2019 19:52:07 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F7F120094; Thu, 27 Jun 2019 19:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6457; q=dns/txt; s=iport; t=1561690327; x=1562899927; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FUHPDrKSIiaN94kuMUSoFqwUCShIitRqmUrCGukqJrU=; b=iFt9RsWcpy6u/HPq2Kow3LMirnzJ4IXkNiaZISiTIqGdtn0Dtmvz2LaZ vQH4HkQp/ZZWdkSZj4nk8wYGlo2L6CFYlB0yUCG9hvVG6LZeghnnG7H6F m4EGVnn9FrjPXPE/AL9fLSjL9EjKqNfxEjg1mUMBJmdnMZk4e3n2S8bE/ k=; IronPort-PHdr: =?us-ascii?q?9a23=3AYqViLRCY2fq/KviwD4srUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNP3jajQzGs1qX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AACJfxVd/5ldJa1mDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgWeBRFADalUgBAsoh2MDjlyCW5dEgUKBEANUCQEBAQw?= =?us-ascii?q?BARgNCAIBAYRAAoMAIzgTAQMBAQQBAQIBBW2KNwyFSgEBAQQBARAoBgEBLAs?= =?us-ascii?q?BCwQCAQgRBAEBHgEQJwsdCAIEAQ0FCBqDAYFqAx0BAgyaVwKBOIhggiOCeQE?= =?us-ascii?q?BBYEyARNBgwYYghEDBoE0i18XgUA/gRFGgkw+gmEBAQEBAQGBKgESASEwgwq?= =?us-ascii?q?CJot9EodtlUNrCQKCFoZSjT6CK4cXjE+BTY0phziPZgIEAgQFAg4BAQWBZyF?= =?us-ascii?q?nWBEIcBU7gmwTgi4JAgEXFIM6hRSFBDtyAQmBH4tFgkMBAQ?= X-IronPort-AV: E=Sophos;i="5.63,426,1557187200"; d="scan'208";a="497355963" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jun 2019 02:52:06 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5S2q5Bm028415 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Jun 2019 02:52:06 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 21:52:05 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 21:52:04 -0500 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 27 Jun 2019 21:52:04 -0500 ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=OtSVxzyifgTI/FJiQmkM15roDDUfQ91cFv4XX0DBPOxcatk46G4BojyJJHRfVzWud4904IdY3rz+Ff2zeRj7Ib90znhaZY668dL1Ii1WdHqDSN4KWwU/XHwH2frYfFkN/xOEFEnS0Ne/AtN+ueCNHjS/57b227lkZjaK1GDLQtE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EV+WBtweootY/FTrsR7XJe+9nYMe1sOtvYJoYpSH5rM=; b=sQy/4gycC1cx26EAmaxfOB0qLCWs7G8bX72IuDXEtXA43zWQKJXGdayHiHL7Apbjz52V+YqWuiJXht2vquxWbltNBKTvhEij3Vjo3ZeR7LM/SWhdnOnn2h9aVCUo+NBePZVIzOHa996vmSSQ2/mLSuGK7iVeeNwmIi3GLdNJcgc= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EV+WBtweootY/FTrsR7XJe+9nYMe1sOtvYJoYpSH5rM=; b=MeqZpK4Ev/M7bUxcKPQfZkpE/ZMPJApbnAtouVW/M5/4roN0WPC++52SsFcNM3Ind/sj4HmFO6aqd1ss+/ujFB1vZ8jRJSeaficcv5PFoGLjA2EoN4BCKpk5nW26v3MwaQJBmuU17RKbIld8QEgJmiT8N8iO8ZprNDv1pGaVWZ0= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.244.29) by BN7PR11MB2562.namprd11.prod.outlook.com (52.135.244.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Fri, 28 Jun 2019 02:52:03 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b1dc:fd0d:e540:67aa]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b1dc:fd0d:e540:67aa%7]) with mapi id 15.20.2008.018; Fri, 28 Jun 2019 02:52:03 +0000 From: "Panos Kampanakis (pkampana)" To: Benjamin Kaduk , The IESG CC: "spasm@ietf.org" , "housley@vigilsec.com" , "draft-ietf-lamps-pkix-shake@ietf.org" , "lamps-chairs@ietf.org" Thread-Topic: [lamps] Benjamin Kaduk's Yes on draft-ietf-lamps-pkix-shake-11: (with COMMENT) Thread-Index: AQHVKrxtDm2L1haLKkG9mQOvI++2lKawYTcw Date: Fri, 28 Jun 2019 02:52:03 +0000 Message-ID: References: <156140166968.17780.4781257860683054457.idtracker@ietfa.amsl.com> In-Reply-To: <156140166968.17780.4781257860683054457.idtracker@ietfa.amsl.com> 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=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1003::3db] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7ef5a1ce-d017-4d52-a33d-08d6fb7399a3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2562; x-ms-traffictypediagnostic: BN7PR11MB2562: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00826B6158 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(39860400002)(396003)(346002)(136003)(199004)(189003)(13464003)(5660300002)(53546011)(54906003)(186003)(102836004)(99286004)(76176011)(7696005)(11346002)(71200400001)(71190400001)(8936002)(256004)(6506007)(6246003)(229853002)(14444005)(110136005)(4326008)(2171002)(25786009)(66574012)(316002)(6306002)(53936002)(64756008)(2906002)(6116002)(52536014)(66476007)(66446008)(966005)(66946007)(66556008)(46003)(33656002)(9686003)(55016002)(14454004)(86362001)(305945005)(7736002)(81166006)(68736007)(8676002)(74316002)(81156014)(486006)(76116006)(478600001)(73956011)(446003)(6436002)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2562; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1mwVwlgJMKBlwLRdsS33tZSFy5i0Zc2/18z1sh443r05JpGBr9Vzp6lzAR4yk+JhWBkXBSU/UG8GBVAx57f8gKVTMMb9btYuQBBXN+BB5E5UXQQfTda/EKz9raxNAogZuJVLzxuIxNgHFlx7DvotIRc93xPoSpBH33hwA8fV041k3I05aeVnJ0S6whVC4o2j8EEdEcDCAFeeHCIrOcTQg7N9MEufU5FsL8tess/VzA5NOzdcM0r2fxVOU4cyi2Ba6qcnIhaT0hU2ztu9eQGS0myGCYLNmFpJVbX+cyVsarGSlsOzOvlR/i0V2ItyjHYQ6JBNd+5SwYNQGl92FZ1TRg88AfFBUcZHAW1Q1pixHhEQ4CieJFdCo0GjVV4TOhQJpCp767uKS+AKp1HKngw0IzTTrxJ8dRnXBPjvROnzqpo= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7ef5a1ce-d017-4d52-a33d-08d6fb7399a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2019 02:52:03.4914 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkampana@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2562 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Yes on draft-ietf-lamps-pkix-shake-11: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 02:52:10 -0000 Hi Ben, Then you for the review.=20 I addressed all your comments. The details and the language used are descri= bed in the git issue https://github.com/csosto-pk/adding-shake-to-pkix/issu= es/47#issuecomment-505640399 And the actual updates are in https://github.c= om/csosto-pk/adding-shake-to-pkix/commit/1f056710eea828a4f2cfd8f349563a4b1a= 5af85a Please check them out to see if they look OK.=20 I am planning to reupload the draft tomorrow or Monday.=20 Thanks, Panos=20 -----Original Message----- From: Spasm On Behalf Of Benjamin Kaduk via Datatr= acker Sent: Monday, June 24, 2019 2:41 PM To: The IESG Cc: spasm@ietf.org; housley@vigilsec.com; draft-ietf-lamps-pkix-shake@ietf.= org; lamps-chairs@ietf.org Subject: [lamps] Benjamin Kaduk's Yes on draft-ietf-lamps-pkix-shake-11: (w= ith COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-pkix-shake-11: Yes 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 introduc= tory 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-pkix-shake/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document; I only have editorial-nit-level comments. Section 2 This document describes cryptographic algorithm identifiers for several cryptographic algorithms which use variable length output SHAKE functions introduced in [SHA3] which can be used with the Internet X.509 Certificate and CRL profile [RFC5280]. nit(?): Is "describes" or "defines" more appropriate? (Given that NIST has= already allocated some of the OIDs in question, I could go either way.) I'= d also suggest further rewording, perhaps as: This document defines cryptographic algorithm identifiers for several cryptographic algorithms that use the variable length output SHAKE functions introduced in [SHA3]; these algorithms can be used with the Internet X.509 Certificate and CRL profile [RFC5280]. -- This specification describes the identifiers for SHAKEs to be used in X.509 and their meaning. nit: this seems pretty redundant with the first paragraph of the section. Section 5.1 Signatures are used in a number of different ASN.1 structures. As shown in the ASN.1 representation from [RFC5280] below, an X.509 certificate a signature is encoded with an algorithm identifier in the signatureAlgorithm attribute and a signatureValue attribute that contains the actual signature. nit: "an X.509 certificate a signature is encoded" is not grammatical; I th= ink there's a missing "in" at the start? The identifiers defined in Section 4 can be used as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence Certificate and the signature field in the sequence tbsCertificate in X.509 [RFC5280]. [...] nit: I'm a bit confused by the usage "sequence tbsCertificate" -- the name = of the ASN.1 SEQUENCE is TBSCertificate, with tbsCertificate reflecting the= field name for this sequence as it appears in the Certificate. (Contrariw= ise, "the sequence Certificate" makes sense to me, as that is the type name= of an ASN.1 SEQUENCE.) I do note that the sentence "This field MUST conta= in the same algorithm identifier as the signature field in the sequence tbs= Certificate (Section 4.1.2.3" appears in RFC 5280, which includes the same = phrasing. Section 5.1.1 The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 4 is used, the encoding MUST omit the parameters field. [...] Is this requirement redundant with the one in Section 4? (Similarly in Section 5.1.2.) The hash algorithm to hash a message being signed and the hash algorithm as the mask generation function used in RSASSA-PSS MUST be the same, SHAKE128 or SHAKE256 respectively. [...] nit: I think just "as" is not the right grammar, here, and we want "used as= " instead. SHAKE128 and id-RSASSA-PSS-SHAKE256 respectively. The mgfSeed is the seed from which mask is generated, an octet string [RFC8017]. As explained in Step 9 of section 9.1.1 of [RFC8017], the output length of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256 respectively. Thus when SHAKE is used as the MGF, the SHAKE output length maskLen is (n - 264) or (n - 520) bits respectively. For example, when RSA modulus n is 2048, the output length of SHAKE128 or SHAKE256 as the MGF will be 1784 or 1528-bits when id-RSASSA-PSS- SHAKE128 or id-RSASSA-PSS-SHAKE256 is used respectively. nit: Absent some external requirement for the RSA modulus to be a multiple = of 8 bits (that I have forgotten about), it seems we need to be more carefu= l about transtioning from the byte length of the MGF output to the bit leng= th of SHAKE output needed, as the ceil() function will vary with the modulu= s of n base 8. Section 5.2 is an OID and optionally associated parameters. The conventions and encoding for RSASSA-PSS and ECDSA public keys algorithm identifiers are as specified in Section 2.3 of [RFC3279], Section 3.1 of [RFC4055] and Section 2.1 of [RFC5480]. I think this might be better if it calls out sections 2.3.1 and 2.3.5 of RF= C 3279 explicitly rather than globbing in a bunch of unrelated subsections. The identifier parameters, as explained in Section 4, MUST be absent. This feels like the fourth time we've said that parameters are absent... Appendix A nit: Does "Deterministic" need to be in the comments for the ECDSA smime ca= pabilities? It's not really something the peer can verify. _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Jun 28 09:34:59 2019 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 56076120368 for ; Fri, 28 Jun 2019 09:34:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 BlGVFYkIjsR2 for ; Fri, 28 Jun 2019 09:34:50 -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 1444112036F for ; Fri, 28 Jun 2019 09:34:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0EA8B300ABC for ; Fri, 28 Jun 2019 12:15:26 -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 QLzo4vuvHUZH for ; Fri, 28 Jun 2019 12:15:24 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id E438C3004A7; Fri, 28 Jun 2019 12:15:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <20190628002208.GQ18345@kduck.mit.edu> Date: Fri, 28 Jun 2019 12:34:40 -0400 Cc: SPASM , IESG Content-Transfer-Encoding: quoted-printable Message-Id: <280BF6C9-193D-4563-AE69-11E71C5E2282@vigilsec.com> References: <155916984601.5535.15415810479866156115.idtracker@ietfa.amsl.com> <83521276-738B-4298-A36D-B3C04E11A05C@vigilsec.com> <20190614212637.GV52381@kduck.mit.edu> <20190628002208.GQ18345@kduck.mit.edu> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 16:34:52 -0000 Ben: Dropping parts where we have reached agreement ... >>>>>> = ---------------------------------------------------------------------- >>>>>> DISCUSS: >>>>>> = ---------------------------------------------------------------------- >=20 >> I propose to replace the paragraph after that with one that handles = the non-repository case and points out that the Wen PKI falls in that = case. See below. >>=20 >>>>> The id-ad-caRepository OID is used when the subject is a CA that >>>>> publishes certificates it issues in a repository. The = accessLocation >>>>> field is defined as a GeneralName, which can take several forms. >>>>>=20 >>>>> ... >>>>>=20 >>>>> Where the information is available via HTTP or FTP, accessLocation >>>>> MUST be a uniformResourceIdentifier and the URI MUST point to = either >>>>> a single DER encoded certificate as specified in [RFC2585] or a >>>>> collection of certificates in a BER or DER encoded "certs-only" = CMS >>>>> message as specified in [RFC2797]. >>>>>=20 >>>>> I am willing to RECOMMEND the inclusion of this extension and = posting the oldWithNew and newWithOld so that they can be fetched using = the "certs-only" (simple PKI response). This format would allow = certificates to be added and removed from the bag of certificates over = time. >>>=20 >>> That does seem worth doing. >>>=20 >>> I think what would best help move the document forward right now = would be >>> for you to point me at the existing text that is "fairly clear that = there >>> can be some failure if there is not a repository or directory = service.", >>> since I seem to have missed it. Text that matches that description = should >>> be enough to resolve the Discuss point -- we don't need to bend over >>> backwards to satisfy the Web PKI case when the mechanism works fine = as-is >>> in other use cases. >>=20 >> Here is the proposed text for the non-repository case. The first = paragraph offers guidance to the Root CA, and the next one offers = guidance to recipients: >>=20 >> In environments without such a directory service or repository, = like >> the Web PKI, recipients need a way to obtain the oldWithNew and >> newWithOld certificates. The Root CA SHOULD include the subject >> information access extension [RFC5280] with the accessMethod set to >> id-ad-caRepository and the assessLocation set to the HTTP URL that >> can be used to fetch a DER-encoded "certs-only" (simple PKI = response) >> message as specified in [RFC5272]. The Root CA SHOULD post the >> "certs-only" message with the oldWithNew certificate and the >> newWithOld certificate before the current Root CA self-signed >> certificate is released. The "certs-only" message format allows >=20 > I might be confused, but if "the current Root CA self-signed = certificate is > released" means that people are using the current root, then this = doesn't > seem to make much sense -- that requires using the next key to sign > OldWithNew before the current key is usable, which seems counter to = the > point of the flow here. So I think this maybe was supposed to be > "successor" instead of "current"? You are not confused. The original self-signed certificate and the = successor self-signed certificate should contain the same URL for the = "certs-only" message. This way, a replying party will find the = certificate that is needed no matter which trust anchor they are using. = So, yes, you are right the update the "certs-only" message should happen = before the successor self-signed certificate is released. Here is the = corrected text: In environments without such a directory service or repository, like the Web PKI, recipients need a way to obtain the oldWithNew and newWithOld certificates. The Root CA SHOULD include the subject information access extension [RFC5280] with the accessMethod set to id-ad-caRepository and the assessLocation set to the HTTP URL that can be used to fetch a DER-encoded "certs-only" (simple PKI response) message as specified in [RFC5272] in all of their self-signed certificates. The Root CA SHOULD publish the "certs-only" message with the oldWithNew certificate and the newWithOld certificate before the subsequent Root CA self-signed certificate is released. The "certs-only" message format allows certificates to be added and removed from the bag of certificates over time, so the same HTTP URL can be used throughout the lifetime of the Root CA. >> certificates to be added and removed from the bag of certificates >> over time, so the same HTTP URL can be used throughout the lifetime >> of the Root CA. >>=20 >> In environments without such a directory service or repository, >> recipients SHOULD keep both the old and replacement Root CA self- >> signed certificates in the trust anchor store for some amount of = time >> to ensure that all end-entity certificates can be validated until >> they expire. The recipient MAY keep the old Root CA self-signed >> certificate until all of the certificates in the local cache that = are >> subordinate to it have expired. >=20 > Modulo the above comment, this should be enough to resolve the = Discuss. I believe that is sorted by the above text. > I think I'm still left a bit unsatisfied by the document since I don't = get > a clear picture of what roles "recipients" take. Presumably this is = to > some extent intentional, so as to be relevant in many use cases and = not > have to finesse distinctions such as the Web PKI's TLS client and > end-entity server, but my current understanding still includes = different > recipients using the root CA for different purposes and getting it in > different ways, and there's something of an impedance mismatch between = the > text of the document and my understanding. I admit the possibility = that > the document is fine and my understanding wrong, so I don't want to = stand > in the way of the document moving forward. There are many ways that the successor self-signed certificate might = "become available" (the words used in the Introduction). A protocol = could be used to push it out, or the recipient could simply process a = certification path that includes it. Flexibility is intentional; the = answer may be very different in a private PKI and the Web PKI. The = experimental RFC specifying the syntax of the extension should not need = to cover all of the possible use cases. Russ From nobody Fri Jun 28 09:57:21 2019 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 7F6DD12049A; Fri, 28 Jun 2019 09:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jOsgXXG6YEZ; Fri, 28 Jun 2019 09:57:16 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2A7120485; Fri, 28 Jun 2019 09:57:09 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5SGv4TQ012222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Jun 2019 12:57:06 -0400 Date: Fri, 28 Jun 2019 11:57:03 -0500 From: Benjamin Kaduk To: Russ Housley Cc: SPASM , IESG Message-ID: <20190628165703.GB18345@kduck.mit.edu> References: <155916984601.5535.15415810479866156115.idtracker@ietfa.amsl.com> <83521276-738B-4298-A36D-B3C04E11A05C@vigilsec.com> <20190614212637.GV52381@kduck.mit.edu> <20190628002208.GQ18345@kduck.mit.edu> <280BF6C9-193D-4563-AE69-11E71C5E2282@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <280BF6C9-193D-4563-AE69-11E71C5E2282@vigilsec.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 16:57:20 -0000 On Fri, Jun 28, 2019 at 12:34:40PM -0400, Russ Housley wrote: > Ben: > > Dropping parts where we have reached agreement ... > > > >>>>>> ---------------------------------------------------------------------- > >>>>>> DISCUSS: > >>>>>> ---------------------------------------------------------------------- > > > >> I propose to replace the paragraph after that with one that handles the non-repository case and points out that the Wen PKI falls in that case. See below. > >> > >>>>> The id-ad-caRepository OID is used when the subject is a CA that > >>>>> publishes certificates it issues in a repository. The accessLocation > >>>>> field is defined as a GeneralName, which can take several forms. > >>>>> > >>>>> ... > >>>>> > >>>>> Where the information is available via HTTP or FTP, accessLocation > >>>>> MUST be a uniformResourceIdentifier and the URI MUST point to either > >>>>> a single DER encoded certificate as specified in [RFC2585] or a > >>>>> collection of certificates in a BER or DER encoded "certs-only" CMS > >>>>> message as specified in [RFC2797]. > >>>>> > >>>>> I am willing to RECOMMEND the inclusion of this extension and posting the oldWithNew and newWithOld so that they can be fetched using the "certs-only" (simple PKI response). This format would allow certificates to be added and removed from the bag of certificates over time. > >>> > >>> That does seem worth doing. > >>> > >>> I think what would best help move the document forward right now would be > >>> for you to point me at the existing text that is "fairly clear that there > >>> can be some failure if there is not a repository or directory service.", > >>> since I seem to have missed it. Text that matches that description should > >>> be enough to resolve the Discuss point -- we don't need to bend over > >>> backwards to satisfy the Web PKI case when the mechanism works fine as-is > >>> in other use cases. > >> > >> Here is the proposed text for the non-repository case. The first paragraph offers guidance to the Root CA, and the next one offers guidance to recipients: > >> > >> In environments without such a directory service or repository, like > >> the Web PKI, recipients need a way to obtain the oldWithNew and > >> newWithOld certificates. The Root CA SHOULD include the subject > >> information access extension [RFC5280] with the accessMethod set to > >> id-ad-caRepository and the assessLocation set to the HTTP URL that > >> can be used to fetch a DER-encoded "certs-only" (simple PKI response) > >> message as specified in [RFC5272]. The Root CA SHOULD post the > >> "certs-only" message with the oldWithNew certificate and the > >> newWithOld certificate before the current Root CA self-signed > >> certificate is released. The "certs-only" message format allows > > > > I might be confused, but if "the current Root CA self-signed certificate is > > released" means that people are using the current root, then this doesn't > > seem to make much sense -- that requires using the next key to sign > > OldWithNew before the current key is usable, which seems counter to the > > point of the flow here. So I think this maybe was supposed to be > > "successor" instead of "current"? > > You are not confused. The original self-signed certificate and the successor self-signed certificate should contain the same URL for the "certs-only" message. This way, a replying party will find the certificate that is needed no matter which trust anchor they are using. So, yes, you are right the update the "certs-only" message should happen before the successor self-signed certificate is released. Here is the corrected text: > > In environments without such a directory service or repository, like > the Web PKI, recipients need a way to obtain the oldWithNew and > newWithOld certificates. The Root CA SHOULD include the subject > information access extension [RFC5280] with the accessMethod set to > id-ad-caRepository and the assessLocation set to the HTTP URL that > can be used to fetch a DER-encoded "certs-only" (simple PKI response) > message as specified in [RFC5272] in all of their self-signed > certificates. The Root CA SHOULD publish the "certs-only" message > with the oldWithNew certificate and the newWithOld certificate before > the subsequent Root CA self-signed certificate is released. The > "certs-only" message format allows certificates to be added and > removed from the bag of certificates over time, so the same HTTP URL > can be used throughout the lifetime of the Root CA. > > >> certificates to be added and removed from the bag of certificates > >> over time, so the same HTTP URL can be used throughout the lifetime > >> of the Root CA. > >> > >> In environments without such a directory service or repository, > >> recipients SHOULD keep both the old and replacement Root CA self- > >> signed certificates in the trust anchor store for some amount of time > >> to ensure that all end-entity certificates can be validated until > >> they expire. The recipient MAY keep the old Root CA self-signed > >> certificate until all of the certificates in the local cache that are > >> subordinate to it have expired. > > > > Modulo the above comment, this should be enough to resolve the Discuss. > > I believe that is sorted by the above text. I do, too -- thanks. > > I think I'm still left a bit unsatisfied by the document since I don't get > > a clear picture of what roles "recipients" take. Presumably this is to > > some extent intentional, so as to be relevant in many use cases and not > > have to finesse distinctions such as the Web PKI's TLS client and > > end-entity server, but my current understanding still includes different > > recipients using the root CA for different purposes and getting it in > > different ways, and there's something of an impedance mismatch between the > > text of the document and my understanding. I admit the possibility that > > the document is fine and my understanding wrong, so I don't want to stand > > in the way of the document moving forward. > > There are many ways that the successor self-signed certificate might "become available" (the words used in the Introduction). A protocol could be used to push it out, or the recipient could simply process a certification path that includes it. Flexibility is intentional; the answer may be very different in a private PKI and the Web PKI. The experimental RFC specifying the syntax of the extension should not need to cover all of the possible use cases. All true. Let's move forward with this, then -- please publish the new rev and I can clear. -Ben From nobody Fri Jun 28 10:43:35 2019 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 E8D06120351; Fri, 28 Jun 2019 10:43:25 -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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <156174380586.20692.14839489553696728709@ietfa.amsl.com> Date: Fri, 28 Jun 2019 10:43:25 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-hash-of-root-key-cert-extn-06.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 17:43:26 -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 : Hash Of Root Key Certificate Extension Author : Russ Housley Filename : draft-ietf-lamps-hash-of-root-key-cert-extn-06.txt Pages : 11 Date : 2019-06-28 Abstract: This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, eventually replacing the current one. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-06 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-hash-of-root-key-cert-extn-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-hash-of-root-key-cert-extn-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 28 10:45:04 2019 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 84DB112000E for ; Fri, 28 Jun 2019 10:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 YaFbPeD0URp7 for ; Fri, 28 Jun 2019 10:44:53 -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 BD4F6120351 for ; Fri, 28 Jun 2019 10:44:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C1A14300AEE for ; Fri, 28 Jun 2019 13:25:35 -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 C3UmuHPGZKuF for ; Fri, 28 Jun 2019 13:25:34 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id BC7DD300596; Fri, 28 Jun 2019 13:25:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <20190628165703.GB18345@kduck.mit.edu> Date: Fri, 28 Jun 2019 13:44:49 -0400 Cc: SPASM , IESG Content-Transfer-Encoding: 7bit Message-Id: <0E302B69-FB03-458B-973C-2D5CA3541EA1@vigilsec.com> References: <155916984601.5535.15415810479866156115.idtracker@ietfa.amsl.com> <83521276-738B-4298-A36D-B3C04E11A05C@vigilsec.com> <20190614212637.GV52381@kduck.mit.edu> <20190628002208.GQ18345@kduck.mit.edu> <280BF6C9-193D-4563-AE69-11E71C5E2282@vigilsec.com> <20190628165703.GB18345@kduck.mit.edu> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 17:44:57 -0000 Ben: > Let's move forward with this, then -- please publish the new rev > and I can clear. Done. https://www.ietf.org/id/draft-ietf-lamps-hash-of-root-key-cert-extn-06.txt Russ From nobody Fri Jun 28 15:59:58 2019 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 302FB120973; Fri, 28 Jun 2019 15:57:53 -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, rdd@cert.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176267318.11015.5251991405919774230.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:57:53 -0700 Archived-At: Subject: [lamps] lamps - Requested session has been scheduled for IETF 105 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 22:58:00 -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:30 requested) Tuesday, 23 July 2019, Afternoon Session I 1330-1500 Room Name: Van Horne size: 130 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/lamps.ics 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.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: suit curdle quic perc saag sidrops sipbrandy mls tls ipwave stir acme ace rtcweb secdispatch teep Second Priority: cfrg dprive oauth t2trg uta ipsecme Third Priority: mile sacm secevent tcpinc trans People who must be present: Russ Housley Sean Turner Alexey Melnikov Roman Danyliw Jim Schaad Tim Hollebeek Resources Requested: Special Requests: Due to travel to a family wedding, please do not schedule this session for Friday. --------------------------------------------------------- From nobody Fri Jun 28 18:24:37 2019 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 3F949120977; Fri, 28 Jun 2019 18:24:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, Tim Hollebeek , lamps-chairs@ietf.org, tim.hollebeek@digicert.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156177146925.11075.2248188871860632974.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 18:24:29 -0700 Archived-At: Subject: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-hash-of-root-key-cert-extn-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jun 2019 01:24:29 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-hash-of-root-key-cert-extn-06: 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-hash-of-root-key-cert-extn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss (and Comment) points! It looks like the ASN.1 module changes from the -05 to the -06 left a stale definition of HashAlgorithmId (but if it is not stale then the import of DIGEST-ALGORITHM would need to be restored). From nobody Sat Jun 29 07:06:21 2019 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 76D62120041 for ; Sat, 29 Jun 2019 07:06:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 FJsYk2ETQObT for ; Sat, 29 Jun 2019 07:06:12 -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 068B4120033 for ; Sat, 29 Jun 2019 07:06:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 91709300AEE for ; Sat, 29 Jun 2019 09:46:53 -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 oz2HwxYMMlyp for ; Sat, 29 Jun 2019 09:46:52 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 696953001A7; Sat, 29 Jun 2019 09:46:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <156177146925.11075.2248188871860632974.idtracker@ietfa.amsl.com> Date: Sat, 29 Jun 2019 10:06:09 -0400 Cc: IESG , SPASM Content-Transfer-Encoding: quoted-printable Message-Id: References: <156177146925.11075.2248188871860632974.idtracker@ietfa.amsl.com> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-hash-of-root-key-cert-extn-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jun 2019 14:06:15 -0000 Ben: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for addressing my Discuss (and Comment) points! >=20 > It looks like the ASN.1 module changes from the -05 to the -06 > left a stale definition of HashAlgorithmId (but if it is not stale > then the import of DIGEST-ALGORITHM would need to be restored). Good catch! I removed that line from the module when I compiled it, but = I guess I forgot to take it out of the Internet-Draft. I will do that = now. Russ From nobody Sat Jun 29 07:09:53 2019 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 9334212000E; Sat, 29 Jun 2019 07:09:45 -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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <156181738552.12874.18262032149692248477@ietfa.amsl.com> Date: Sat, 29 Jun 2019 07:09:45 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-hash-of-root-key-cert-extn-07.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jun 2019 14:09:46 -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 : Hash Of Root Key Certificate Extension Author : Russ Housley Filename : draft-ietf-lamps-hash-of-root-key-cert-extn-07.txt Pages : 11 Date : 2019-06-29 Abstract: This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, eventually replacing the current one. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-hash-of-root-key-cert-extn-07 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-hash-of-root-key-cert-extn-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-hash-of-root-key-cert-extn-07 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 Sun Jun 30 21:00:42 2019 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 9B1DE1201F0; Sun, 30 Jun 2019 21:00:19 -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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <156195361959.21990.15074710691896847079@ietfa.amsl.com> Date: Sun, 30 Jun 2019 21:00:19 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-12.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 01 Jul 2019 04:00:20 -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 : Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS) Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-cms-shakes-12.txt Pages : 17 Date : 2019-06-30 Abstract: This document updates [RFC3370] and describes the conventions for using the SHAKE family of hash functions with the Cryptographic Message Syntax (CMS) as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms, as message digests and message authentication codes. The conventions for the associated signer public keys in CMS are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-12 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-shakes-12 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 Sun Jun 30 21:01:07 2019 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 B676512019D; Sun, 30 Jun 2019 21:01:05 -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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <156195366570.22233.11713837851262829718@ietfa.amsl.com> Date: Sun, 30 Jun 2019 21:01:05 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-12.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 01 Jul 2019 04:01:06 -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 : Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-pkix-shake-12.txt Pages : 16 Date : 2019-06-30 Abstract: Digital signatures are used to sign messages, X.509 certificates and CRLs. This document updates [RFC3279] and describes the conventions for using the SHAKE function family in Internet X.509 certificates and CRLs as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated subject public keys are also described. 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-12 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-pkix-shake-12 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 Sun Jun 30 21:10:31 2019 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 9741A1201F1 for ; Sun, 30 Jun 2019 21:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 header.b=HmOp1yYU; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=o/2hHmBU 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 fj3PVrlSfv5X for ; Sun, 30 Jun 2019 21:10:27 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ADF812019D for ; Sun, 30 Jun 2019 21:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2490; q=dns/txt; s=iport; t=1561954227; x=1563163827; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cLGAeASf9zkG4Iqh1k75PARdPDwKrBi3VLeOHttVztc=; b=HmOp1yYU/0JgLnjBDzDySyLd33suqG3bSpIJ3v2kK+Ubh8zsvhrABSjk M1u4i9MN8CXMDtKjyNI5SfFX4bPVdmwhysdOmFwdNH9D9mP1H/n9LN9wo sjTaSiyRyJSZe6dPkgD0qGh0GBwam6+bXkm7FLCueujGBdqkxJj0u+djv 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AEPMwLRA4ATRLD/undBEzUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNP3jajQzGs1qX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAAD8hhld/5tdJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwcBAQsBgUNQA2pVIAQLKIdkA4RSigxMgg+XRIEugSQDVAkBAQEMAQE?= =?us-ascii?q?YCwoCAQGEQAKDACM0CQ4BAwEBBAEBAgEFbYo3AQuFSgEBAQEDAQEQKAYBASw?= =?us-ascii?q?MCwQCAQgRBAEBHgEQJwsdCAIEEwgagwGBagMdAQIMmDcCgTiIYIIjgnkBAQW?= =?us-ascii?q?BNgIOQYMFGIIRCYE0AYteF4FAP4ERRoJMPoJhAQECAQEWgSApgzqCJqozCQK?= =?us-ascii?q?CFoZTjUKCK2yGL44jjTCHOYwfg0sCBAIEBQIOAQEFgVA4gVhwFRohgmwJgjg?= =?us-ascii?q?LGINOhRSFP3KBKYs4glIBAQ?= X-IronPort-AV: E=Sophos;i="5.63,437,1557187200"; d="scan'208";a="585282908" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Jul 2019 04:10:26 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x614AQw2021124 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 1 Jul 2019 04:10:26 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 30 Jun 2019 23:10:25 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 1 Jul 2019 00:10:24 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 30 Jun 2019 23:10:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SR+liY3/SlKExrUkrs38TeMNSz1PmxNTCCz03fg2A5Y=; b=o/2hHmBUZ0emFMvRh8DPvow7/d2e7kLMpovFTG/chOA/2vI2wdv5h/9rCBiUyBdGC7kC/gpOHXgZtbSlnn56iUh8EKObUa9pArkGpMIXkMy/p/AP+FG4I/JH5Y1oWpJKvgAi4cWXDMauTqcR8CW2GpdOineTbxMJhEQSiGd1lnU= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.244.29) by BN7PR11MB2577.namprd11.prod.outlook.com (52.135.244.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.18; Mon, 1 Jul 2019 04:10:23 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b1dc:fd0d:e540:67aa]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b1dc:fd0d:e540:67aa%7]) with mapi id 15.20.2032.019; Mon, 1 Jul 2019 04:10:23 +0000 From: "Panos Kampanakis (pkampana)" To: "spasm@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-12.txt Thread-Index: AQHVL8GoFexzPdKicUGJL0ARC9gV+aa1JLOQ Date: Mon, 1 Jul 2019 04:10:23 +0000 Message-ID: References: <156195366570.22233.11713837851262829718@ietfa.amsl.com> In-Reply-To: <156195366570.22233.11713837851262829718@ietfa.amsl.com> 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=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1005::f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 016258ec-5360-4989-21c3-08d6fdda0a44 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2577; x-ms-traffictypediagnostic: BN7PR11MB2577: x-ms-exchange-purlcount: 8 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 00851CA28B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(39860400002)(346002)(366004)(376002)(13464003)(189003)(199004)(53754006)(54164003)(55016002)(14454004)(5660300002)(33656002)(966005)(7696005)(9686003)(71200400001)(6916009)(305945005)(74316002)(256004)(66476007)(6436002)(66446008)(66946007)(316002)(6306002)(229853002)(52536014)(71190400001)(76176011)(2501003)(66556008)(64756008)(2351001)(53936002)(46003)(66574012)(73956011)(7736002)(81166006)(81156014)(1730700003)(6506007)(478600001)(5640700003)(68736007)(53546011)(76116006)(8676002)(2906002)(486006)(6246003)(102836004)(446003)(11346002)(86362001)(476003)(25786009)(8936002)(99286004)(6116002)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2577; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Awx9389wEf9Q8TDPoWHHNNw3+WrcwfYVLf4Bt2haLQ+qO3NBTjawAxYhBWj0kgK3FbTAVI1hSz4ccoLiwWI69BZhyZTmrZQGjLpenoUcUjIonxa65ddZsQuvRzSvs4Wy2g35iYrHvOo5qSwYCNXY5ZFx59Ob+ssoubAMiPh2Uk3Ser8+WoRu4UaKrpubxkGTGjqB19kUN9JmSCl9nopGkD7kjTeVO0UaGsOgUB2hJ3rj9hn8MQ5Td+i73jRDv0zu59G1X5+RWsYZPtVVr4Mb0MFSHMc5hd+7Tn+jnw7ZvplQSgBigBizHwFWdXIkhaP3GD31lkk37LCD+fJR1Tn0Yglkd0zYUAKjpguXzvhYL4997Ma/3WuWMaKI47LNiKzBRTJCIkUWxkYkk1TtsqnIXFdRHru0wRqveE95fyNRLns= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 016258ec-5360-4989-21c3-08d6fdda0a44 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2019 04:10:23.4759 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkampana@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2577 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-12.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 01 Jul 2019 04:10:30 -0000 Hi all,=20 This iteration addresses ballot review feedback from Ben, Eric, Barry and A= dam. The feedbacks and updates are tracked in https://github.com/csosto-pk/= adding-shake-to-pkix/issues/46 , https://github.com/csosto-pk/adding-shake-= to-pkix/issues/47 and https://github.com/csosto-pk/adding-shake-to-pkix/iss= ues/48=20 Diff is here https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-pkix-shak= e-12=20 Thanks to all reviewing thoroughly.=20 Rgs, Panos -----Original Message----- From: Spasm On Behalf Of internet-drafts@ietf.org Sent: Monday, July 01, 2019 12:01 AM To: i-d-announce@ietf.org Cc: spasm@ietf.org Subject: [lamps] I-D Action: draft-ietf-lamps-pkix-shake-12.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 : Internet X.509 Public Key Infrastructure: Additio= nal Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-pkix-shake-12.txt Pages : 16 Date : 2019-06-30 Abstract: Digital signatures are used to sign messages, X.509 certificates and CRLs. This document updates [RFC3279] and describes the conventions for using the SHAKE function family in Internet X.509 certificates and CRLs as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated subject public keys are also described. 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-12 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pkix-shake-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-pkix-shake-12 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 From nobody Sun Jun 30 21:10:39 2019 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 023D012019D for ; Sun, 30 Jun 2019 21:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, 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 header.b=eMG+miNg; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OBy32tpW 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 73kYdT88pyd0 for ; Sun, 30 Jun 2019 21:10:28 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBEE1201F0 for ; Sun, 30 Jun 2019 21:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2457; q=dns/txt; s=iport; t=1561954227; x=1563163827; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=JvQidodTJgBrXXtX9m+KaTXjfSype5vg+8ZXxTt2Yk8=; b=eMG+miNgy2G4OvBGbJnPbtaYEPWh1kPs4vCFj2uPO/3Ola9yGWoVfTcm L+rvh6XMhGGRgh/jHXAp1h8bnV2B+ROLoy1Dw+0DN/U59xxkRaZyisSqo 3s25fohjv4slAN21uNRvaQpei8QkdhwJgq8U7WYKBL/FtlH7Mfl+w9QQ2 k=; IronPort-PHdr: =?us-ascii?q?9a23=3AmGdBDRc0ymXiQkpYJRms1wmYlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dy8zGdxLUlZN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAAD8hhld/4UNJK1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwcBAQsBgUNQA2pVIAQLKIdkA4RSigxMgg+XRIEugSQDVAkBAQEMAQE?= =?us-ascii?q?YCwoCAQGEQAKDACM0CQ4BAwEBBAEBAgEFbYo3AQuFSgEBAQEDAQEQKAYBASw?= =?us-ascii?q?MCwQCAQgRBAEBHgEQJwsdCAIEEwgagwGBagMdAQIMmDcCgTiIYIIjgnkBAQW?= =?us-ascii?q?BNgIOQYMFGIIRCYE0AYteF4FAP4ERRoJMPoJhAQECAQEWgSApgzqCJqozCQK?= =?us-ascii?q?CFoZTjUKCK2yGL44jjTCHOYwfg0sCBAIEBQIOAQEFgVA4gVhwFRohgmwJgjg?= =?us-ascii?q?LGINOhRSFP3KBKYs4glIBAQ?= X-IronPort-AV: E=Sophos;i="5.63,437,1557187200"; d="scan'208";a="580720052" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Jul 2019 04:10:26 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x614AQ5t002589 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 1 Jul 2019 04:10:26 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 30 Jun 2019 23:10:26 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 30 Jun 2019 23:10:25 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 30 Jun 2019 23:10:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SSySVqrl+aAnsKy89A904Y2ZNDeVYQmhgOYbK9TOPBY=; b=OBy32tpWd9P4gYkk64W3o2l1ItzMlcw4EWyS4D4oDFiBMOONPdjYmRhxlRHD3TT56hCUoxJR/Ig3F4R9f4l5cRH8Uy/woNB7E14LEIjOhuMHKZSGbcVxi6kXrZUEXP0JU37D8/oehrmBf/QmrQQeR0YfEPagNPl+uUWPVXZgR8g= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.244.29) by BN7PR11MB2577.namprd11.prod.outlook.com (52.135.244.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.18; Mon, 1 Jul 2019 04:10:24 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b1dc:fd0d:e540:67aa]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b1dc:fd0d:e540:67aa%7]) with mapi id 15.20.2032.019; Mon, 1 Jul 2019 04:10:24 +0000 From: "Panos Kampanakis (pkampana)" To: "spasm@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-12.txt Thread-Index: AQHVL8GfpkEBl3vjYk+TG6u1wl5yQaa1JImQ Date: Mon, 1 Jul 2019 04:10:24 +0000 Message-ID: References: <156195361959.21990.15074710691896847079@ietfa.amsl.com> In-Reply-To: <156195361959.21990.15074710691896847079@ietfa.amsl.com> 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=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1005::f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cf00db46-ec83-422f-f64c-08d6fdda0abf x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2577; x-ms-traffictypediagnostic: BN7PR11MB2577: x-ms-exchange-purlcount: 8 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 00851CA28B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(39860400002)(346002)(366004)(376002)(13464003)(189003)(199004)(53754006)(54164003)(55016002)(14454004)(5660300002)(33656002)(966005)(7696005)(9686003)(71200400001)(6916009)(305945005)(74316002)(256004)(66476007)(6436002)(66446008)(66946007)(316002)(6306002)(229853002)(52536014)(71190400001)(76176011)(2501003)(66556008)(64756008)(2351001)(53936002)(46003)(66574012)(73956011)(7736002)(81166006)(81156014)(1730700003)(6506007)(478600001)(5640700003)(68736007)(53546011)(76116006)(8676002)(2906002)(486006)(6246003)(102836004)(446003)(11346002)(86362001)(476003)(25786009)(8936002)(99286004)(6116002)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2577; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EIrCCLwOvqUIURdLd6d0LBeHqast7cOZ6yg4uziVuBvlkkniPWggoToOQZ6GGig1kYgsnb/IadAugBFDzi/D21M5q4l+Bmqu53tQqUmYnnqJWgXj8JO11BrJOY7Xsl6Y9Ar74SW+SNvjN21892TsaSG0t4RUyAhHlLVhA+h/xmwqJBvGcKBySLZSef22zChrFf3heBktKew+9z8OXmL+vRISOgxw2qSQCdMGdf9vQuFgtOGUaWewMAv5TGO77zz7/E3og6EtWr+4BYxC+AlfMft8smQ0umnYtO4LoWd7IlcmtgT66L5/yuOZzvH+E0tqanPD+V6M0cFKgsQkRNdWACjiMxNjukwlZ6gl4POZbFpFe4nAHQIAq0k9XXBt6tNs2Gde6QmbSILsDkovqHuVJp2OUvV4MPnOq4q5Py+zyBQ= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cf00db46-ec83-422f-f64c-08d6fdda0abf X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2019 04:10:24.3335 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkampana@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2577 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-12.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 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, 01 Jul 2019 04:10:31 -0000 Hi all,=20 This iteration addresses ballot review feedback from Ben, Eric, Barry and A= dam. The feedbacks and updates are tracked in https://github.com/csosto-pk/= adding-shake-to-pkix/issues/46 , https://github.com/csosto-pk/adding-shake-= to-pkix/issues/47 and https://github.com/csosto-pk/adding-shake-to-pkix/iss= ues/48=20 Diff is here https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-shake= s-12=20 Thanks to all reviewing thoroughly.=20 Rgs, Panos -----Original Message----- From: Spasm On Behalf Of internet-drafts@ietf.org Sent: Monday, July 01, 2019 12:00 AM To: i-d-announce@ietf.org Cc: spasm@ietf.org Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-12.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 : Use of the SHAKE One-way Hash Functions in the Cr= yptographic Message Syntax (CMS) Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-cms-shakes-12.txt Pages : 17 Date : 2019-06-30 Abstract: This document updates [RFC3370] and describes the conventions for using the SHAKE family of hash functions with the Cryptographic Message Syntax (CMS) as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms, as message digests and message authentication codes. The conventions for the associated signer public keys in CMS are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-12 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-shakes-12 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