From nobody Mon Jul 10 08:03:34 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0253E1201F8 for ; Mon, 10 Jul 2017 08:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3oGCBoo1ykg for ; Mon, 10 Jul 2017 08:03:31 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9E4124D85 for ; Mon, 10 Jul 2017 08:03:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6FFC0B80DD1; Mon, 10 Jul 2017 08:03:30 -0700 (PDT) To: philliph@comodo.com, rob.stradling@comodo.com, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, kent@bbn.com, stefan@aaa-sec.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: philliph@comodo.com, pkix@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170710150330.6FFC0B80DD1@rfc-editor.org> Date: Mon, 10 Jul 2017 08:03:30 -0700 (PDT) Archived-At: Subject: [pkix] [Technical Errata Reported] RFC6844 (5065) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 15:03:33 -0000 The following errata report has been submitted for RFC6844, "DNS Certification Authority Authorization (CAA) Resource Record". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5065 -------------------------------------- Type: Technical Reported by: Phillip Hallam-Baker Section: 4 Original Text ------------- Let CAA(X) be the record set returned in response to performing a CAA record query on the label X, P(X) be the DNS label immediately above X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record specified at the label X. o If CAA(X) is not empty, R(X) = CAA (X), otherwise o If A(X) is not null, and R(A(X)) is not empty, then R(X) = R(A(X)), otherwise o If X is not a top-level domain, then R(X) = R(P(X)), otherwise o R(X) is empty. Corrected Text -------------- Let CAA(X) be the record set returned in response to performing a CAA record query on the label X, P(X) be the DNS label immediately above X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record chain specified at the label X. o If CAA(X) is not empty, R(X) = CAA (X), otherwise o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) = CAA(A(X)), otherwise o If X is not a top-level domain, then R(X) = R(P(X)), otherwise o R(X) is empty. Thus, when a search at node X returns a CNAME record, the CA will follow the CNAME record chain to its target. If the target label contains a CAA record, it is returned. ​O​therwise, the CA continues the search at the parent of node X. Note that the search does not include the parent of a target of a CNAME record (except when the CNAME points back to its own path). To prevent resource exhaustion attacks, CAs SHOULD limit the length of CNAME chains that are accepted. However CAs MUST process CNAME chains that contain 8 or fewer CNAME records. Notes ----- This is the updated errata to replace the ones previously deleted. It has been reviewed by all the parties concerned. Since this is a breaking change, this will have to go to hold for document update. The LAMPS working group is currently considering a more radical re-working of the CAA discovery scheme as a work item for its new charter. I will be in Prague to discuss... Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6844 (draft-ietf-pkix-caa-15) -------------------------------------- Title : DNS Certification Authority Authorization (CAA) Resource Record Publication Date : January 2013 Author(s) : P. Hallam-Baker, R. Stradling Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Jul 17 07:19:51 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F138413166B for ; Mon, 17 Jul 2017 07:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.343 X-Spam-Level: X-Spam-Status: No, score=-0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, 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 1zntrbVVXgvK for ; Mon, 17 Jul 2017 07:19:47 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 9B27B131BB0 for ; Mon, 17 Jul 2017 07:19:47 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id DC9B43740F41 for ; Mon, 17 Jul 2017 10:19:46 -0400 (EDT) To: pkix@ietf.org From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> Date: Mon, 17 Jul 2017 16:19:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------9AA471A342822CC1C358CC52" Content-Language: en-US Archived-At: Subject: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 14:19:49 -0000 This is a multi-part message in MIME format. --------------9AA471A342822CC1C358CC52 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi PKIX, I have a small question for the list regarding long-lived CA certificates. Especially in the context of device certificates, we often see the use of extra long-lived certificates for Root and Sub CAs (e.g., 35+ years) combined with limited key sizes (e.g., p256). Until we have a supported mechanism for reprovisioning devices (...), one possible solution for limiting the exposure of the private key would be to have a scoped certificate issuance period. What I am thinking about would be adding an extension that says: "This CA can issue certificates from up to 5 years from the validFrom, after this, just use it to provide revocation information". This might provide some protection in case the CA key is compromised after the initial 5 years of validity (e.g., certificates issued after that date shall be rejected). Does such extension exists today ? If not, could this be some work for LAMPS/SPASM WG ? Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------9AA471A342822CC1C358CC52 Content-Type: multipart/related; boundary="------------DD3D316B58580DD3471CE643" --------------DD3D316B58580DD3471CE643 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi PKIX,

I have a small question for the list regarding long-lived CA certificates. Especially in the context of device certificates, we often see the use of extra long-lived certificates for Root and Sub CAs (e.g., 35+ years) combined with limited key sizes (e.g., p256).

Until we have a supported mechanism for reprovisioning devices (...), one possible solution for limiting the exposure of the private key would be to have a scoped certificate issuance period.

What I am thinking about would be adding an extension that says: "This CA can issue certificates from up to 5 years from the validFrom, after this, just use it to provide revocation information". This might provide some protection in case the CA key is compromised after the initial 5 years of validity (e.g., certificates issued after that date shall be rejected).

Does such extension exists today ? If not, could this be some work for LAMPS/SPASM WG ?

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------DD3D316B58580DD3471CE643 Content-Type: image/png; name="eibffaoijngmjaee.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="eibffaoijngmjaee.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= --------------DD3D316B58580DD3471CE643-- --------------9AA471A342822CC1C358CC52-- From nobody Mon Jul 17 07:50:00 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3B7131472 for ; Mon, 17 Jul 2017 07:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b67epfTOz2k for ; Mon, 17 Jul 2017 07:49:55 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 DC66A127B60 for ; Mon, 17 Jul 2017 07:49:54 -0700 (PDT) Received: (qmail 10815 invoked by uid 1004); 17 Jul 2017 14:49:52 -0000 Received: from rmdccgwarp1.reyn.mcr.dc.comodo.net (HELO maileu.comodo.net) (10.1.72.82) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 17 Jul 2017 15:49:52 +0100 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201707171549504083; Mon, 17 Jul 2017 15:49:50 +0100 To: "Dr. Pala" References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> Cc: pkix@ietf.org From: Rob Stradling Message-ID: <5ff947d4-4609-a998-ee16-6988750bedba@comodo.com> Date: Mon, 17 Jul 2017 15:49:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 14:49:58 -0000 Hi Max. The "Private Key Usage Period" extension was present in RFC2459 and RFC3280 (see section 4.2.1.4), but was removed in RFC5280. (Well, mostly removed; the ASN.1 definitions are still in Appendix A.2 ;-) ). On 17/07/17 15:19, Dr. Pala wrote: > Hi PKIX, > > I have a small question for the list regarding long-lived CA > certificates. Especially in the context of device certificates, we often > see the use of extra long-lived certificates for Root and Sub CAs (e.g., > 35+ years) combined with limited key sizes (e.g., p256). > > Until we have a supported mechanism for reprovisioning devices (...), > one possible solution for limiting the exposure of the private key would > be to have a scoped certificate issuance period. > > What I am thinking about would be adding an extension that says: "This > CA can issue certificates from up to 5 years from the validFrom, after > this, just use it to provide revocation information". This might provide > some protection in case the CA key is compromised after the initial 5 > years of validity (e.g., certificates issued after that date shall be > rejected). > > Does such extension exists today ? If not, could this be some work for > LAMPS/SPASM WG ? > > Cheers, > Max > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > OpenCA Logo > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Jul 17 07:58:41 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8D3126557 for ; Mon, 17 Jul 2017 07:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJliO6ar5SWD for ; Mon, 17 Jul 2017 07:58:38 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 35FED1200FC for ; Mon, 17 Jul 2017 07:58:38 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 79ECB3740F41 for ; Mon, 17 Jul 2017 10:58:37 -0400 (EDT) To: PKIX References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <5ff947d4-4609-a998-ee16-6988750bedba@comodo.com> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <6d12f836-6920-0a37-bff7-326b998dae3e@openca.org> Date: Mon, 17 Jul 2017 16:58:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5ff947d4-4609-a998-ee16-6988750bedba@comodo.com> Content-Type: multipart/alternative; boundary="------------5E0DBBF8552F323DB1B360DA" Content-Language: en-US Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 14:58:40 -0000 This is a multi-part message in MIME format. --------------5E0DBBF8552F323DB1B360DA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Rob, I was thinking about that but wouldn't it prevent using the key for other reasons like signing CRLs ? I know you can have a separate CRL signer, but I would like to limit _only_ the issuing of certificates, not other usages. Cheers, Max On 7/17/17 4:49 PM, Rob Stradling wrote: > Hi Max. > > The "Private Key Usage Period" extension was present in RFC2459 and > RFC3280 (see section 4.2.1.4), but was removed in RFC5280. (Well, > mostly removed; the ASN.1 definitions are still in Appendix A.2 ;-) ). > > On 17/07/17 15:19, Dr. Pala wrote: >> Hi PKIX, >> >> I have a small question for the list regarding long-lived CA >> certificates. Especially in the context of device certificates, we >> often see the use of extra long-lived certificates for Root and Sub >> CAs (e.g., 35+ years) combined with limited key sizes (e.g., p256). >> >> Until we have a supported mechanism for reprovisioning devices (...), >> one possible solution for limiting the exposure of the private key >> would be to have a scoped certificate issuance period. >> >> What I am thinking about would be adding an extension that says: >> "This CA can issue certificates from up to 5 years from the >> validFrom, after this, just use it to provide revocation >> information". This might provide some protection in case the CA key >> is compromised after the initial 5 years of validity (e.g., >> certificates issued after that date shall be rejected). >> >> Does such extension exists today ? If not, could this be some work >> for LAMPS/SPASM WG ? >> >> Cheers, >> Max >> >> -- >> Best Regards, >> Massimiliano Pala, Ph.D. >> OpenCA Labs Director >> OpenCA Logo >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------5E0DBBF8552F323DB1B360DA Content-Type: multipart/related; boundary="------------B3D83A52BC1A2C8963912377" --------------B3D83A52BC1A2C8963912377 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Rob,

I was thinking about that but wouldn't it prevent using the key for other reasons like signing CRLs ? I know you can have a separate CRL signer, but I would like to limit only the issuing of certificates, not other usages.

Cheers,
Max


On 7/17/17 4:49 PM, Rob Stradling wrote:
Hi Max.

The "Private Key Usage Period" extension was present in RFC2459 and RFC3280 (see section 4.2.1.4), but was removed in RFC5280.  (Well, mostly removed; the ASN.1 definitions are still in Appendix A.2 ;-) ).

On 17/07/17 15:19, Dr. Pala wrote:
Hi PKIX,

I have a small question for the list regarding long-lived CA certificates. Especially in the context of device certificates, we often see the use of extra long-lived certificates for Root and Sub CAs (e.g., 35+ years) combined with limited key sizes (e.g., p256).

Until we have a supported mechanism for reprovisioning devices (...), one possible solution for limiting the exposure of the private key would be to have a scoped certificate issuance period.

What I am thinking about would be adding an extension that says: "This CA can issue certificates from up to 5 years from the validFrom, after this, just use it to provide revocation information". This might provide some protection in case the CA key is compromised after the initial 5 years of validity (e.g., certificates issued after that date shall be rejected).

Does such extension exists today ? If not, could this be some work for LAMPS/SPASM WG ?

Cheers,
Max

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


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



--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------B3D83A52BC1A2C8963912377 Content-Type: image/png; name="mfofkneikpkmnabc.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="mfofkneikpkmnabc.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= --------------B3D83A52BC1A2C8963912377-- --------------5E0DBBF8552F323DB1B360DA-- From nobody Mon Jul 17 08:04:47 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C304131C5A for ; Mon, 17 Jul 2017 08:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWTjJxmSRAYs for ; Mon, 17 Jul 2017 08:04:43 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) (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 547DA131C56 for ; Mon, 17 Jul 2017 08:04:42 -0700 (PDT) Received: from Morten ([62.44.134.67]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id 3201707171704372238 for ; Mon, 17 Jul 2017 17:04:37 +0200 From: "Erik Andersen" To: "PKIX" References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> In-Reply-To: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> Date: Mon, 17 Jul 2017 17:04:35 +0200 Message-ID: <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0016_01D2FF1E.C4783640" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDOcHAtNaigQtZhTsCOwy8a/DXXL6RhOfmQ Content-Language: en-gb Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:04:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0016_01D2FF1E.C4783640 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0017_01D2FF1E.C4783640" ------=_NextPart_001_0017_01D2FF1E.C4783640 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Massimiliano, =20 What about the private key usage period extension. It was clarified in = the latest edition of X.509: =20 9.2.2.5 Private key usage period extension This extension indicates the period of use of the private key = corresponding to the certified public key. It is applicable only for = private key used for creating digital signatures. This extension is = defined as follows: =20 privateKeyUsagePeriod EXTENSION ::=3D { SYNTAX PrivateKeyUsagePeriod IDENTIFIED BY id-ce-privateKeyUsagePeriod } =20 PrivateKeyUsagePeriod ::=3D SEQUENCE { notBefore [0] GeneralizedTime OPTIONAL, notAfter [1] GeneralizedTime OPTIONAL, ... } (WITH COMPONENTS {..., notBefore PRESENT } | WITH COMPONENTS {..., notAfter PRESENT } ) The notBefore component indicates the earliest date and time at which = the private key may be used for signing. If the notBefore component is = not present, then no information is provided as to when the period of = valid use of the private key commences beyond that specified in the = validity component of the public-key certificate. The notAfter component = indicates the latest date and time at which the private key may be used = for signing. If the notAfter component is not present then no = information is provided as to when the period of valid use of the = private key concludes beyond that specified in the validity component of = the public-key certificate. This extension shall always be flagged as non-critical. NOTE 1 =E2=80=93 The period of valid use of the private key may be = different from the certified validity of the public key as indicated by = the public-key certificate validity period. The usage period for the = private key used for signing is typically shorter than that for the = public key used for verifying the signature. NOTE 2 =E2=80=93 The period of use of the private key corresponding to = a public key can only be enforced if both the private key and the = corresponding public-key certificate are placed in a tamper-resistant = hardware module that contains a reliable clock synchronized with UTC. = When this is not the case, a signer may avoid using a signing private = key up to the very end of the validity period of the public-key = certificate. This is one possible use of this extension. NOTE 3 =E2=80=93 In general, this Specification does not associate any = semantic with this extension. Any particular use of this extension will = have to specify the semantic associated with that usage. =20 =20 Fra: pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af Dr. Pala Sendt: 17 July 2017 16:20 Til: pkix@ietf.org Emne: [pkix] Managing Long-Lived CA certs =20 Hi PKIX, I have a small question for the list regarding long-lived CA = certificates. Especially in the context of device certificates, we often = see the use of extra long-lived certificates for Root and Sub CAs (e.g., = 35+ years) combined with limited key sizes (e.g., p256). Until we have a supported mechanism for reprovisioning devices (...), = one possible solution for limiting the exposure of the private key would = be to have a scoped certificate issuance period. What I am thinking about would be adding an extension that says: "This = CA can issue certificates from up to 5 years from the validFrom, after = this, just use it to provide revocation information". This might provide = some protection in case the CA key is compromised after the initial 5 = years of validity (e.g., certificates issued after that date shall be = rejected). Does such extension exists today ? If not, could this be some work for = LAMPS/SPASM WG ? Cheers, Max --=20 Best Regards,=20 Massimiliano Pala, Ph.D. OpenCA Labs Director ------=_NextPart_001_0017_01D2FF1E.C4783640 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Massimiliano,

 

What about the private key usage period = extension. It was clarified in the latest edition of = X.509:

 

9.2.2.5=C2=A0=C2=A0=C2=A0=C2=A0 Private key usage = period extension

This extension = indicates the period of use of the private key corresponding to the = certified public key. It is applicable only for private key used for = creating digital signatures. This extension is defined as = follows:

 

privateKeyUsagePeriod EXTENSION ::=3D {

=C2=A0 = SYNTAX=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = PrivateKeyUsagePeriod

=C2=A0 IDENTIFIED = BY=C2=A0 id-ce-privateKeyUsagePeriod }

 

PrivateKeyUsagePeriod = ::=3D SEQUENCE {

=C2=A0 notBefore=C2=A0 = [0]=C2=A0 GeneralizedTime OPTIONAL,

=C2=A0 = notAfter=C2=A0=C2=A0 [1]=C2=A0 GeneralizedTime = OPTIONAL,

=C2=A0 ... }

=C2=A0 (WITH COMPONENTS {..., notBefore=C2=A0 PRESENT } = |

=C2=A0=C2=A0 WITH COMPONENTS {..., = notAfter=C2=A0=C2=A0 PRESENT } )

The = notBefore component indicates = the earliest date and time at which the private key may be used for = signing. If the notBefore component is not = present, then no information is provided as to when the period of valid = use of the private key commences beyond that specified in the validity = component of the public-key certificate. The notAfter = component indicates the latest date and time at which the = private key may be used for signing. If the notAfter component is not = present then no information is provided as to when the period of valid = use of the private key concludes beyond that specified in the validity = component of the public-key certificate.

This extension shall always be flagged as = non-critical.

NOTE 1 =E2=80=93 The period of valid use of = the private key may be different from the certified validity of the = public key as indicated by the public-key certificate validity period. = The usage period for the private key used for signing is typically = shorter than that for the public key used for verifying the = signature.

NOTE =  2 =E2=80=93 The period of use of the private key = corresponding to a public key can only be enforced if both the private = key and the corresponding public-key certificate are placed in a = tamper-resistant hardware module that contains a reliable clock = synchronized with UTC. When this is not the case, a signer may avoid = using a signing private key up to the very end of the validity period of = the public-key certificate. This is one possible use of this = extension.

NOTE 3 =E2=80=93 In general, this = Specification does not associate any semantic with this extension. Any = particular use of this extension will have to specify the semantic = associated with that usage.

 

 

Fra: pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af Dr. = Pala
Sendt: 17 July 2017 16:20
Til: = pkix@ietf.org
Emne: [pkix] Managing Long-Lived CA = certs

 

Hi PKIX,

I = have a small question for the list regarding long-lived CA certificates. = Especially in the context of device certificates, we often see the use = of extra long-lived certificates for Root and Sub CAs (e.g., 35+ years) = combined with limited key sizes (e.g., p256).

Until we = have a supported mechanism for reprovisioning devices (...), one = possible solution for limiting the exposure of the private key would be = to have a scoped certificate issuance period.

What I am = thinking about would be adding an extension that says: "This CA can = issue certificates from up to 5 years from the validFrom, after this, = just use it to provide revocation information". This might provide = some protection in case the CA key is compromised after the initial 5 = years of validity (e.g., certificates issued after that date shall be = rejected).

Does such extension exists today ? If not, = could this be some work for LAMPS/SPASM WG = ?

Cheers,
Max

--

Best Regards,

Massimiliano Pala, = Ph.D.
OpenCA Labs Director

3D"OpenCA

------=_NextPart_001_0017_01D2FF1E.C4783640-- ------=_NextPart_000_0016_01D2FF1E.C4783640 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/ MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp 7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91 aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6 yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV 2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7 QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7 qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6 vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP 7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90 1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K +f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA AAAASUVORK5CYII= ------=_NextPart_000_0016_01D2FF1E.C4783640-- From nobody Mon Jul 17 08:16:42 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09D7126D73 for ; Mon, 17 Jul 2017 08:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ6pr1L_2OHb for ; Mon, 17 Jul 2017 08:16:38 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id D2285131C3C for ; Mon, 17 Jul 2017 08:16:37 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id EEE5D3740F41 for ; Mon, 17 Jul 2017 11:16:36 -0400 (EDT) To: pkix@ietf.org References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> From: "Dr. Pala" Message-ID: <4c3aadcc-7ed0-5f60-640c-93a11cb718bc@openca.org> Date: Mon, 17 Jul 2017 17:16:34 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> Content-Type: multipart/alternative; boundary="------------0671D2D021968B2DEF32EFDA" Content-Language: en-US Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:16:40 -0000 This is a multi-part message in MIME format. --------------0671D2D021968B2DEF32EFDA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Eric, thanks, however this does not solve the issue I am trying to address - it would be great if we would have it scoped. For example (not aiming at correctness here.. :D): privateKeyUsageTypes ::= CHOICE { anyPurpose, certificateSigning, ... } scopedPrivateKeyUsagePeriod ::= SEQUENCE { scope privateKeyUsageTypes, notBefore [0] GeneralizedTime OPTIONAL, notAfter [1] GeneralizedTime OPTIONAL } privateKeyUsageRestrictions ::= SET OF scopedPrivateKeyUsagePeriod Of course, this is just an example :-D Cheers, Max On 7/17/17 5:04 PM, Erik Andersen wrote: > > Hi Massimiliano, > > What about the private key usage period extension. It was clarified in > the latest edition of X.509: > > > 9.2.2.5 Private key usage period extension > > This extension indicates the period of use of the private key > corresponding to the certified public key. It is applicable only for > private key used for creating digital signatures. This extension is > defined as follows: > > privateKeyUsagePeriod EXTENSION ::= { > > SYNTAX PrivateKeyUsagePeriod > > IDENTIFIED BY id-ce-privateKeyUsagePeriod } > > PrivateKeyUsagePeriod ::= SEQUENCE { > > notBefore [0] GeneralizedTime OPTIONAL, > > notAfter [1] GeneralizedTime OPTIONAL, > > ... } > > (WITH COMPONENTS {..., notBefore PRESENT } | > > WITH COMPONENTS {..., notAfter PRESENT } ) > > The notBefore component indicates the earliest date and time at which > the private key may be used for signing. If the notBefore component is > not present, then no information is provided as to when the period of > valid use of the private key commences beyond that specified in the > validity component of the public-key certificate. The notAfter > component indicates the latest date and time at which the private key > may be used for signing. If the notAfter component is not present then > no information is provided as to when the period of valid use of the > private key concludes beyond that specified in the validity component > of the public-key certificate. > > This extension shall always be flagged as non-critical. > > NOTE 1 – The period of valid use of the private key may be different > from the certified validity of the public key as indicated by the > public-key certificate validity period. The usage period for the > private key used for signing is typically shorter than that for the > public key used for verifying the signature. > > NOTE 2 – The period of use of the private key corresponding to a > public key can only be enforced if both the private key and the > corresponding public-key certificate are placed in a tamper-resistant > hardware module that contains a reliable clock synchronized with UTC. > When this is not the case, a signer may avoid using a signing private > key up to the very end of the validity period of the public-key > certificate. This is one possible use of this extension. > > NOTE 3 – In general, this Specification does not associate any > semantic with this extension. Any particular use of this extension > will have to specify the semantic associated with that usage. > > *Fra:*pkix [mailto:pkix-bounces@ietf.org] *På vegne af *Dr. Pala > *Sendt:* 17 July 2017 16:20 > *Til:* pkix@ietf.org > *Emne:* [pkix] Managing Long-Lived CA certs > > Hi PKIX, > > I have a small question for the list regarding long-lived CA > certificates. Especially in the context of device certificates, we > often see the use of extra long-lived certificates for Root and Sub > CAs (e.g., 35+ years) combined with limited key sizes (e.g., p256). > > Until we have a supported mechanism for reprovisioning devices (...), > one possible solution for limiting the exposure of the private key > would be to have a scoped certificate issuance period. > > What I am thinking about would be adding an extension that says: "This > CA can issue certificates from up to 5 years from the validFrom, after > this, just use it to provide revocation information". This might > provide some protection in case the CA key is compromised after the > initial 5 years of validity (e.g., certificates issued after that date > shall be rejected). > > Does such extension exists today ? If not, could this be some work for > LAMPS/SPASM WG ? > > Cheers, > Max > > -- > > Best Regards, > > Massimiliano Pala, Ph.D. > OpenCA Labs Director > > OpenCA Logo > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------0671D2D021968B2DEF32EFDA Content-Type: multipart/related; boundary="------------24C2BDCB9D7DFAB6CCAB2DF7" --------------24C2BDCB9D7DFAB6CCAB2DF7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Eric,

thanks, however this does not solve the issue I am trying to address - it would be great if we would have it scoped. For example (not aiming at correctness here.. :D):

privateKeyUsageTypes ::= CHOICE {
   anyPurpose,
   certificateSigning,
   ... 
}

scopedPrivateKeyUsagePeriod ::= SEQUENCE {
   scope           privateKeyUsageTypes,
   notBefore   [0] GeneralizedTime OPTIONAL,
   notAfter    [1] GeneralizedTime OPTIONAL
}

privateKeyUsageRestrictions ::= SET OF scopedPrivateKeyUsagePeriod
Of course, this is just an example :-D

Cheers,
Max

On 7/17/17 5:04 PM, Erik Andersen wrote:

Hi Massimiliano,

 

What about the private key usage period extension. It was clarified in the latest edition of X.509:

 

9.2.2.5     Private key usage period extension

This extension indicates the period of use of the private key corresponding to the certified public key. It is applicable only for private key used for creating digital signatures. This extension is defined as follows:

 

privateKeyUsagePeriod EXTENSION ::= {

  SYNTAX         PrivateKeyUsagePeriod

  IDENTIFIED BY  id-ce-privateKeyUsagePeriod }

 

PrivateKeyUsagePeriod ::= SEQUENCE {

  notBefore  [0]  GeneralizedTime OPTIONAL,

  notAfter   [1]  GeneralizedTime OPTIONAL,

  ... }

  (WITH COMPONENTS {..., notBefore  PRESENT } |

   WITH COMPONENTS {..., notAfter   PRESENT } )

The notBefore component indicates the earliest date and time at which the private key may be used for signing. If the notBefore component is not present, then no information is provided as to when the period of valid use of the private key commences beyond that specified in the validity component of the public-key certificate. The notAfter component indicates the latest date and time at which the private key may be used for signing. If the notAfter component is not present then no information is provided as to when the period of valid use of the private key concludes beyond that specified in the validity component of the public-key certificate.

This extension shall always be flagged as non-critical.

NOTE 1 – The period of valid use of the private key may be different from the certified validity of the public key as indicated by the public-key certificate validity period. The usage period for the private key used for signing is typically shorter than that for the public key used for verifying the signature.

NOTE  2 – The period of use of the private key corresponding to a public key can only be enforced if both the private key and the corresponding public-key certificate are placed in a tamper-resistant hardware module that contains a reliable clock synchronized with UTC. When this is not the case, a signer may avoid using a signing private key up to the very end of the validity period of the public-key certificate. This is one possible use of this extension.

NOTE 3 – In general, this Specification does not associate any semantic with this extension. Any particular use of this extension will have to specify the semantic associated with that usage.

 

 

Fra: pkix [mailto:pkix-bounces@ietf.org] På vegne af Dr. Pala
Sendt: 17 July 2017 16:20
Til: pkix@ietf.org
Emne: [pkix] Managing Long-Lived CA certs

 

Hi PKIX,

I have a small question for the list regarding long-lived CA certificates. Especially in the context of device certificates, we often see the use of extra long-lived certificates for Root and Sub CAs (e.g., 35+ years) combined with limited key sizes (e.g., p256).

Until we have a supported mechanism for reprovisioning devices (...), one possible solution for limiting the exposure of the private key would be to have a scoped certificate issuance period.

What I am thinking about would be adding an extension that says: "This CA can issue certificates from up to 5 years from the validFrom, after this, just use it to provide revocation information". This might provide some protection in case the CA key is compromised after the initial 5 years of validity (e.g., certificates issued after that date shall be rejected).

Does such extension exists today ? If not, could this be some work for LAMPS/SPASM WG ?

Cheers,
Max

--

Best Regards,

Massimiliano Pala, Ph.D.
OpenCA Labs Director

OpenCA Logo



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

--------------24C2BDCB9D7DFAB6CCAB2DF7 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="image001.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= --------------24C2BDCB9D7DFAB6CCAB2DF7-- --------------0671D2D021968B2DEF32EFDA-- From nobody Mon Jul 17 08:41:44 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FCE131C71 for ; Mon, 17 Jul 2017 08:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM04yzvoWxOo for ; Mon, 17 Jul 2017 08:41:39 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) (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 B4C79131C44 for ; Mon, 17 Jul 2017 08:41:38 -0700 (PDT) Received: from Morten ([62.44.134.67]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id 3201707171741353126 for ; Mon, 17 Jul 2017 17:41:35 +0200 From: "Erik Andersen" To: References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <4c3aadcc-7ed0-5f60-640c-93a11cb718bc@openca.org> In-Reply-To: <4c3aadcc-7ed0-5f60-640c-93a11cb718bc@openca.org> Date: Mon, 17 Jul 2017 17:41:33 +0200 Message-ID: <002c01d2ff13$2add1880$80974980$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_002D_01D2FF23.EE6A0730" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDOcHAtNaigQtZhTsCOwy8a/DXXLwJG2NRHAZgK4cekQk2wQA== Content-Language: en-gb Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:41:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002D_01D2FF23.EE6A0730 Content-Type: multipart/alternative; boundary="----=_NextPart_001_002E_01D2FF23.EE6A0730" ------=_NextPart_001_002E_01D2FF23.EE6A0730 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Max, =20 Would adding an optional key usage component after the extension mark = solve the issue? =20 Regards, =20 Erik =20 Fra: pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af Dr. Pala Sendt: 17 July 2017 17:17 Til: pkix@ietf.org Emne: Re: [pkix] Managing Long-Lived CA certs =20 Hi Eric, thanks, however this does not solve the issue I am trying to address - = it would be great if we would have it scoped. For example (not aiming at = correctness here.. :D): privateKeyUsageTypes ::=3D CHOICE { anyPurpose, certificateSigning, ...=20 } scopedPrivateKeyUsagePeriod ::=3D SEQUENCE { scope privateKeyUsageTypes, notBefore [0] GeneralizedTime OPTIONAL, notAfter [1] GeneralizedTime OPTIONAL } =20 privateKeyUsageRestrictions ::=3D SET OF scopedPrivateKeyUsagePeriod =20 Of course, this is just an example :-D Cheers, Max On 7/17/17 5:04 PM, Erik Andersen wrote: Hi Massimiliano, =20 What about the private key usage period extension. It was clarified in = the latest edition of X.509: =20 9.2.2.5 Private key usage period extension This extension indicates the period of use of the private key = corresponding to the certified public key. It is applicable only for = private key used for creating digital signatures. This extension is = defined as follows: =20 privateKeyUsagePeriod EXTENSION ::=3D { SYNTAX PrivateKeyUsagePeriod IDENTIFIED BY id-ce-privateKeyUsagePeriod } =20 PrivateKeyUsagePeriod ::=3D SEQUENCE { notBefore [0] GeneralizedTime OPTIONAL, notAfter [1] GeneralizedTime OPTIONAL, ... } (WITH COMPONENTS {..., notBefore PRESENT } | WITH COMPONENTS {..., notAfter PRESENT } ) The notBefore component indicates the earliest date and time at which = the private key may be used for signing. If the notBefore component is = not present, then no information is provided as to when the period of = valid use of the private key commences beyond that specified in the = validity component of the public-key certificate. The notAfter component = indicates the latest date and time at which the private key may be used = for signing. If the notAfter component is not present then no = information is provided as to when the period of valid use of the = private key concludes beyond that specified in the validity component of = the public-key certificate. This extension shall always be flagged as non-critical. NOTE 1 =E2=80=93 The period of valid use of the private key may be = different from the certified validity of the public key as indicated by = the public-key certificate validity period. The usage period for the = private key used for signing is typically shorter than that for the = public key used for verifying the signature. NOTE 2 =E2=80=93 The period of use of the private key corresponding to = a public key can only be enforced if both the private key and the = corresponding public-key certificate are placed in a tamper-resistant = hardware module that contains a reliable clock synchronized with UTC. = When this is not the case, a signer may avoid using a signing private = key up to the very end of the validity period of the public-key = certificate. This is one possible use of this extension. NOTE 3 =E2=80=93 In general, this Specification does not associate any = semantic with this extension. Any particular use of this extension will = have to specify the semantic associated with that usage. =20 =20 Fra: pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af Dr. Pala Sendt: 17 July 2017 16:20 Til: pkix@ietf.org =20 Emne: [pkix] Managing Long-Lived CA certs =20 Hi PKIX, I have a small question for the list regarding long-lived CA = certificates. Especially in the context of device certificates, we often = see the use of extra long-lived certificates for Root and Sub CAs (e.g., = 35+ years) combined with limited key sizes (e.g., p256). Until we have a supported mechanism for reprovisioning devices (...), = one possible solution for limiting the exposure of the private key would = be to have a scoped certificate issuance period. What I am thinking about would be adding an extension that says: "This = CA can issue certificates from up to 5 years from the validFrom, after = this, just use it to provide revocation information". This might provide = some protection in case the CA key is compromised after the initial 5 = years of validity (e.g., certificates issued after that date shall be = rejected). Does such extension exists today ? If not, could this be some work for = LAMPS/SPASM WG ? Cheers, Max --=20 Best Regards,=20 Massimiliano Pala, Ph.D. OpenCA Labs Director _______________________________________________ pkix mailing list pkix@ietf.org =20 https://www.ietf.org/mailman/listinfo/pkix =20 ------=_NextPart_001_002E_01D2FF23.EE6A0730 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Max,

 

Would adding an optional key usage component = after the extension mark solve the issue?

 

Regards,

 

Erik

 

Fra: pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af Dr. = Pala
Sendt: 17 July 2017 17:17
Til: = pkix@ietf.org
Emne: Re: [pkix] Managing Long-Lived CA = certs

 

Hi = Eric,

thanks, however this does not solve the issue I = am trying to address - it would be great if we would have it scoped. For = example (not aiming at correctness here.. = :D):

privateKeyUsageTypes ::=3D CHOICE =
{
=C2=A0=C2=A0 =
anyPurpose,
   =
certificateSigning,
=C2=A0=C2=A0 ... =

}
scopedPrivateKeyUsagePeriod =
::=3D SEQUENCE {
=C2=A0=C2=A0 =
scope=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
privateKeyUsageTypes,
=C2=A0=C2=A0 =
notBefore=C2=A0=C2=A0 [0] GeneralizedTime =
OPTIONAL,
=C2=A0=C2=A0 notAfter=C2=A0=C2=A0=C2=A0 =
[1] GeneralizedTime =
OPTIONAL
}
 
privateKeyUsageRestrictions ::=3D SET OF =
scopedPrivateKeyUsagePeriod
 
<=
p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>Of course, this is =
just an example :-D

Cheers,
Max
On 7/17/17 5:04 PM, Erik Andersen =
wrote:
Hi Massimiliano,
 
What about the private key usage period =
extension. It was clarified in the latest edition of =
X.509:
 
9.2.2.5     Private key =
usage period extension
This =
extension indicates the period of use of the private key corresponding =
to the certified public key. It is applicable only for private key used =
for creating digital signatures. This extension is defined as =
follows:
 
privateKeyUsagePeriod EXTENSION ::=3D {
  =
SYNTAX         =
PrivateKeyUsagePeriod
  IDENTIFIED =
BY  id-ce-privateKeyUsagePeriod }
 
PrivateKeyUsagePeriod =
::=3D SEQUENCE {
  notBefore  =
[0]  GeneralizedTime OPTIONAL,
  =
notAfter   [1]  GeneralizedTime =
OPTIONAL,
  ... }
  (WITH COMPONENTS {..., notBefore  PRESENT } =
|
   WITH COMPONENTS {..., =
notAfter   PRESENT } )
The =
notBefore component indicates =
the earliest date and time at which the private key may be used for =
signing. If the notBefore component is not =
present, then no information is provided as to when the period of valid =
use of the private key commences beyond that specified in the validity =
component of the public-key certificate. The notAfter =
component indicates the latest date and time at which the =
private key may be used for signing. If the notAfter component is not =
present then no information is provided as to when the period of valid =
use of the private key concludes beyond that specified in the validity =
component of the public-key certificate.
This extension shall always be flagged as =
non-critical.
NOTE 1 =E2=80=93 The period of valid use of =
the private key may be different from the certified validity of the =
public key as indicated by the public-key certificate validity period. =
The usage period for the private key used for signing is typically =
shorter than that for the public key used for verifying the =
signature.
NOTE =
 2 =E2=80=93 The period of use of the private key =
corresponding to a public key can only be enforced if both the private =
key and the corresponding public-key certificate are placed in a =
tamper-resistant hardware module that contains a reliable clock =
synchronized with UTC. When this is not the case, a signer may avoid =
using a signing private key up to the very end of the validity period of =
the public-key certificate. This is one possible use of this =
extension.
NOTE 3 =E2=80=93 In general, this =
Specification does not associate any semantic with this extension. Any =
particular use of this extension will have to specify the semantic =
associated with that usage.
 
 
Fra: pkix [mailto:pkix-bounces@ietf.org] =
P=C3=A5 vegne af Dr. Pala
Sendt: 17 July 2017 =
16:20
Til: pkix@ietf.org
Emne: [pkix] =
Managing Long-Lived CA certs
 
Hi PKIX,
I =
have a small question for the list regarding long-lived CA certificates. =
Especially in the context of device certificates, we often see the use =
of extra long-lived certificates for Root and Sub CAs (e.g., 35+ years) =
combined with limited key sizes (e.g., p256).
Until we =
have a supported mechanism for reprovisioning devices (...), one =
possible solution for limiting the exposure of the private key would be =
to have a scoped certificate issuance period.
What I am =
thinking about would be adding an extension that says: "This CA can =
issue certificates from up to 5 years from the validFrom, after this, =
just use it to provide revocation information". This might provide =
some protection in case the CA key is compromised after the initial 5 =
years of validity (e.g., certificates issued after that date shall be =
rejected).
Does such extension exists today ? If not, =
could this be some work for LAMPS/SPASM WG =
?
Cheers,
Max
-- 
Best Regards, 
Massimiliano Pala, =
Ph.D.
OpenCA Labs Director
3D"OpenCA




_______________________=
________________________
pkix mailing =
list
pkix@ietf.org
https://www.ietf.org/=
mailman/listinfo/pkix
 
------=_NextPart_001_002E_01D2FF23.EE6A0730-- ------=_NextPart_000_002D_01D2FF23.EE6A0730 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/ MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp 7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91 aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6 yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV 2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7 QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7 qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6 vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP 7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90 1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K +f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA AAAASUVORK5CYII= ------=_NextPart_000_002D_01D2FF23.EE6A0730-- From nobody Mon Jul 17 08:43:03 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD88131C56 for ; Mon, 17 Jul 2017 08:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf5FzzYVHd2U for ; Mon, 17 Jul 2017 08:43:00 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D02512EC12 for ; Mon, 17 Jul 2017 08:43:00 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id 32so109414770qtv.1 for ; Mon, 17 Jul 2017 08:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=l0LUlUaTG9BLy7Px+UbfU6yEYKYzr3RiIkS/N/OGDbU=; b=Leh3pbYuT792zjrzkItSZirvcvvvN8EGXL/o79qJd5tgXGhW1O5UzHexhAjc0IZOM7 KeB3fZykGNREn68Be5X4Fcww5MabcbLEIBBrFheQ57Ythg8UoPjQRFui54q4Q6L9JDql PWX0CgV++1AbVhO40t/xZ+Wlt2Y/uflysNWpQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=l0LUlUaTG9BLy7Px+UbfU6yEYKYzr3RiIkS/N/OGDbU=; b=Az2N8h++jMSpJNt0u2Q8vY5J2vIS3YDqtjq7MwQmT/UTLGh4xt2xlAAyMq1yH0il1G EpyVXgHNZZV6MaC5oEMhdmmDdga3MpDbb/NVU0W+H5VM5rdDSDxTTjD3Ul+VGjKI5qWN 4wiYjZkmkTVwv+rgR/Yw7Oc95MSF5g6g2J58uvJBTzPBSUZTagU3R33UfSN4jZE3Qq3F gtsuR5WGaLqmOCYWOAppK3Cyyteb/Uq2UHVpo7pPnlKb0vL1vGoiFtf9D7hwCE6vDKJA O+xRB9HD+h5GliesljoO9GWqu/2iw9vGJUdyxn5Mh/SZuaREtNyvVC0vrtgruu9YUOwW l2zw== X-Gm-Message-State: AIVw1114QS/mScpoq9lQInfY8UmHP+OUXNrN4QL4UpvZiCO8QEOCFTmr RehqfSEyoDc+m7l+CXo= X-Received: by 10.237.41.225 with SMTP id o88mr29123888qtd.27.1500306179362; Mon, 17 Jul 2017 08:42:59 -0700 (PDT) Received: from [192.168.2.27] (pool-173-66-76-215.washdc.fios.verizon.net. [173.66.76.215]) by smtp.googlemail.com with ESMTPSA id j137sm7661652qke.19.2017.07.17.08.42.57 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 17 Jul 2017 08:42:58 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.4.170508 Date: Mon, 17 Jul 2017 11:42:53 -0400 From: Carl Wallace To: "Dr. Pala" , Message-ID: Thread-Topic: [pkix] Managing Long-Lived CA certs References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> In-Reply-To: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3583136578_14982670" Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:43:03 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3583136578_14982670 Content-type: multipart/alternative; boundary="B_3583136578_15003387" --B_3583136578_15003387 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Inline.. From: pkix on behalf of "Dr. Pala" Organization: OpenCA Labs Date: Monday, July 17, 2017 at 10:19 AM To: Subject: [pkix] Managing Long-Lived CA certs > > > > Hi PKIX, > > > I have a small question for the list regarding long-lived CA certificates. > Especially in the context of device certificates, we often see the use of > extra long-lived certificates for Root and Sub CAs (e.g., 35+ years) combined > with limited key sizes (e.g., p256). > > > Until we have a supported mechanism for reprovisioning devices (...), one > possible solution for limiting the exposure of the private key would be to > have a scoped certificate issuance period. > > > What I am thinking about would be adding an extension that says: "This CA can > issue certificates from up to 5 years from the validFrom, after this, just use > it to provide revocation information". This might provide some protection in > case the CA key is compromised after the initial 5 years of validity (e.g., > certificates issued after that date shall be rejected). [CW] Wouldn't the protection need to come in the form of revocation? If the CA key is compromised, the validity period in certificates cannot be trusted. > > > Does such extension exists today ? If not, could this be some work for > LAMPS/SPASM WG ? > > > Cheers, > Max > > > -- > > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > > > > > > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3583136578_15003387 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Inline..

=
From: pkix <pkix-bounces@ietf.org> on behalf of "Dr. Pala" <director@openca.org>
Organization: OpenCA Labs
Date: Monday, July 17, 2017 at 10:19 AM
To: <pkix@ietf.or= g>
Subject: [pkix] Managing= Long-Lived CA certs

Hi PKIX,

I have a small question for the list regarding long-lived CA certificates. Especially in the context of device certificates, we often see the use of extra long-lived certificates for Root and Sub CAs (e.g., 35+ years) combined with limited key sizes (e.g., p256).

Until we have a supported mechanism for reprovisioning devices (...), one possible solution for limiting the exposure of the private key would be to have a scoped certificate issuance period.

What I am thinking about would be adding an extension that says: "This CA can issue certificates from up to 5 years from the validFrom, after this, just use it to provide revocation information". This might provide some protection in case the CA key is compromised after the initial 5 years of validity (e.g., certificates issued after that date shall be rejected).

[CW] Wouldn't the protection need to come in the = form of revocation? If the CA key is compromised, the validity period in cer= tificates cannot be trusted.

Does such extension exists today ? If not, could this be some work for LAMPS/SPASM WG ?

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix --B_3583136578_15003387-- --B_3583136578_14982670 Content-type: image/png; name="eibffaoijngmjaee.png" Content-ID: Content-disposition: inline; filename="eibffaoijngmjaee.png" Content-transfer-encoding: base64 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= --B_3583136578_14982670-- From nobody Mon Jul 17 08:53:16 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF11127342 for ; Mon, 17 Jul 2017 08:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDUQ2H3hf2mp for ; Mon, 17 Jul 2017 08:53:11 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id A683F12EC42 for ; Mon, 17 Jul 2017 08:53:11 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id BCE713740F41 for ; Mon, 17 Jul 2017 11:53:10 -0400 (EDT) To: pkix@ietf.org References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <4c3aadcc-7ed0-5f60-640c-93a11cb718bc@openca.org> <002c01d2ff13$2add1880$80974980$@x500.eu> From: "Dr. Pala" Message-ID: <258f8448-bf8d-3ef7-3145-9a13f2ec5ea6@openca.org> Date: Mon, 17 Jul 2017 17:53:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <002c01d2ff13$2add1880$80974980$@x500.eu> Content-Type: multipart/alternative; boundary="------------4E0C15D749F443F6FFB9C485" Content-Language: en-US Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:53:14 -0000 This is a multi-part message in MIME format. --------------4E0C15D749F443F6FFB9C485 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Erik, Would the proposed approach provide the possibility to scope only one type of usage (which would work for my case... but maybe there might be other usages that could be restricted) ? Could you make an example of how it would look like ? Thanks, Max On 7/17/17 5:41 PM, Erik Andersen wrote: > > Hi Max, > > Would adding an optional key usage component after the extension mark > solve the issue? > > Regards, > > Erik > > *Fra:*pkix [mailto:pkix-bounces@ietf.org] *På vegne af *Dr. Pala > *Sendt:* 17 July 2017 17:17 > *Til:* pkix@ietf.org > *Emne:* Re: [pkix] Managing Long-Lived CA certs > > Hi Eric, > > thanks, however this does not solve the issue I am trying to address - > it would be great if we would have it scoped. For example (not aiming > at correctness here.. :D): > > privateKeyUsageTypes ::= CHOICE { > anyPurpose, > certificateSigning, > ... > } > scopedPrivateKeyUsagePeriod ::= SEQUENCE { > scope privateKeyUsageTypes, > notBefore [0] GeneralizedTime OPTIONAL, > notAfter [1] GeneralizedTime OPTIONAL > } > privateKeyUsageRestrictions ::= SET OF scopedPrivateKeyUsagePeriod > > Of course, this is just an example :-D > > Cheers, > Max > > On 7/17/17 5:04 PM, Erik Andersen wrote: > > Hi Massimiliano, > > What about the private key usage period extension. It was > clarified in the latest edition of X.509: > > > 9.2.2.5 Private key usage period extension > > This extension indicates the period of use of the private key > corresponding to the certified public key. It is applicable only > for private key used for creating digital signatures. This > extension is defined as follows: > > privateKeyUsagePeriod EXTENSION ::= { > > SYNTAX PrivateKeyUsagePeriod > > IDENTIFIED BY id-ce-privateKeyUsagePeriod } > > PrivateKeyUsagePeriod ::= SEQUENCE { > > notBefore [0] GeneralizedTime OPTIONAL, > > notAfter [1] GeneralizedTime OPTIONAL, > > ... } > > (WITH COMPONENTS {..., notBefore PRESENT } | > > WITH COMPONENTS {..., notAfter PRESENT } ) > > The notBefore component indicates the earliest date and time at > which the private key may be used for signing. If the notBefore > component is not present, then no information is provided as to > when the period of valid use of the private key commences beyond > that specified in the validity component of the public-key > certificate. The notAfter component indicates the latest date and > time at which the private key may be used for signing. If the > notAfter component is not present then no information is provided > as to when the period of valid use of the private key concludes > beyond that specified in the validity component of the public-key > certificate. > > This extension shall always be flagged as non-critical. > > NOTE 1 – The period of valid use of the private key may be > different from the certified validity of the public key as > indicated by the public-key certificate validity period. The usage > period for the private key used for signing is typically shorter > than that for the public key used for verifying the signature. > > NOTE 2 – The period of use of the private key corresponding to a > public key can only be enforced if both the private key and the > corresponding public-key certificate are placed in a > tamper-resistant hardware module that contains a reliable clock > synchronized with UTC. When this is not the case, a signer may > avoid using a signing private key up to the very end of the > validity period of the public-key certificate. This is one > possible use of this extension. > > NOTE 3 – In general, this Specification does not associate any > semantic with this extension. Any particular use of this extension > will have to specify the semantic associated with that usage. > > *Fra:*pkix [mailto:pkix-bounces@ietf.org] *På vegne af *Dr. Pala > *Sendt:* 17 July 2017 16:20 > *Til:* pkix@ietf.org > *Emne:* [pkix] Managing Long-Lived CA certs > > Hi PKIX, > > I have a small question for the list regarding long-lived CA > certificates. Especially in the context of device certificates, we > often see the use of extra long-lived certificates for Root and > Sub CAs (e.g., 35+ years) combined with limited key sizes (e.g., > p256). > > Until we have a supported mechanism for reprovisioning devices > (...), one possible solution for limiting the exposure of the > private key would be to have a scoped certificate issuance period. > > What I am thinking about would be adding an extension that says: > "This CA can issue certificates from up to 5 years from the > validFrom, after this, just use it to provide revocation > information". This might provide some protection in case the CA > key is compromised after the initial 5 years of validity (e.g., > certificates issued after that date shall be rejected). > > Does such extension exists today ? If not, could this be some work > for LAMPS/SPASM WG ? > > Cheers, > Max > > -- > > Best Regards, > > Massimiliano Pala, Ph.D. > OpenCA Labs Director > > OpenCA Logo > > > > > _______________________________________________ > > pkix mailing list > > pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------4E0C15D749F443F6FFB9C485 Content-Type: multipart/related; boundary="------------A9A3A470628B9E1B1541DD35" --------------A9A3A470628B9E1B1541DD35 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Erik,

Would the proposed approach provide the possibility to scope only one type of usage (which would work for my case... but maybe there might be other usages that could be restricted) ? Could you make an example of how it would look like ?

Thanks,
Max


On 7/17/17 5:41 PM, Erik Andersen wrote:

Hi Max,

 

Would adding an optional key usage component after the extension mark solve the issue?

 

Regards,

 

Erik

 

Fra: pkix [mailto:pkix-bounces@ietf.org] På vegne af Dr. Pala
Sendt: 17 July 2017 17:17
Til: pkix@ietf.org
Emne: Re: [pkix] Managing Long-Lived CA certs

 

Hi Eric,

thanks, however this does not solve the issue I am trying to address - it would be great if we would have it scoped. For example (not aiming at correctness here.. :D):

privateKeyUsageTypes ::= CHOICE {
   anyPurpose,
   certificateSigning,
   ... 
}
scopedPrivateKeyUsagePeriod ::= SEQUENCE {
   scope           privateKeyUsageTypes,
   notBefore   [0] GeneralizedTime OPTIONAL,
   notAfter    [1] GeneralizedTime OPTIONAL
}
 
privateKeyUsageRestrictions ::= SET OF scopedPrivateKeyUsagePeriod
 

Of course, this is just an example :-D

Cheers,
Max

On 7/17/17 5:04 PM, Erik Andersen wrote:

Hi Massimiliano,

 

What about the private key usage period extension. It was clarified in the latest edition of X.509:

 

9.2.2.5     Private key usage period extension

This extension indicates the period of use of the private key corresponding to the certified public key. It is applicable only for private key used for creating digital signatures. This extension is defined as follows:

 

privateKeyUsagePeriod EXTENSION ::= {

  SYNTAX         PrivateKeyUsagePeriod

  IDENTIFIED BY  id-ce-privateKeyUsagePeriod }

 

PrivateKeyUsagePeriod ::= SEQUENCE {

  notBefore  [0]  GeneralizedTime OPTIONAL,

  notAfter   [1]  GeneralizedTime OPTIONAL,

  ... }

  (WITH COMPONENTS {..., notBefore  PRESENT } |

   WITH COMPONENTS {..., notAfter   PRESENT } )

The notBefore component indicates the earliest date and time at which the private key may be used for signing. If the notBefore component is not present, then no information is provided as to when the period of valid use of the private key commences beyond that specified in the validity component of the public-key certificate. The notAfter component indicates the latest date and time at which the private key may be used for signing. If the notAfter component is not present then no information is provided as to when the period of valid use of the private key concludes beyond that specified in the validity component of the public-key certificate.

This extension shall always be flagged as non-critical.

NOTE 1 – The period of valid use of the private key may be different from the certified validity of the public key as indicated by the public-key certificate validity period. The usage period for the private key used for signing is typically shorter than that for the public key used for verifying the signature.

NOTE  2 – The period of use of the private key corresponding to a public key can only be enforced if both the private key and the corresponding public-key certificate are placed in a tamper-resistant hardware module that contains a reliable clock synchronized with UTC. When this is not the case, a signer may avoid using a signing private key up to the very end of the validity period of the public-key certificate. This is one possible use of this extension.

NOTE 3 – In general, this Specification does not associate any semantic with this extension. Any particular use of this extension will have to specify the semantic associated with that usage.

 

 

Fra: pkix [mailto:pkix-bounces@ietf.org] På vegne af Dr. Pala
Sendt: 17 July 2017 16:20
Til: pkix@ietf.org
Emne: [pkix] Managing Long-Lived CA certs

 

Hi PKIX,

I have a small question for the list regarding long-lived CA certificates. Especially in the context of device certificates, we often see the use of extra long-lived certificates for Root and Sub CAs (e.g., 35+ years) combined with limited key sizes (e.g., p256).

Until we have a supported mechanism for reprovisioning devices (...), one possible solution for limiting the exposure of the private key would be to have a scoped certificate issuance period.

What I am thinking about would be adding an extension that says: "This CA can issue certificates from up to 5 years from the validFrom, after this, just use it to provide revocation information". This might provide some protection in case the CA key is compromised after the initial 5 years of validity (e.g., certificates issued after that date shall be rejected).

Does such extension exists today ? If not, could this be some work for LAMPS/SPASM WG ?

Cheers,
Max

--

Best Regards,

Massimiliano Pala, Ph.D.
OpenCA Labs Director

OpenCA Logo




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

 



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

--------------A9A3A470628B9E1B1541DD35 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="image001.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= --------------A9A3A470628B9E1B1541DD35-- --------------4E0C15D749F443F6FFB9C485-- From nobody Mon Jul 17 09:05:36 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6931A131C71 for ; Mon, 17 Jul 2017 09:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WwiVBHIjPs7 for ; Mon, 17 Jul 2017 09:05:33 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8A412711E for ; Mon, 17 Jul 2017 09:05:33 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id 21so34663210qtx.3 for ; Mon, 17 Jul 2017 09:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-language:thread-index; bh=MTBmR2umt3oiWGU3Rz0xwjp4YHX/up3ReMIcsZqQP9s=; b=CSSZyvjIZrF1/0+YWwCzgy5FDJUqTD+wtOpwtpJN9qL4ngN/XeZhnHcWOtwvmWDROd c826HstupAwOI/Ak2nivaSkEwqQh0UgWUmfLjvAHTc4JmNIT55KehLO9C2Agp0qDuely VtFkTJifmZ+9p/h84gE2o9qkhufO7+AKejG4haQ+PvAnhtcfyUot5FC6vWkXcXEuIlTi ogbae7cbXRdF1lunH1GbOElnbfb2ZGE96BPehLZcHBBSciWOqTy3gAedQtRLSQCYQ+UL 2C+jfmIYoVGTf9+C71fygtYkMbrP8ZjhRVXJNc/RJljMviD04zUWiu7m4/M7WBNt3Lqf I4sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=MTBmR2umt3oiWGU3Rz0xwjp4YHX/up3ReMIcsZqQP9s=; b=qTcLjtY3XAhD/IiwGjpSWVEz8cDxxzTldDaCT+6b2hDKRxF7VFlrsPnSjxzOipEtLy hYJS9IshiOEWZD7uZd/bXPtkIAXvA/sDBARZ+91JPyoSCMrm++Tn9wEshkAnYMlyjGHX BayN8ceCIjbwhUyvskjwxsaq0TKqau9iJb++JouSPrV8o5PbWDo+Enx/r9rcPCGFqXoK WrM4Rjd8zBM8JhBueKEYCgi5e1HGTWVxAZtSRMKs3U84jpdXEy8ypt2lcefaRF4c+smG RkRMw3LaQcvGwMlUXPcRXJuWZzUy4DUA39L1giV3nSZRTu2Uunphxe99Zbqfy9Exqadd sxLw== X-Gm-Message-State: AIVw113bjo5mBAECsDee8mAtLRjBinTITdy/LVMqmnn8VBO2YJ0yQujv 4kp5zqPWpIeAbg== X-Received: by 10.237.63.9 with SMTP id p9mr7015252qtf.81.1500307532319; Mon, 17 Jul 2017 09:05:32 -0700 (PDT) Received: from SantoshBrain (pool-96-255-227-53.washdc.fios.verizon.net. [96.255.227.53]) by smtp.gmail.com with ESMTPSA id f37sm3123840qtb.43.2017.07.17.09.05.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 09:05:31 -0700 (PDT) From: "Santosh Chokhani" To: "'Dr. Pala'" , References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <4c3aadcc-7ed0-5f60-640c-93a11cb718bc@openca.org> <002c01d2ff13$2add1880$80974980$@x500.eu> <258f8448-bf8d-3ef7-3145-9a13f2ec5ea6@openca.org> In-Reply-To: <258f8448-bf8d-3ef7-3145-9a13f2ec5ea6@openca.org> Date: Mon, 17 Jul 2017 12:05:30 -0400 Message-ID: <112201d2ff16$838105c0$8a831140$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_1123_01D2FEF4.FC71D6C0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQDOcHAtNaigQtZhTsCOwy8a/DXXLwJG2NRHAZgK4ccBUOq5GAGdQrAXpCrgwKA= Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:05:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1123_01D2FEF4.FC71D6C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_1124_01D2FEF4.FC71D6C0" ------=_NextPart_001_1124_01D2FEF4.FC71D6C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree with Carl. =20 I do not see a benefit to this request. The rogue party will simply = pre-date the certificates. One could argue that temporal window of = vulnerability is reduced via this extension. But, that can and should = be easily accommodated by the PKI Engineering. If the CA is supposed to = cut certificates for X years and maximum validity is Y, the CA = certificate should not be valid for X + Y in the first place since all = certificates signed will expire by then. =20 From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Dr. Pala Sent: Monday, July 17, 2017 11:53 AM To: pkix@ietf.org Subject: Re: [pkix] Managing Long-Lived CA certs =20 Hi Erik, Would the proposed approach provide the possibility to scope only one = type of usage (which would work for my case... but maybe there might be = other usages that could be restricted) ? Could you make an example of = how it would look like ? Thanks, Max =20 On 7/17/17 5:41 PM, Erik Andersen wrote: Hi Max, =20 Would adding an optional key usage component after the extension mark = solve the issue? =20 Regards, =20 Erik =20 Fra: pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af Dr. Pala Sendt: 17 July 2017 17:17 Til: pkix@ietf.org =20 Emne: Re: [pkix] Managing Long-Lived CA certs =20 Hi Eric, thanks, however this does not solve the issue I am trying to address - = it would be great if we would have it scoped. For example (not aiming at = correctness here.. :D): privateKeyUsageTypes ::=3D CHOICE { anyPurpose, certificateSigning, ...=20 } scopedPrivateKeyUsagePeriod ::=3D SEQUENCE { scope privateKeyUsageTypes, notBefore [0] GeneralizedTime OPTIONAL, notAfter [1] GeneralizedTime OPTIONAL } =20 privateKeyUsageRestrictions ::=3D SET OF scopedPrivateKeyUsagePeriod =20 Of course, this is just an example :-D Cheers, Max On 7/17/17 5:04 PM, Erik Andersen wrote: Hi Massimiliano, =20 What about the private key usage period extension. It was clarified in = the latest edition of X.509: =20 9.2.2.5 Private key usage period extension This extension indicates the period of use of the private key = corresponding to the certified public key. It is applicable only for = private key used for creating digital signatures. This extension is = defined as follows: =20 privateKeyUsagePeriod EXTENSION ::=3D { SYNTAX PrivateKeyUsagePeriod IDENTIFIED BY id-ce-privateKeyUsagePeriod } =20 PrivateKeyUsagePeriod ::=3D SEQUENCE { notBefore [0] GeneralizedTime OPTIONAL, notAfter [1] GeneralizedTime OPTIONAL, ... } (WITH COMPONENTS {..., notBefore PRESENT } | WITH COMPONENTS {..., notAfter PRESENT } ) The notBefore component indicates the earliest date and time at which = the private key may be used for signing. If the notBefore component is = not present, then no information is provided as to when the period of = valid use of the private key commences beyond that specified in the = validity component of the public-key certificate. The notAfter component = indicates the latest date and time at which the private key may be used = for signing. If the notAfter component is not present then no = information is provided as to when the period of valid use of the = private key concludes beyond that specified in the validity component of = the public-key certificate. This extension shall always be flagged as non-critical. NOTE 1 =E2=80=93 The period of valid use of the private key may be = different from the certified validity of the public key as indicated by = the public-key certificate validity period. The usage period for the = private key used for signing is typically shorter than that for the = public key used for verifying the signature. NOTE 2 =E2=80=93 The period of use of the private key corresponding to = a public key can only be enforced if both the private key and the = corresponding public-key certificate are placed in a tamper-resistant = hardware module that contains a reliable clock synchronized with UTC. = When this is not the case, a signer may avoid using a signing private = key up to the very end of the validity period of the public-key = certificate. This is one possible use of this extension. NOTE 3 =E2=80=93 In general, this Specification does not associate any = semantic with this extension. Any particular use of this extension will = have to specify the semantic associated with that usage. =20 =20 Fra: pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af Dr. Pala Sendt: 17 July 2017 16:20 Til: pkix@ietf.org =20 Emne: [pkix] Managing Long-Lived CA certs =20 Hi PKIX, I have a small question for the list regarding long-lived CA = certificates. Especially in the context of device certificates, we often = see the use of extra long-lived certificates for Root and Sub CAs (e.g., = 35+ years) combined with limited key sizes (e.g., p256). Until we have a supported mechanism for reprovisioning devices (...), = one possible solution for limiting the exposure of the private key would = be to have a scoped certificate issuance period. What I am thinking about would be adding an extension that says: "This = CA can issue certificates from up to 5 years from the validFrom, after = this, just use it to provide revocation information". This might provide = some protection in case the CA key is compromised after the initial 5 = years of validity (e.g., certificates issued after that date shall be = rejected). Does such extension exists today ? If not, could this be some work for = LAMPS/SPASM WG ? Cheers, Max --=20 Best Regards,=20 Massimiliano Pala, Ph.D. OpenCA Labs Director _______________________________________________ pkix mailing list pkix@ietf.org =20 https://www.ietf.org/mailman/listinfo/pkix =20 _______________________________________________ pkix mailing list pkix@ietf.org =20 https://www.ietf.org/mailman/listinfo/pkix =20 ------=_NextPart_001_1124_01D2FEF4.FC71D6C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I agree with Carl.

 

I do not see a benefit to this request.=C2=A0 The rogue party will = simply pre-date the certificates.=C2=A0 One could argue that temporal = window of vulnerability is reduced via this extension.=C2=A0 But, that = can and should be easily accommodated by the PKI Engineering.=C2=A0 If = the CA is supposed to cut certificates for X years and maximum validity = is Y, the CA certificate should not be valid for X + Y in the first = place since all certificates signed will expire by = then.

 

From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Dr. = Pala
Sent: Monday, July 17, 2017 11:53 AM
To: = pkix@ietf.org
Subject: Re: [pkix] Managing Long-Lived CA = certs

 

Hi = Erik,

Would the proposed approach provide the = possibility to scope only one type of usage (which would work for my = case... but maybe there might be other usages that could be restricted) = ? Could you make an example of how it would look like = ?

Thanks,
Max

 

On = 7/17/17 5:41 PM, Erik Andersen wrote:

Hi Max,

 

Would adding an optional key usage component after the extension mark = solve the issue?

 

Regards,

 

Erik

 

Fra: pkix [mailto:pkix-bounces@ietf.org] = P=C3=A5 vegne af Dr. Pala
Sendt: 17 July 2017 = 17:17
Til: pkix@ietf.org
Emne: Re: = [pkix] Managing Long-Lived CA certs

 

Hi = Eric,

thanks, however this does not solve the issue I = am trying to address - it would be great if we would have it scoped. For = example (not aiming at correctness here.. = :D):

privateKeyUsageTypes ::=3D CHOICE =
{
   =
anyPurpose,
   =
certificateSigning,
   ... =

}
scopedPrivateKeyUsagePeriod =
::=3D SEQUENCE {
   =
scope           =
privateKeyUsageTypes,
   =
notBefore   [0] GeneralizedTime =
OPTIONAL,
   notAfter    =
[1] GeneralizedTime =
OPTIONAL
}
 
privateKeyUsageRestrictions ::=3D SET OF =
scopedPrivateKeyUsagePeriod
 
<=
p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>Of course, this is =
just an example :-D

Cheers,
Max
On 7/17/17 5:04 PM, Erik Andersen =
wrote:
Hi Massimiliano,
 
What about the private key usage period extension. It was clarified in =
the latest edition of X.509:
 
9.2.2.5     Private key =
usage period extension
This =
extension indicates the period of use of the private key corresponding =
to the certified public key. It is applicable only for private key used =
for creating digital signatures. This extension is defined as =
follows:
 
privateKeyUsagePeriod EXTENSION ::=3D {
  =
SYNTAX         =
PrivateKeyUsagePeriod
  IDENTIFIED =
BY  id-ce-privateKeyUsagePeriod }
 
PrivateKeyUsagePeriod =
::=3D SEQUENCE {
  notBefore  =
[0]  GeneralizedTime OPTIONAL,
  =
notAfter   [1]  GeneralizedTime =
OPTIONAL,
  ... }
  (WITH COMPONENTS {..., notBefore  PRESENT } =
|
   WITH COMPONENTS {..., =
notAfter   PRESENT } )
The =
notBefore component indicates =
the earliest date and time at which the private key may be used for =
signing. If the notBefore component is not =
present, then no information is provided as to when the period of valid =
use of the private key commences beyond that specified in the validity =
component of the public-key certificate. The notAfter =
component indicates the latest date and time at which the =
private key may be used for signing. If the notAfter component is not =
present then no information is provided as to when the period of valid =
use of the private key concludes beyond that specified in the validity =
component of the public-key certificate.
This extension shall always be flagged as =
non-critical.
NOTE 1 =E2=80=93 The period of valid use of =
the private key may be different from the certified validity of the =
public key as indicated by the public-key certificate validity period. =
The usage period for the private key used for signing is typically =
shorter than that for the public key used for verifying the =
signature.
NOTE =
 2 =E2=80=93 The period of use of the private key =
corresponding to a public key can only be enforced if both the private =
key and the corresponding public-key certificate are placed in a =
tamper-resistant hardware module that contains a reliable clock =
synchronized with UTC. When this is not the case, a signer may avoid =
using a signing private key up to the very end of the validity period of =
the public-key certificate. This is one possible use of this =
extension.
NOTE 3 =E2=80=93 In general, this =
Specification does not associate any semantic with this extension. Any =
particular use of this extension will have to specify the semantic =
associated with that usage.
 
 
Fra: pkix [mailto:pkix-bounces@ietf.org] =
P=C3=A5 vegne af Dr. Pala
Sendt: 17 July 2017 =
16:20
Til: pkix@ietf.org
Emne: [pkix] =
Managing Long-Lived CA certs
 
Hi PKIX,
I =
have a small question for the list regarding long-lived CA certificates. =
Especially in the context of device certificates, we often see the use =
of extra long-lived certificates for Root and Sub CAs (e.g., 35+ years) =
combined with limited key sizes (e.g., p256).
Until we =
have a supported mechanism for reprovisioning devices (...), one =
possible solution for limiting the exposure of the private key would be =
to have a scoped certificate issuance period.
What I am =
thinking about would be adding an extension that says: "This CA can =
issue certificates from up to 5 years from the validFrom, after this, =
just use it to provide revocation information". This might provide =
some protection in case the CA key is compromised after the initial 5 =
years of validity (e.g., certificates issued after that date shall be =
rejected).
Does such extension exists today ? If not, =
could this be some work for LAMPS/SPASM WG =
?
Cheers,
Max
-- 
Best Regards, 
Massimiliano Pala, =
Ph.D.
OpenCA Labs Director
3D"OpenCA





___________________=
____________________________
pkix mailing =
list
pkix@ietf.org
https://www.ietf.org/=
mailman/listinfo/pkix
 



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

 

------=_NextPart_001_1124_01D2FEF4.FC71D6C0-- ------=_NextPart_000_1123_01D2FEF4.FC71D6C0 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/ MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp 7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91 aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6 yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV 2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7 QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7 qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6 vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP 7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90 1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K +f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA AAAASUVORK5CYII= ------=_NextPart_000_1123_01D2FEF4.FC71D6C0-- From nobody Mon Jul 17 09:29:12 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEA1131C95 for ; Mon, 17 Jul 2017 09:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.343 X-Spam-Level: X-Spam-Status: No, score=-0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, 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 n7MfJgH7dLT3 for ; Mon, 17 Jul 2017 09:29:09 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id B75DD128BC8 for ; Mon, 17 Jul 2017 09:29:08 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 117123740A29 for ; Mon, 17 Jul 2017 12:29:07 -0400 (EDT) To: pkix@ietf.org References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <8fee3040-d629-762b-f5b0-b8e770911639@openca.org> Date: Mon, 17 Jul 2017 18:29:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1DB84F40E49D16D7D75E23E2" Content-Language: en-US Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:29:10 -0000 This is a multi-part message in MIME format. --------------1DB84F40E49D16D7D75E23E2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Carl, you are totally right :D That case would be covered by the revocation of the CA key. However, there are also other types of compromises (e.g., the system is compromised, but the key is not - certificates issued by non-authorized person). Keep in mind that in the ecosystem where this happens (device certs and many others) certificate revocation is not really checked... this would limit the exposure for non-catastrophic compromise events. Does this make sense ? What do you think ? Cheers, Max [*] = I know that checking revocation is still, regrettably, not common... On 7/17/17 5:42 PM, Carl Wallace wrote: > [...] > [CW] Wouldn't the protection need to come in the form of revocation? > If the CA key is compromised, the validity period in certificates > cannot be trusted. [...] -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------1DB84F40E49D16D7D75E23E2 Content-Type: multipart/related; boundary="------------DF084C35646C10D43EE35F05" --------------DF084C35646C10D43EE35F05 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi Carl,

you are totally right :D That case would be covered by the revocation of the CA key. However, there are also other types of compromises (e.g., the system is compromised, but the key is not - certificates issued by non-authorized person).

Keep in mind that in the ecosystem where this happens (device certs and many others) certificate revocation is not really checked... this would limit the exposure for non-catastrophic compromise events.

Does this make sense ? What do you think ?

Cheers,
Max

[*] = I know that checking revocation is still, regrettably, not common...

On 7/17/17 5:42 PM, Carl Wallace wrote:
[...]
[CW] Wouldn't the protection need to come in the form of revocation? If the CA key is compromised, the validity period in certificates cannot be trusted. [...]

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------DF084C35646C10D43EE35F05 Content-Type: image/png; name="pdeedbnagofkbcmj.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="pdeedbnagofkbcmj.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= --------------DF084C35646C10D43EE35F05-- --------------1DB84F40E49D16D7D75E23E2-- From nobody Mon Jul 17 09:46:59 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9839B131B33 for ; Mon, 17 Jul 2017 09:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX7UQ5Zwkoe2 for ; Mon, 17 Jul 2017 09:46:56 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87CA7131B48 for ; Mon, 17 Jul 2017 09:46:56 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id d78so125112100qkb.1 for ; Mon, 17 Jul 2017 09:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=Bjx5PUP2C0qwUORUF9NEX+86msfO76bloUAThmDewyw=; b=hHG9qLEAitDoLYbTvh030sGCvEoBbixn0xq1oYmaPjuqynvVRr6sPGq+nTTffqENej uSOehoq+5NbDE94AHTGG2YhBKgiYtgGPqsBc1nMF3kzQy5QRz4ui1sHDXwfWaVU5mV7C 5FN6vXrgTwB+G4xcfCNOvJM6P1bdlibh56z2k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=Bjx5PUP2C0qwUORUF9NEX+86msfO76bloUAThmDewyw=; b=TnoeNV90nYQI+jmvQlH2trWG4fI+xt6JB14hMSIyVerOGwd4BZQYl/MfZCpq9JWqqf gnIzaPohcaOwsVNJYVBYQvzWIc9AGg0JHvk6J0KlZT+wa5Yg2vs73tTxXWY8k84bntEX Fc5TnAXEEaez9ob2bkUId8ZbTc/7AykZxs8ca+GZGkWyygenFIxRL7Nch0VXPEqCLoA0 I3wcSQQfb1zGE0qjDh/xrJJKk9lA7npvnbVOGFb1k3G/Sycnx7mXiaOtSklTx9+K93Zh 6Q2fDYprYjJuTbBeF3OLEoLGnQoVF535EWV1HbUWa8Czxcvt+BERet5x32d/GQm4NsXo S/kA== X-Gm-Message-State: AIVw113INg2tMaCm5KsDEgt6+syhd88O71whQAMG7HVx25ctrJDaRZWR 2LQOZ5J8JHceX56U X-Received: by 10.55.23.231 with SMTP id 100mr26672666qkx.67.1500310015608; Mon, 17 Jul 2017 09:46:55 -0700 (PDT) Received: from [192.168.2.27] (pool-173-66-76-215.washdc.fios.verizon.net. [173.66.76.215]) by smtp.googlemail.com with ESMTPSA id s24sm834798qtc.7.2017.07.17.09.46.54 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 17 Jul 2017 09:46:55 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.4.170508 Date: Mon, 17 Jul 2017 12:46:51 -0400 From: Carl Wallace To: "Dr. Pala" , Message-ID: Thread-Topic: [pkix] Managing Long-Lived CA certs References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <8fee3040-d629-762b-f5b0-b8e770911639@openca.org> In-Reply-To: <8fee3040-d629-762b-f5b0-b8e770911639@openca.org> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3583140414_15259628" Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:46:58 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3583140414_15259628 Content-type: multipart/alternative; boundary="B_3583140414_15244361" --B_3583140414_15244361 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable If the system is compromised, revoke all issued certs since you stopped using the key (assuming the system compromise isn't such that your efforts can be undone by the attacker). You could do this fairly easily with OCSP and a whitelist of issued certs generated when the private key stops being used for certificates. That begs a different question. What about responder certs? Would there be a loophole for those? The upside feels light relative to the challenge of updating path validatio= n implementations and I tend to doubt enough implementations would pick this up to obviate the need for one of the above steps anyway =E2=80=93 especially whe= n considering a target is implementations that are already incomplete. From: pkix on behalf of "Dr. Pala" Organization: OpenCA Labs Date: Monday, July 17, 2017 at 12:29 PM To: Subject: Re: [pkix] Managing Long-Lived CA certs > =20 > =20 >=20 > Hi Carl, > =20 >=20 > you are totally right :D That case would be covered by the revocation of = the > CA key. However, there are also other types of compromises (e.g., the sys= tem > is compromised, but the key is not - certificates issued by non-authorize= d > person). > =20 >=20 > Keep in mind that in the ecosystem where this happens (device certs and m= any > others) certificate revocation is not really checked... this would limit = the > exposure for non-catastrophic compromise events. > =20 >=20 > Does this make sense ? What do you think ? > =20 >=20 > Cheers, > Max > [*] =3D I know that checking revocation is still, regrettably, not common.= .. > =20 > =20 > On 7/17/17 5:42 PM, Carl Wallace wrote: > =20 > =20 >> [...]=20 >> [CW] Wouldn't the protection need to come in the form of revocation? If = the >> CA key is compromised, the validity period in certificates cannot be tru= sted. >> [...] >> =20 > =20 > =20 > --=20 > =20 > Best Regards,=20 > Massimiliano Pala, Ph.D. > OpenCA Labs Director > =20 > =20 > =20 > =20 > =20 > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3583140414_15244361 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
If the system is compromised,= revoke all issued certs since you stopped using the key (assuming the syste= m compromise isn't such that your efforts can be undone by the attacker). Yo= u could do this fairly easily with OCSP and a whitelist of issued certs gene= rated when the private key stops being used for certificates. That begs a di= fferent question. What about responder certs? Would there be a loophole for = those?

The upside feels light relative to the chall= enge of updating path validation implementations and I tend to doubt enough = implementations would pick this up to obviate the need for one of the above = steps anyway – especially when considering a target is implementations= that are already incomplete. 

From: pkix <pkix-b= ounces@ietf.org> on behalf of "Dr. Pala" <director@openca.org>
O= rganization: OpenCA Labs
Date: Monday, July 17, 2017 at 12:29 PM
To:= <pkix@ietf.org>
Subject: Re: [pkix] Managing Long-Lived CA c= erts

=

Hi Carl,

you are totally right :D That case would be covered by the revocation of the CA key. However, there are also other types of compromises (e.g., the system is compromised, but the key is not - certificates issued by non-authorized person).

Keep in mind that in the ecosystem where this happens (device certs and many others) certificate revocation is not really checked... this would limit the exposure for non-catastrophic compromise events.

Does this make sense ? What do you think ?

Cheers,
Max

[*] =3D I know that checking revocation is still, regrettably, not common...

On 7/17/17 5:42 PM, Carl Wallace wrote:
[...]
[CW] Wouldn't the protection need to come in the form of revocation? If the CA key is compromised, the validity period in certificates cannot be trusted. [...]

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3583140414_15244361-- --B_3583140414_15259628 Content-type: image/png; name="pdeedbnagofkbcmj.png" Content-ID: Content-disposition: inline; filename="pdeedbnagofkbcmj.png" Content-transfer-encoding: base64 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= --B_3583140414_15259628-- From nobody Mon Jul 17 09:58:45 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CDB131C1F for ; Mon, 17 Jul 2017 09:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_vDF5tAM57m for ; Mon, 17 Jul 2017 09:58:41 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 34DC5131B4E for ; Mon, 17 Jul 2017 09:58:41 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id F1B783740A29; Mon, 17 Jul 2017 12:58:39 -0400 (EDT) To: Carl Wallace , pkix@ietf.org References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <8fee3040-d629-762b-f5b0-b8e770911639@openca.org> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <4ce36bdb-a441-a3cf-8a2b-5ef1ff3f6bb3@openca.org> Date: Mon, 17 Jul 2017 18:58:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------923C5C7E47AA402107EAEE25" Content-Language: en-US Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:58:43 -0000 This is a multi-part message in MIME format. --------------923C5C7E47AA402107EAEE25 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Carl, all, yes, I agree with you that in a perfect world that would work... but lightbulbs and other small IoT will probably never do any OCSP.. so, this proposal is to address a problem that we are already seeing today and that device manufacturer are not really equipped to address and/or even understand it. It is not a perfect solution, but a possible mitigation.. :D What I understand from all the responses is that today nothing really exists, and there might be space for a simple proposal.. maybe in LAMPS or as an individual contribution. I personally think there is value for the IoT / Devices environment. Thanks everybody for your replies! Cheers, Max On 7/17/17 6:46 PM, Carl Wallace wrote: > If the system is compromised, revoke all issued certs since you > stopped using the key (assuming the system compromise isn't such that > your efforts can be undone by the attacker). You could do this fairly > easily with OCSP and a whitelist of issued certs generated when the > private key stops being used for certificates. That begs a different > question. What about responder certs? Would there be a loophole for those? > > The upside feels light relative to the challenge of updating path > validation implementations and I tend to doubt enough implementations > would pick this up to obviate the need for one of the above steps > anyway – especially when considering a target is implementations that > are already incomplete. > > From: pkix > on > behalf of "Dr. Pala" > > Organization: OpenCA Labs > Date: Monday, July 17, 2017 at 12:29 PM > To: > > Subject: Re: [pkix] Managing Long-Lived CA certs > > Hi Carl, > > you are totally right :D That case would be covered by the > revocation of the CA key. However, there are also other types of > compromises (e.g., the system is compromised, but the key is not - > certificates issued by non-authorized person). > > Keep in mind that in the ecosystem where this happens (device > certs and many others) certificate revocation is not really > checked... this would limit the exposure for non-catastrophic > compromise events. > > Does this make sense ? What do you think ? > > Cheers, > Max > > [*] = I know that checking revocation is still, regrettably, not > common... > > On 7/17/17 5:42 PM, Carl Wallace wrote: >> [...] >> [CW] Wouldn't the protection need to come in the form of >> revocation? If the CA key is compromised, the validity period in >> certificates cannot be trusted. [...] > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > OpenCA Logo > _______________________________________________ pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------923C5C7E47AA402107EAEE25 Content-Type: multipart/related; boundary="------------78A7788D17485D677228BEBD" --------------78A7788D17485D677228BEBD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Carl, all,

yes, I agree with you that in a perfect world that would work... but lightbulbs and other small IoT will probably never do any OCSP.. so, this proposal is to address a problem that we are already seeing today and that device manufacturer are not really equipped to address and/or even understand it.

It is not a perfect solution, but a possible mitigation.. :D

What I understand from all the responses is that today nothing really exists, and there might be space for a simple proposal.. maybe in LAMPS or as an individual contribution. I personally think there is value for the IoT / Devices environment.

Thanks everybody for your replies!

Cheers,
Max


On 7/17/17 6:46 PM, Carl Wallace wrote:
If the system is compromised, revoke all issued certs since you stopped using the key (assuming the system compromise isn't such that your efforts can be undone by the attacker). You could do this fairly easily with OCSP and a whitelist of issued certs generated when the private key stops being used for certificates. That begs a different question. What about responder certs? Would there be a loophole for those?

The upside feels light relative to the challenge of updating path validation implementations and I tend to doubt enough implementations would pick this up to obviate the need for one of the above steps anyway – especially when considering a target is implementations that are already incomplete. 

From: pkix <pkix-bounces@ietf.org> on behalf of "Dr. Pala" <director@openca.org>
Organization: OpenCA Labs
Date: Monday, July 17, 2017 at 12:29 PM
To: <pkix@ietf.org>
Subject: Re: [pkix] Managing Long-Lived CA certs

Hi Carl,

you are totally right :D That case would be covered by the revocation of the CA key. However, there are also other types of compromises (e.g., the system is compromised, but the key is not - certificates issued by non-authorized person).

Keep in mind that in the ecosystem where this happens (device certs and many others) certificate revocation is not really checked... this would limit the exposure for non-catastrophic compromise events.

Does this make sense ? What do you think ?

Cheers,
Max

[*] = I know that checking revocation is still, regrettably, not common...

On 7/17/17 5:42 PM, Carl Wallace wrote:
[...]
[CW] Wouldn't the protection need to come in the form of revocation? If the CA key is compromised, the validity period in certificates cannot be trusted. [...]

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------78A7788D17485D677228BEBD Content-Type: image/png; name="bdefnmdkgfehkkjl.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="bdefnmdkgfehkkjl.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= --------------78A7788D17485D677228BEBD-- --------------923C5C7E47AA402107EAEE25-- From nobody Mon Jul 17 20:31:56 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D9212ECCE for ; Mon, 17 Jul 2017 20:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZaUjAUZpoNQ for ; Mon, 17 Jul 2017 20:31:52 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD98126B6E for ; Mon, 17 Jul 2017 20:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1500348712; x=1531884712; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XzPMkIZke9kVURYAQeHr/TlT8gy+3lc82iUg9lqIWng=; b=YYmQGYdmZE6FPwvJcZpRLJ930tCHVWjmlw+2tyHaP9ySDUt2RkHhKloX 9x9sqEK9qaY+gqUnFgqVkw8z+exDBFDxv/ptrF5q/DAUSzzAgQDxB7W0C +igmPDqpAt3i9bR7SZ+PThynyTBCqRfmoRjwq/BIxdt4cxf040pu08PIq 4OW92A25im7UuqXd26Nl96jDHutqHecOndKrU61RV8Tf6x/mGw6PHZE5l eUkxWb9FQwd1+BuRjVJj50DrYDw4TYguZqr1zfwA4fqVmaOw/kr3OyCUG 5ixKU1rkL4aDsdeEUzuheTI5uzbAn9swgUg/ymH2nENDVLXf9ct4KXOF1 A==; X-IronPort-AV: E=Sophos;i="5.40,376,1496059200"; d="scan'208";a="166174983" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Jul 2017 15:31:47 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 18 Jul 2017 15:31:47 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Tue, 18 Jul 2017 15:31:47 +1200 From: Peter Gutmann To: Erik Andersen , PKIX Thread-Topic: [pkix] Managing Long-Lived CA certs Thread-Index: AQHS/wfFsHzAHG/6DUqwsYmxTQJgoKJXVMeAgAGZvr0= Date: Tue, 18 Jul 2017 03:31:46 +0000 Message-ID: <1500348690922.69356@cs.auckland.ac.nz> References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org>, <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> In-Reply-To: <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 03:31:55 -0000 Erik Andersen writes:=0A= =0A= >What about the private key usage period extension=0A= =0A= That would be the obvious choice, but PKIX says you're not allowed to use i= t.=0A= No reason given, you just can't. This would imply that support for it in= =0A= implementations is going to be hard to find...=0A= =0A= Peter.=0A= =0A= =0A= =0A= =0A= From nobody Mon Jul 17 23:00:44 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FFA129B43 for ; Mon, 17 Jul 2017 23:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raTosi-pfAyw for ; Mon, 17 Jul 2017 23:00:41 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) (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 0E9C8129459 for ; Mon, 17 Jul 2017 23:00:40 -0700 (PDT) Received: from Morten ([62.44.134.67]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id 3201707180800374212 for ; Tue, 18 Jul 2017 08:00:37 +0200 From: "Erik Andersen" To: "'PKIX'" References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org>, <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> In-Reply-To: <1500348690922.69356@cs.auckland.ac.nz> Date: Tue, 18 Jul 2017 08:00:36 +0200 Message-ID: <001801d2ff8b$2cd3a2d0$867ae870$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDOcHAtNaigQtZhTsCOwy8a/DXXLwJG2NRHAgHCn8GkP+8tYA== Content-Language: en-gb Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 06:00:43 -0000 Hi Peter, We live in a very changeable world. Today's implementations are junk tomorrow. If we are not allowed to do anything that is not supported by current implementations, it is like trying to stop the world. Erik -----Oprindelig meddelelse----- Fra: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] Sendt: 18 July 2017 05:32 Til: Erik Andersen ; PKIX Emne: Re: [pkix] Managing Long-Lived CA certs Erik Andersen writes: >What about the private key usage period extension That would be the obvious choice, but PKIX says you're not allowed to use it. No reason given, you just can't. This would imply that support for it in implementations is going to be hard to find... Peter. = From nobody Tue Jul 18 07:03:59 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9D413178E for ; Tue, 18 Jul 2017 07:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgMJboQpYXGH for ; Tue, 18 Jul 2017 07:03:55 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152A613167D for ; Tue, 18 Jul 2017 07:03:54 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 18 Jul 2017 10:03:50 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Tue, 18 Jul 2017 10:03:52 -0400 Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v6IE3PjF031505; Tue, 18 Jul 2017 10:03:25 -0400 To: Peter Gutmann References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> From: "David A. Cooper" CC: PKIX Message-ID: <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> Date: Tue, 18 Jul 2017 10:03:25 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1500348690922.69356@cs.auckland.ac.nz> Content-Type: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-NIST-MailScanner-Information: Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:03:57 -0000
Can you provide a citation for your claim that "PKIX says you're not allowed to use it. No reason given, you just can't."?

RFC 5280 says:
This specification obsoletes [RFC3280].  Differences from RFC 3280 are summarized below:

      * Section 4.2.1.4 in RFC 3280, which specified the
        privateKeyUsagePeriod certificate extension but deprecated its
        use, was removed.  Use of this ISO standard extension is neither
        deprecated nor recommended for use in the Internet PKI.
"Use of this ISO standard extension is neither deprecated nor recommended" doesn't sound like "you just can't" to me.

On 07/17/2017 11:31 PM, Peter Gutmann wrote:
Erik Andersen <era@x500.eu> writes:


What about the private key usage period extension

That would be the obvious choice, but PKIX says you're not allowed to use it.
No reason given, you just can't.  This would imply that support for it in
implementations is going to be hard to find...

Peter.
From nobody Tue Jul 18 07:17:33 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E121286B2 for ; Tue, 18 Jul 2017 07:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs4wq3fR7Nd7 for ; Tue, 18 Jul 2017 07:17:30 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B597812706D for ; Tue, 18 Jul 2017 07:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1500387449; x=1531923449; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PJJhFJs+6v0h/cgU4Q640fXt/AovodJiGq2JnmoAVuc=; b=IyimRhLZJQhi6QEL6IjdfljjZ+wD7V6ZmwAPq3MwOsb9WLHrQk3n2AuQ EkmitX2xxjoB8uwExbcBmo3JMGx3ziX8QKEDmzvuVlqFGStURaOYO0w4H G8DYbB0hxb6tMP9ez2XJxpIUM9rgOVcjcBZLYkctP3hGp7kG7e02VeM0/ RpVMvkOyVhLwffNa1M2S8xG0KAH7fDJJFEpXRZMIsssY4CGruf7j2S+2M faVNoghqArL4EXa48cLYnxAnuOgTQOe98wju1RcZT2mjDCK3MDMGXh9rL RAWrWrYewAnykCFDmRz5cvrLSk/m/a5E607MWsb6kvG4X9GEjmEAWjP3W g==; X-IronPort-AV: E=Sophos;i="5.40,378,1496059200"; d="scan'208";a="166300096" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Jul 2017 02:17:00 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Jul 2017 02:17:00 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Wed, 19 Jul 2017 02:17:00 +1200 From: Peter Gutmann To: "David A. Cooper" CC: PKIX Thread-Topic: [pkix] Managing Long-Lived CA certs Thread-Index: AQHS/wfFsHzAHG/6DUqwsYmxTQJgoKJXVMeAgAGZvr3//+d/gIAAzL86 Date: Tue, 18 Jul 2017 14:16:59 +0000 Message-ID: <1500387403338.42595@cs.auckland.ac.nz> References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz>, <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> In-Reply-To: <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:17:32 -0000 David A. Cooper writes:=0A= =0A= >Can you provide a citation for your claim that "PKIX says you're not allow= ed=0A= >to use it. No reason given, you just can't."?=0A= =0A= Um, the PKIX RFCs for the last twenty years, starting with 2459:=0A= =0A= 4.2.1.4 Private Key Usage Period=0A= =0A= This profile recommends against the use of this extension. CAs=0A= conforming to this profile MUST NOT generate certificates with=0A= critical private key usage period extensions.=0A= =0A= Peter.=0A= =0A= From nobody Tue Jul 18 07:27:23 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6AB131B09 for ; Tue, 18 Jul 2017 07:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Dm-ncy4qk2P for ; Tue, 18 Jul 2017 07:27:20 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.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 672C5131A7D for ; Tue, 18 Jul 2017 07:27:20 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 18 Jul 2017 10:27:59 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Tue, 18 Jul 2017 10:27:18 -0400 Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v6IER8TW000495; Tue, 18 Jul 2017 10:27:08 -0400 To: Peter Gutmann References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <1500387403338.42595@cs.auckland.ac.nz> From: "David A. Cooper" CC: "pkix@ietf.org" Message-ID: Date: Tue, 18 Jul 2017 10:27:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1500387403338.42595@cs.auckland.ac.nz> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-NIST-MailScanner-Information: Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:27:22 -0000 So, you intentionally delete the quote I provided from RFC 5280 saying that use of the private key usage period extension is "neither deprecated nor recommended" so that you can falsely claim that the "PKIX RFCs for the last twenty years" have said the same thing. So, you are trying to claim that "the PKIX RFCs for the last twenty years" have said something, even though you know that RFC 5280, which is 9 years old, doesn't say that. In addition, even the text you quote doesn't support your claim that "PKIX says you're not allowed to use it." Before May 2008, PKIX said that you're not allowed to mark the extension as critical, which is not the same as "not allowed to use it." While PKIX previously recommended against the use of the extension, it has not done so for the past 9 years. On 07/18/2017 10:16 AM, Peter Gutmann wrote: > David A. Cooper writes: > >> Can you provide a citation for your claim that "PKIX says you're not allowed >> to use it. No reason given, you just can't."? > Um, the PKIX RFCs for the last twenty years, starting with 2459: > > 4.2.1.4 Private Key Usage Period > > This profile recommends against the use of this extension. CAs > conforming to this profile MUST NOT generate certificates with > critical private key usage period extensions. > > Peter. > > From nobody Tue Jul 18 08:25:52 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE87D131A7E for ; Tue, 18 Jul 2017 08:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNVtZCxkJbdd for ; Tue, 18 Jul 2017 08:25:49 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD6A131A69 for ; Tue, 18 Jul 2017 08:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1500391549; x=1531927549; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XL6SQGgOCHm2jK367oY/kXZ0IgDqed/reM37SF1hmS8=; b=yeJHbOJJ4MGCDdQgxpAVOyG38R6krzNdntYW9Cz2d//lPbmyqrfIeqjf QbpZAmsPvog1sz5V2ydQvSj+v6AU6EA3Ywb6c2nHN2X676UtVZlxc3vM+ A5elO7Vjnv+UYp5g9zgljguJWcBydmGMMl3QL4mOEoC6+uc1sULBVUWay zz6pM9OLmU0Dkf8WdYWeAawiHAouKlrVnPsOuULnpesaqMle9WWCLmiWm dYlleNlquWXw+v97ojKPzSpOqdwg03y48ReN4VALsoCc2IlE/3eG1wzoh WLI58CFjdkw/2EW70ggJ5I3LwXTL7xSKMifoXzilnBbU9OKJ3gtqdKA1y g==; X-IronPort-AV: E=Sophos;i="5.40,378,1496059200"; d="scan'208";a="166310022" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Jul 2017 03:25:47 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Jul 2017 03:25:47 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::6929:c5b:e4d6:fd92%14]) with mapi id 15.00.1263.000; Wed, 19 Jul 2017 03:25:47 +1200 From: Peter Gutmann To: "David A. Cooper" CC: "pkix@ietf.org" Thread-Topic: [pkix] Managing Long-Lived CA certs Thread-Index: AQHS/wfFsHzAHG/6DUqwsYmxTQJgoKJXVMeAgAGZvr3//+d/gIAAzL86//854gCAANk/0g== Date: Tue, 18 Jul 2017 15:25:46 +0000 Message-ID: <1500391529591.47499@cs.auckland.ac.nz> References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <1500387403338.42595@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 15:25:51 -0000 David A. Cooper writes:=0A= =0A= >So, you intentionally delete the quote I provided from RFC 5280 saying tha= t=0A= >use of the private key usage period extension is "neither deprecated nor= =0A= >recommended" so that you can falsely claim that the "PKIX RFCs for the las= t=0A= >twenty years" have said the same thing.=0A= =0A= So you intentionally quibble over trivia in order to turn this into a long = and=0A= pointlessly boring argument...=0A= =0A= >From drafts of 2459 around 20 years ago until 5280 the spec said you should= n't=0A= use PKUP (3280 was even more strongly worded than the original 2459 text I= =0A= cited, "This extension SHOULD NOT be used within the Internet PKI"), and th= en=0A= 5280 removed mention of it. The majority of the PKI implementations I'm aw= are=0A= of date from well before 5280, when the "don't use PKUP" was in force. Tha= t's=0A= why I pointed out that support for it in implementations could be hard to= =0A= find.=0A= =0A= Peter.=0A= From nobody Tue Jul 18 08:48:03 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957DD131B81 for ; Tue, 18 Jul 2017 08:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=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 h9bKwus1SYke for ; Tue, 18 Jul 2017 08:47:59 -0700 (PDT) Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) (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 EC53A127077 for ; Tue, 18 Jul 2017 08:47:53 -0700 (PDT) Received: from Morten ([62.44.134.67]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id 4201707181747482506 for ; Tue, 18 Jul 2017 17:47:48 +0200 From: "Erik Andersen" To: "'PKIX'" References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> In-Reply-To: <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> Date: Tue, 18 Jul 2017 17:47:50 +0200 Message-ID: <003d01d2ffdd$35d67c70$a1837550$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01D2FFED.F961E480" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDOcHAtNaigQtZhTsCOwy8a/DXXLwJG2NRHAgHCn8ECXth9BaQtmm9Q Content-Language: en-gb Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 15:48:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003E_01D2FFED.F961E480 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi David, =20 PKIX is not the whole world. =20 The smart grid security work within IEC TC57 WG15 does not refer to RFC = 5280, but only to X.509. X.509 provides functionality, like = authorization and validation lists (AVLs) not part of any IETF = specification. =20 In the smart grid and IoT world, traditional PKI techniques fall short. = I believe that is what Max is trying to tell. =20 Erik =20 Fra: pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af David A. = Cooper Sendt: 18 July 2017 16:03 Til: Peter Gutmann Cc: PKIX Emne: Re: [pkix] Managing Long-Lived CA certs =20 Can you provide a citation for your claim that "PKIX says you're not = allowed to use it. No reason given, you just can't."? RFC 5280 says: This specification obsoletes [RFC3280]. Differences from RFC 3280 are = summarized below: * Section 4.2.1.4 in RFC 3280, which specified the privateKeyUsagePeriod certificate extension but deprecated its use, was removed. Use of this ISO standard extension is neither deprecated nor recommended for use in the Internet PKI. "Use of this ISO standard extension is neither deprecated nor = recommended" doesn't sound like "you just can't" to me. On 07/17/2017 11:31 PM, Peter Gutmann wrote: Erik Andersen writes: =20 What about the private key usage period extension =20 That would be the obvious choice, but PKIX says you're not allowed to = use it. No reason given, you just can't. This would imply that support for it = in implementations is going to be hard to find... =20 Peter. ------=_NextPart_000_003E_01D2FFED.F961E480 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi David,

 

PKIX is not the whole = world.

 

The smart grid security work within IEC TC57 = WG15 does not refer to RFC 5280, but only to X.509. X.509 provides = functionality, like authorization and validation lists (AVLs) not part = =C2=A0of any IETF specification.

 

In the smart grid and IoT world, traditional = PKI techniques fall short. I believe that is what Max is trying to = tell.

 

Erik

 

Fra: pkix [mailto:pkix-bounces@ietf.org] P=C3=A5 vegne af David = A. Cooper
Sendt: 18 July 2017 16:03
Til: Peter = Gutmann <pgut001@cs.auckland.ac.nz>
Cc: PKIX = <pkix@ietf.org>
Emne: Re: [pkix] Managing Long-Lived CA = certs

 

Can you = provide a citation for your claim that "PKIX says you're not = allowed to use it. No reason given, you just can't."?

RFC = 5280 says:

This specification = obsoletes [RFC3280].  Differences from RFC 3280 are summarized = below:

      * Section 4.2.1.4 = in RFC 3280, which specified = the
        privateKeyUsagePeriod = certificate extension but deprecated = its
        use, was = removed.  Use of this ISO standard extension is = neither
        deprecated nor = recommended for use in the Internet = PKI.

"Use of = this ISO standard extension is neither deprecated nor recommended" = doesn't sound like "you just can't" to me.

On = 07/17/2017 11:31 PM, Peter Gutmann = wrote:

Erik Andersen <era@x500.eu> =
writes:
 
What about the =
private key usage period =
extension
 
T=
hat would be the obvious choice, but PKIX says you're not allowed to use =
it.
No reason given, you just can't.=C2=A0 This =
would imply that support for it in
implementations =
is going to be hard to =
find...
 
Peter.
------=_NextPart_000_003E_01D2FFED.F961E480-- From nobody Tue Jul 18 15:26:19 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E307131A8B for ; Tue, 18 Jul 2017 15:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] 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 AvwJNAfjNfVS for ; Tue, 18 Jul 2017 15:26:16 -0700 (PDT) Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (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 DCAFA1317D4 for ; Tue, 18 Jul 2017 15:26:15 -0700 (PDT) Received: from smtp21.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 11A89258A8 for ; Tue, 18 Jul 2017 18:26:10 -0400 (EDT) Received: from app26.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F0E76254F0 for ; Tue, 18 Jul 2017 18:26:09 -0400 (EDT) X-Sender-Id: swilson@lockstep.com.au Received: from app26.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Tue, 18 Jul 2017 18:26:10 -0400 Received: from lockstep.com.au (localhost [127.0.0.1]) by app26.wa-webapps.iad3a (Postfix) with ESMTP id 3C60FE0298 for ; Tue, 18 Jul 2017 18:26:09 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: swilson@lockstep.com.au, from: swilson@lockstep.com.au) with HTTP; Wed, 19 Jul 2017 08:26:09 +1000 (AEST) X-Auth-ID: swilson@lockstep.com.au Date: Wed, 19 Jul 2017 08:26:09 +1000 (AEST) From: swilson@lockstep.com.au To: pkix@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20170719082609000000_57457" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <1500391529591.47499@cs.auckland.ac.nz> References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <1500387403338.42595@cs.auckland.ac.nz>, <1500391529591.47499@cs.auckland.ac.nz> Message-ID: <1500416769.24548519@apps.rackspace.com> X-Mailer: webmail/12.9.4-RC Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 22:26:18 -0000 ------=_20170719082609000000_57457 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A =0AThis is why we in PKI can't have nice things. =0A =0ACheers,=0A =0AS= teve.=0A =0A =0AStephen Wilson=0AManaging Director=0ALockstep Technologies= =0AE: swilson@lockstep.com.au=0AM: +61 (0)414 488 851=0AW: http://lockstep.= com.au=0AT: @steve_lockstep=0A =0ALockstep Technologies develops unique new= smart ID solutions that =0Aenhance privacy and prevent identity theft. Loc= kstep Consulting provides =0Aindependent specialist advice and analysis on = digital identity and privacy. =0A =0A =0A =0A-----Original Message-----=0AF= rom: "Peter Gutmann" =0ASent: Wednesday, 19 July= , 2017 1:25am=0ATo: "David A. Cooper" =0ACc: "pkix@i= etf.org" =0ASubject: Re: [pkix] Managing Long-Lived CA certs= =0A=0A=0A=0ADavid A. Cooper writes:=0A=0A>So, you i= ntentionally delete the quote I provided from RFC 5280 saying that=0A>use o= f the private key usage period extension is "neither deprecated nor=0A>reco= mmended" so that you can falsely claim that the "PKIX RFCs for the last=0A>= twenty years" have said the same thing.=0A=0ASo you intentionally quibble o= ver trivia in order to turn this into a long and=0Apointlessly boring argum= ent...=0A=0A>From drafts of 2459 around 20 years ago until 5280 the spec sa= id you shouldn't=0Ause PKUP (3280 was even more strongly worded than the or= iginal 2459 text I=0Acited, "This extension SHOULD NOT be used within the I= nternet PKI"), and then=0A5280 removed mention of it. The majority of the P= KI implementations I'm aware=0Aof date from well before 5280, when the "don= 't use PKUP" was in force. That's=0Awhy I pointed out that support for it i= n implementations could be hard to=0Afind.=0A=0APeter.=0A=0A_______________= ________________________________=0Apkix mailing list=0Apkix@ietf.org=0Ahttp= s://www.ietf.org/mailman/listinfo/pkix ------=_20170719082609000000_57457 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

=0A

This is why we in PKI can't have nice things. 

=0A

 

=0A

Cheers,

=0A

 

= =0A

Steve.

=0A

 

=0A

 

=0A

Stephen Wilson
Managing DirectorLockstep Technologies
E: swilson@lockstep.com.au
M: +61 (0)414= 488 851
W: http://lockstep.com.au
T: @steve_lockstep

Lockstep Technologies develops unique new smart ID solutions that
en= hance privacy and prevent identity theft. Lockstep Consulting provides
independent specialist advice and analysis on digital identity and privac= y.

=0A

 

=0A

 

=0A

 

=0A

-----Original Message-----
F= rom: "Peter Gutmann" <pgut001@cs.auckland.ac.nz>
Sent: Wednesday= , 19 July, 2017 1:25am
To: "David A. Cooper" <david.cooper@nist.gov= >
Cc: "pkix@ietf.org" <pkix@ietf.org>
Subject: Re: [pkix= ] Managing Long-Lived CA certs

=0A
=0A

David A. Cooper <david.cooper@nist.gov> wr= ites:

>So, you intentionally delete the quote I provided from= RFC 5280 saying that
>use of the private key usage period extensio= n is "neither deprecated nor
>recommended" so that you can falsely = claim that the "PKIX RFCs for the last
>twenty years" have said the= same thing.

So you intentionally quibble over trivia in order t= o turn this into a long and
pointlessly boring argument...

= >From drafts of 2459 around 20 years ago until 5280 the spec said you sh= ouldn't
use PKUP (3280 was even more strongly worded than the original= 2459 text I
cited, "This extension SHOULD NOT be used within the Inte= rnet PKI"), and then
5280 removed mention of it. The majority of the P= KI implementations I'm aware
of date from well before 5280, when the "= don't use PKUP" was in force. That's
why I pointed out that support fo= r it in implementations could be hard to
find.

Peter.
=
_______________________________________________
pkix mailing lis= t
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

=0A=
------=_20170719082609000000_57457-- From nobody Wed Jul 19 10:33:45 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFC212EC36 for ; Wed, 19 Jul 2017 10:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95-Yo5_ibpjx for ; Wed, 19 Jul 2017 10:33:41 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1AC129AF9 for ; Wed, 19 Jul 2017 10:33:41 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 5161D3740F19 for ; Wed, 19 Jul 2017 13:33:40 -0400 (EDT) To: pkix@ietf.org References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <003d01d2ffdd$35d67c70$a1837550$@x500.eu> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: Date: Wed, 19 Jul 2017 19:33:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <003d01d2ffdd$35d67c70$a1837550$@x500.eu> Content-Type: multipart/alternative; boundary="------------CD03AC28C45A5373AEF99608" Content-Language: en-US Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 17:33:44 -0000 This is a multi-part message in MIME format. --------------CD03AC28C45A5373AEF99608 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, I just want to point out that the extension that is mentioned is NOT the same as I wanted try to propose (if this is highly controversial, it can just be an informational RFC). The only correct answer to my question actually is: nothing like that exists, something similar was deprecated in RFC5280 but it is still used in other environments. What follows is a bit of summary of (a) what I see happening in the real world, and (b) my PERSONAL point of view about the real situation where we are heading today. As Erik pointed out, my quick and short proposal is an attempt to address some shortcomings that I see happening especially in the IoT / Device world where expertise around certificates and PKIs is just not there. More and more people that do not really understand the way PKIs SHOULD work in order to really address the threats related to Key Management propose the use of weak infrastructure just because (a) there is no active work aimed at solving issues that exists and (b) go for a quick solution that provides, in many cases, really just a fuzzy feeling rather than solid architectures. An example of this is the trend that has been growing a lot at IETF with the insanity about short-lived certificates (different working groups have no other choices but use what other WG did without realizing how weak those solutions are). I can not find any proposals in the recent times that does not say "let's use short-lived certificates": did we all became great at protecting secrets ? do we all use HW protected keys ? In my experience I have seen (positively) increasing the use of crypto and keys with a decreasing understanding about the risks and less options when it comes to recover from broken trust. Also, the same people that argue for short-lived certificates often pick that option because of the (proven wrong over and over again) willingness to mix AuthN and AuthZ - most of the times not even understanding that that is what the authors are doing! PKIX has a long history about trying to separate the two concepts (i.e., using tokens for authorization like attribute certificates). Delegation, especially when it is a self-delegation, was solved with the introduction of proxy certificates. I also would like to point out the inability (or, actually more accurately the un-willingness - especially from former ADs) to take on important work and new proposals that address efficient revocation handling and discoverability of PK-related services (hack, we still not have a distributed support system for Public Key operations deployed or even envisioned in 2017! That is simply CRAZY to me!). We are still stuck with CRLs most of the times, OCSP if we are lucky, and in most cases even these mechanisms are criticized widely by people at the meetings without really understanding that Internet PKI and PKIs (as pointed out) are not the same thing. Even in the Internet PKIs, applications like browsers do not properly check revocation claiming that few milliseconds of delay (well, they could just check it in parallel and just block further operations in case revocation is detected or, as they do for content, they could simply pre-fetch the information for usually visited resources). Wrongly designed PKIs (or Weak PKIs) are being deployed today and expected to run for 30yrs when the algorithms that are supported (mainly in HW) are NOT going to pass the test of time - not on that scale, not for millions of people, not with devices that might handle our private data. This will affect our homes and the quality of Internet connections (degrading the user experience and creating huge issues for the operators in the future). Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in the PKI discussions): * *There are NO venues where to discuss possible solutions to existing problems.* The PKIX working group has been closed down (very arbitrarily, I might say) and now expertise about the nuances of understanding and running PKIs is mostly lost or very difficult to chase. * *The LAMPS WG has, on purpose, a very limited Charter and only few items* (mostly quite marginal, I would say) are actually accepted as working items. Solving revocation should be the 1st item and the most important on the list... but it is not - actually when I proposed, it was not even acknowledged. * *The constant**nonsense of people saying that PKIs do not work as an excuse not to improve them while they are the reason we can deploy and manage security and provide privacy. *Eroding all the good work done in the past just because people do not understand the importance of providing BETTER support for Trust Management rather than a QUICK solution (e.g., short-lived certificates, mix of authorization and authentication, forgetting the existence of RFCs that already provide more secure solutions than the ones that are re-invented, today, over and over again). Things are happening in other environments and lacking the support from IETF is really scary. The world moves forward and the IETF is standing still on this topic. I really do not understand why. For example: what is more important, fixing internationalization for e-mail addresses or allowing the checking of revocation information in such a way that we can restrict the use of short-lived certificates only when STRICTLY necessary ? Well.. things to consider. I tried many times to push the issue without success... politics is the enemy of the right thing to do... and today we are just dealing with politicians when it comes to PKIs... Just my 2 cents.. but I would be interested in your opinions too... Cheers, Max On 7/18/17 5:47 PM, Erik Andersen wrote: > > Hi David, > > PKIX is not the whole world. > > The smart grid security work within IEC TC57 WG15 does not refer to > RFC 5280, but only to X.509. X.509 provides functionality, like > authorization and validation lists (AVLs) not part of any IETF > specification. > > In the smart grid and IoT world, traditional PKI techniques fall > short. I believe that is what Max is trying to tell. > > Erik > > *Fra:*pkix [mailto:pkix-bounces@ietf.org] *På vegne af *David A. Cooper > *Sendt:* 18 July 2017 16:03 > *Til:* Peter Gutmann > *Cc:* PKIX > *Emne:* Re: [pkix] Managing Long-Lived CA certs > > Can you provide a citation for your claim that "PKIX says you're not > allowed to use it. No reason given, you just can't."? > > RFC 5280 says: > > This specification obsoletes [RFC3280]. Differences from RFC 3280 > are summarized below: > > * Section 4.2.1.4 in RFC 3280, which specified the > privateKeyUsagePeriod certificate extension but deprecated its > use, was removed. Use of this ISO standard extension is > neither > deprecated nor recommended for use in the Internet PKI. > > "Use of this ISO standard extension is neither deprecated nor > recommended" doesn't sound like "you just can't" to me. > > On 07/17/2017 11:31 PM, Peter Gutmann wrote: > > Erik Andersen writes: > > What about the private key usage period extension > > That would be the obvious choice, but PKIX says you're not allowed to use it. > > No reason given, you just can't. This would imply that support for it in > > implementations is going to be hard to find... > > Peter. > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------CD03AC28C45A5373AEF99608 Content-Type: multipart/related; boundary="------------C4C066AC46A5905C9A71BCF8" --------------C4C066AC46A5905C9A71BCF8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi all,

I just want to point out that the extension that is mentioned is NOT the same as I wanted try to propose (if this is highly controversial, it can just be an informational RFC). The only correct answer to my question actually is: nothing like that exists, something similar was deprecated in RFC5280 but it is still used in other environments.

What follows is a bit of summary of (a) what I see happening in the real world, and (b) my PERSONAL point of view about the real situation where we are heading today.

As Erik pointed out, my quick and short proposal is an attempt to address some shortcomings that I see happening especially in the IoT / Device world where expertise around certificates and PKIs is just not there.

More and more people that do not really understand the way PKIs SHOULD work in order to really address the threats related to Key Management propose the use of weak infrastructure just because (a) there is no active work aimed at solving issues that exists and (b) go for a quick solution that provides, in many cases, really just a fuzzy feeling rather than solid architectures.

An example of this is the trend that has been growing a lot at IETF with the insanity about short-lived certificates (different working groups have no other choices but use what other WG did without realizing how weak those solutions are). I can not find any proposals in the recent times that does not say "let's use short-lived certificates": did we all became great at protecting secrets ? do we all use HW protected keys ?

In my experience I have seen (positively) increasing the use of crypto and keys with a decreasing understanding about the risks and less options when it comes to recover from broken trust.

Also, the same people that argue for short-lived certificates often pick that option because of the (proven wrong over and over again) willingness to mix AuthN and AuthZ - most of the times not even understanding that that is what the authors are doing!

PKIX has a long history about trying to separate the two concepts (i.e., using tokens for authorization like attribute certificates). Delegation, especially when it is a self-delegation, was solved with the introduction of proxy certificates.

I also would like to point out the inability (or, actually more accurately the un-willingness - especially from former ADs) to take on important work and new proposals that address efficient revocation handling and discoverability of PK-related services (hack, we still not have a distributed support system for Public Key operations deployed or even envisioned in 2017! That is simply CRAZY to me!).

We are still stuck with CRLs most of the times, OCSP if we are lucky, and in most cases even these mechanisms are criticized widely by people at the meetings without really understanding that Internet PKI and PKIs (as pointed out) are not the same thing. Even in the Internet PKIs, applications like browsers do not properly check revocation claiming that few milliseconds of delay (well, they could just check it in parallel and just block further operations in case revocation is detected or, as they do for content, they could simply pre-fetch the information for usually visited resources).

Wrongly designed PKIs (or Weak PKIs) are being deployed today and expected to run for 30yrs when the algorithms that are supported (mainly in HW) are NOT going to pass the test of time - not on that scale, not for millions of people, not with devices that might handle our private data. This will affect our homes and the quality of Internet connections (degrading the user experience and creating huge issues for the operators in the future).

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

  • There are NO venues where to discuss possible solutions to existing problems. The PKIX working group has been closed down (very arbitrarily, I might say) and now expertise about the nuances of understanding and running PKIs is mostly lost or very difficult to chase.

  • The LAMPS WG has, on purpose, a very limited Charter and only few items (mostly quite marginal, I would say) are actually accepted as working items. Solving revocation should be the 1st item and the most important on the list... but it is not - actually when I proposed, it was not even acknowledged.

  • The constant nonsense of people saying that PKIs do not work as an excuse not to improve them while they are the reason we can deploy and manage security and provide privacy. Eroding all the good work done in the past just because people do not understand the importance of providing BETTER support for Trust Management rather than a QUICK solution (e.g., short-lived certificates, mix of authorization and authentication, forgetting the existence of RFCs that already provide more secure solutions than the ones that are re-invented, today, over and over again).

Things are happening in other environments and lacking the support from IETF is really scary. The world moves forward and the IETF is standing still on this topic. I really do not understand why.

For example: what is more important, fixing internationalization for e-mail addresses or allowing the checking of revocation information in such a way that we can restrict the use of short-lived certificates only when STRICTLY necessary ?

Well.. things to consider.

I tried many times to push the issue without success... politics is the enemy of the right thing to do... and today we are just dealing with politicians when it comes to PKIs...

Just my 2 cents.. but I would be interested in your opinions too...

Cheers,
Max


On 7/18/17 5:47 PM, Erik Andersen wrote:

Hi David,

 

PKIX is not the whole world.

 

The smart grid security work within IEC TC57 WG15 does not refer to RFC 5280, but only to X.509. X.509 provides functionality, like authorization and validation lists (AVLs) not part  of any IETF specification.

 

In the smart grid and IoT world, traditional PKI techniques fall short. I believe that is what Max is trying to tell.

 

Erik

 

Fra: pkix [mailto:pkix-bounces@ietf.org] På vegne af David A. Cooper
Sendt: 18 July 2017 16:03
Til: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: PKIX <pkix@ietf.org>
Emne: Re: [pkix] Managing Long-Lived CA certs

 

Can you provide a citation for your claim that "PKIX says you're not allowed to use it. No reason given, you just can't."?

RFC 5280 says:

This specification obsoletes [RFC3280].  Differences from RFC 3280 are summarized below:

      * Section 4.2.1.4 in RFC 3280, which specified the
        privateKeyUsagePeriod certificate extension but deprecated its
        use, was removed.  Use of this ISO standard extension is neither
        deprecated nor recommended for use in the Internet PKI.

"Use of this ISO standard extension is neither deprecated nor recommended" doesn't sound like "you just can't" to me.

On 07/17/2017 11:31 PM, Peter Gutmann wrote:

Erik Andersen <era@x500.eu> writes:
 
What about the private key usage period extension
 
That would be the obvious choice, but PKIX says you're not allowed to use it.
No reason given, you just can't.  This would imply that support for it in
implementations is going to be hard to find...
 
Peter.


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

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------C4C066AC46A5905C9A71BCF8 Content-Type: image/png; name="hepknflppejcnhoc.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="hepknflppejcnhoc.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= --------------C4C066AC46A5905C9A71BCF8-- --------------CD03AC28C45A5373AEF99608-- From nobody Wed Jul 19 10:49:53 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC437131B67 for ; Wed, 19 Jul 2017 10:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ycvMLURY1Po for ; Wed, 19 Jul 2017 10:49:48 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0053B1317BE for ; Wed, 19 Jul 2017 10:49:47 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id k69so5385845wmc.1 for ; Wed, 19 Jul 2017 10:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=BWRvfjSee6feYq++WUExVk5z7GgF4zWcTsaoM33MZeo=; b=fOD+iN5MdvmKEoz3u7EhNZHUOQMCcT0vkFzosaUd6nL/718zNDu7VdolFBV9oGgyGQ hkH2jQCRzQhK3M40jxiOI46l7LxXd2C97ydwQxBCIy2v0dzOKUjssISqzf9LMFK80ZuK L04L30ztEw3l91ZZpeoIXXTCoZDAej/ZKvJeK6edRsT8YY8wOtG9Nse79S/Lj0hQFYvN 0IWF8RHy2T8XvC76w6QzuJeDvKIsk3oHrQx3D70TOuXi7CbvE3CVONGfG2xX9brAUJrD zLpvP6u5nS8QOxPG/HonUdx8DbJ/oi0p4xea1x+96KDvMb/mJfF0/xoy8OWhsotPnPRs TraQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BWRvfjSee6feYq++WUExVk5z7GgF4zWcTsaoM33MZeo=; b=ODl2QipQO6fenqYqn+ZFi6McJT7LCVsUN7nAJ+nwv1rDvRIElLTBHPJIu7NIMkcJI9 Fkmw4C9CiRtQon0m7yHfkNSvIujXhMTMqepGvRWWOk6SPy42YctAeG1Dj7oDskQljTIw f7udC8n5QcER6f1ipG+N7HlY1F3+Q0+Gvt+J0LDBMJdX9+UtisuQFxEGzuV6Wq90mWmQ /UMySKCLRB49P+suJALZjxwaosiBGbkxAdkLEnz7zJkyazmIoIXXowoLFzi3YoW9kOQb G4y6A9Orq9s4+Qf6IoEODV6T15W7aK9hUycSXv6o2oYdc6YPjnIOmGJ2N+I+WUT3fmFy fJfw== X-Gm-Message-State: AIVw111ZpM8oHsLHuelv5PKimBkR6z7upoEHkQWV6B1+hoGQ/R38gskZ 5a7TCMrcSc1dQcFV X-Received: by 10.28.189.214 with SMTP id n205mr542450wmf.122.1500486586145; Wed, 19 Jul 2017 10:49:46 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id n205sm398084wmf.21.2017.07.19.10.49.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 10:49:45 -0700 (PDT) To: "Dr. Pala" , pkix@ietf.org References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <003d01d2ffdd$35d67c70$a1837550$@x500.eu> From: Anders Rundgren Message-ID: Date: Wed, 19 Jul 2017 19:49:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 17:49:51 -0000 Max, You are absolutely right. The "PKI community" (which doesn't really exist) have left PKI to die and the market is therefore flocking around FIDO alliance products which unlike PKI were designed for an on-line world from the beginning. Anders On 2017-07-19 19:33, Dr. Pala wrote: > Hi all, > > I just want to point out that the extension that is mentioned is NOT the same as I wanted try to propose (if this is highly controversial, it can just be an informational RFC). The only correct answer to my question actually is: nothing like that exists, something similar was deprecated in RFC5280 but it is still used in other environments. > > What follows is a bit of summary of (a) what I see happening in the real world, and (b) my PERSONAL point of view about the real situation where we are heading today. > > As Erik pointed out, my quick and short proposal is an attempt to address some shortcomings that I see happening especially in the IoT / Device world where expertise around certificates and PKIs is just not there. > > More and more people that do not really understand the way PKIs SHOULD work in order to really address the threats related to Key Management propose the use of weak infrastructure just because (a) there is no active work aimed at solving issues that exists and (b) go for a quick solution that provides, in many cases, really just a fuzzy feeling rather than solid architectures. > > An example of this is the trend that has been growing a lot at IETF with the insanity about short-lived certificates (different working groups have no other choices but use what other WG did without realizing how weak those solutions are). I can not find any proposals in the recent times that does not say "let's use short-lived certificates": did we all became great at protecting secrets ? do we all use HW protected keys ? > > In my experience I have seen (positively) increasing the use of crypto and keys with a decreasing understanding about the risks and less options when it comes to recover from broken trust. > > Also, the same people that argue for short-lived certificates often pick that option because of the (proven wrong over and over again) willingness to mix AuthN and AuthZ - most of the times not even understanding that that is what the authors are doing! > > PKIX has a long history about trying to separate the two concepts (i.e., using tokens for authorization like attribute certificates). Delegation, especially when it is a self-delegation, was solved with the introduction of proxy certificates. > > I also would like to point out the inability (or, actually more accurately the un-willingness - especially from former ADs) to take on important work and new proposals that address efficient revocation handling and discoverability of PK-related services (hack, we still not have a distributed support system for Public Key operations deployed or even envisioned in 2017! That is simply CRAZY to me!). > > We are still stuck with CRLs most of the times, OCSP if we are lucky, and in most cases even these mechanisms are criticized widely by people at the meetings without really understanding that Internet PKI and PKIs (as pointed out) are not the same thing. Even in the Internet PKIs, applications like browsers do not properly check revocation claiming that few milliseconds of delay (well, they could just check it in parallel and just block further operations in case revocation is detected or, as they do for content, they could simply pre-fetch the information for usually visited resources). > > Wrongly designed PKIs (or Weak PKIs) are being deployed today and expected to run for 30yrs when the algorithms that are supported (mainly in HW) are NOT going to pass the test of time - not on that scale, not for millions of people, not with devices that might handle our private data. This will affect our homes and the quality of Internet connections (degrading the user experience and creating huge issues for the operators in the future). > > Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in the PKI discussions): > > * *There are NO venues where to discuss possible solutions to existing problems.* The PKIX working group has been closed down (very arbitrarily, I might say) and now expertise about the nuances of understanding and running PKIs is mostly lost or very difficult to chase. > > * *The LAMPS WG has, on purpose, a very limited Charter and only few items* (mostly quite marginal, I would say) are actually accepted as working items. Solving revocation should be the 1st item and the most important on the list... but it is not - actually when I proposed, it was not even acknowledged. > > * *The constant**nonsense of people saying that PKIs do not work as an excuse not to improve them while they are the reason we can deploy and manage security and provide privacy. *Eroding all the good work done in the past just because people do not understand the importance of providing BETTER support for Trust Management rather than a QUICK solution (e.g., short-lived certificates, mix of authorization and authentication, forgetting the existence of RFCs that already provide more secure solutions than the ones that are re-invented, today, over and over again). > > Things are happening in other environments and lacking the support from IETF is really scary. The world moves forward and the IETF is standing still on this topic. I really do not understand why. > > For example: what is more important, fixing internationalization for e-mail addresses or allowing the checking of revocation information in such a way that we can restrict the use of short-lived certificates only when STRICTLY necessary ? > > Well.. things to consider. > > I tried many times to push the issue without success... politics is the enemy of the right thing to do... and today we are just dealing with politicians when it comes to PKIs... > > Just my 2 cents.. but I would be interested in your opinions too... > > Cheers, > Max > > > On 7/18/17 5:47 PM, Erik Andersen wrote: >> >> Hi David, >> >> PKIX is not the whole world. >> >> The smart grid security work within IEC TC57 WG15 does not refer to RFC 5280, but only to X.509. X.509 provides functionality, like authorization and validation lists (AVLs) not part of any IETF specification. >> >> In the smart grid and IoT world, traditional PKI techniques fall short. I believe that is what Max is trying to tell. >> >> Erik >> >> *Fra:*pkix [mailto:pkix-bounces@ietf.org] *På vegne af *David A. Cooper >> *Sendt:* 18 July 2017 16:03 >> *Til:* Peter Gutmann >> *Cc:* PKIX >> *Emne:* Re: [pkix] Managing Long-Lived CA certs >> >> Can you provide a citation for your claim that "PKIX says you're not allowed to use it. No reason given, you just can't."? >> >> RFC 5280 says: >> >> This specification obsoletes [RFC3280]. Differences from RFC 3280 are summarized below: >> >> * Section 4.2.1.4 in RFC 3280, which specified the >> privateKeyUsagePeriod certificate extension but deprecated its >> use, was removed. Use of this ISO standard extension is neither >> deprecated nor recommended for use in the Internet PKI. >> >> "Use of this ISO standard extension is neither deprecated nor recommended" doesn't sound like "you just can't" to me. >> >> On 07/17/2017 11:31 PM, Peter Gutmann wrote: >> >> Erik Andersen writes: >> >> What about the private key usage period extension >> >> That would be the obvious choice, but PKIX says you're not allowed to use it. >> >> No reason given, you just can't. This would imply that support for it in >> >> implementations is going to be hard to find... >> >> Peter. >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > OpenCA Logo > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From nobody Wed Jul 19 11:06:56 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92AE131DA0 for ; Wed, 19 Jul 2017 11:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rmzx5XIeQue6 for ; Wed, 19 Jul 2017 11:06:49 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC86E131B76 for ; Wed, 19 Jul 2017 11:06:48 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id b40so7956396qtb.2 for ; Wed, 19 Jul 2017 11:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=gvQJRPnkLrg57A3aAUultiUdeTiZJqA2xQgc96HiWc0=; b=1P8B9anASoM2NckocRbSS0Jstr+qNk4TfIkPG224OWWGg5uvwiI97ETJex+aJgkPtF ZUZ29SqJCfnig4N90KCZJdK3FZ3SefpdjaNuYD+Ps42Gnv/q17/n1Bo7a6Pv2RpN1UIm HKZRQpCTeCCqScQ0rhCAwHv3v9yaFwFzDebgM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=gvQJRPnkLrg57A3aAUultiUdeTiZJqA2xQgc96HiWc0=; b=QGQc4QOwrojuom/S55d2xamDlbMpVPZuDHabU/wZR/bwVJD16Y0dhWvqrZCyADAhvF 7FT5hdjSco1B5yWVLafmOe4jbDHyiJk6Af/hpeteHxIMfyS7vQMyR6QDPRUPyP/EEndC p9UsSOrxRd4u/MdTedMkLgtxIUlg0/C51sYQUyvRfUy0NxrPpp1nlBj20FT6FRt12Cc4 W9pyXtYAdg7swCGFbGRB4rC1UNR9ORz1+n922OzNDJTP6gkXN1VZavVLTvlNY6N/k7S0 h1WshpQCZXBODwv/UEr5kZfIrsrbQD2ckg1cDcKCrVNGOfmFobqwR1SubcGlpCaXV0IH ZMeg== X-Gm-Message-State: AIVw1116sOHFJKILwU18C+7CkIHLngnpgaJwCv2WRZuwFBO45IX0yfdz qZ7Iz+UTsvycSz2Wa1s= X-Received: by 10.237.34.227 with SMTP id q32mr1411923qtc.39.1500487607813; Wed, 19 Jul 2017 11:06:47 -0700 (PDT) Received: from [192.168.2.27] (pool-173-66-76-215.washdc.fios.verizon.net. [173.66.76.215]) by smtp.googlemail.com with ESMTPSA id i8sm414638qtb.40.2017.07.19.11.06.46 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 19 Jul 2017 11:06:47 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.4.170508 Date: Wed, 19 Jul 2017 14:06:44 -0400 From: Carl Wallace To: "Dr. Pala" , Message-ID: Thread-Topic: [pkix] Managing Long-Lived CA certs References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <003d01d2ffdd$35d67c70$a1837550$@x500.eu> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3583318007_21969861" Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 18:06:51 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3583318007_21969861 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit From: pkix on behalf of "Dr. Pala" Organization: OpenCA Labs Date: Wednesday, July 19, 2017 at 1:33 PM To: Subject: Re: [pkix] Managing Long-Lived CA certs > > > > Hi all, > > > I just want to point out that the extension that is mentioned is NOT the same > as I wanted try to propose (if this is highly controversial, it can just be an > informational RFC). The only correct answer to my question actually is: > nothing like that exists, something similar was deprecated in RFC5280 but it > is still used in other environments. [CW] Re: your proposal (politics aside), it's not clear that a mechanism to allow a CA key to live for CRL generation but not certificate signing is necessary to serve a community that doesn't check revocation status (i.e., lightbulbs, in your example). An alternative that does not require new ASN.1 would be to reuse the PrivateKeyUsagePeriod syntax, define a new OID, and declare the semantics for extensions with the OID and structure to be for CA keys only with the caveat that CRLs and OCSP responder certificates can be signed after the date in the extension. > > > --B_3583318007_21969861 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

From: pkix <pkix-= bounces@ietf.org> on behalf of "Dr. Pala" <director@openca.org>
= Organization: OpenCA Labs
Date: Wednesday, July 19, 2017 at 1:33 PM
= To: <pkix@ietf.org>
Subject: Re: [pkix] Managing Long-Lived C= A certs

Hi all,

I just want to point out that the extension that is mentioned is NOT the same as I wanted try to propose (if this is highly controversial, it can just be an informational RFC). The only correct answer to my question actually is: nothing like that exists, something similar was deprecated in RFC5280 but it is still used in other environments.

=
[CW] Re: your proposal (politics aside), it's not clear that a mechanis= m to allow a CA key to live for CRL generation but not certificate signing i= s necessary to serve a community that doesn't check revocation status (i.e.,= lightbulbs, in your example). An alternative that does not require new ASN.= 1 would be to reuse the PrivateKeyUsagePeriod syntax, define a new OID, and = declare the semantics for extensions with the OID and structure to be for CA= keys only with the caveat that CRLs and OCSP responder certificates can be = signed after the date in the extension.

<very large snip>

 --B_3583318007_21969861-- From nobody Wed Jul 19 13:30:41 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C63713168D for ; Wed, 19 Jul 2017 13:30:39 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kjqwmeZAtSH for ; Wed, 19 Jul 2017 13:30:34 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 60E15131671 for ; Wed, 19 Jul 2017 13:30:34 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 4E63F780282 for ; Wed, 19 Jul 2017 22:30:30 +0200 (CEST) To: pkix@ietf.org References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <003d01d2ffdd$35d67c70$a1837550$@x500.eu> From: Denis Message-ID: Date: Wed, 19 Jul 2017 22:30:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------604E554BAE67906D779CABB1" Content-Language: en-US Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 20:30:39 -0000 This is a multi-part message in MIME format. --------------604E554BAE67906D779CABB1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Max, Just my 1 cent ... since you said you would be interested to hear opinions. PKI is still very useful and used for servers, but it is no more adequate to be used for user authentication over the net. Initially, privacy was not considered, but now it is. Using PKC for users or clients allows to link user accounts between servers whereas it is not the case with FIDO which has been built using "privacy by design" principles. What we need today for human users is no more only security but *both privacy and security* (where privacy comes first). Coming back to your original proposal, I quote your text below: What I am thinking about would be adding an extension that says: "This CA can issue certificates from up to 5 years from the validFrom, after this, just use it to provide revocation information". This might provide some protection in case the CA key is compromised after the initial 5 years of validity (e.g., certificates issued after that date shall be rejected). The way you present the case violates one the fundamentals of PKI: A certificate contains necessarily a validity period defined by: Validity ::= SEQUENCE { notBeforeTime, notAfterTime } A CA is not required to handle revocation, once the certificate has expired. However, before that sentence you wrote: Until we have a supported mechanism for reprovisioning devices (...), one possible solution for limiting the exposure of the private key would be to have a scoped certificate issuance period. Hence you have identified the solution: work on a mechanism for reprovisioning devices. RFC 2510 that was issued in the last century (March 1999) contains a description on how to perform a root key change. See section "2.4 Root CA key update". This might possibly help to solve your problem. This is just my 1 cent. Denis > Max, You are absolutely right. The "PKI community" (which doesn't > really exist) have left PKI to die and the market is therefore > flocking around FIDO alliance products > which unlike PKI were designed for an on-line world from the beginning. > > Anders > > On 2017-07-19 19:33, Dr. Pala wrote: >> Hi all, >> >> I just want to point out that the extension that is mentioned is NOT >> the same as I wanted try to propose (if this is highly controversial, >> it can just be an informational RFC). The only correct answer to my >> question actually is: nothing like that exists, something similar was >> deprecated in RFC5280 but it is still used in other environments. >> >> What follows is a bit of summary of (a) what I see happening in the >> real world, and (b) my PERSONAL point of view about the real >> situation where we are heading today. >> >> As Erik pointed out, my quick and short proposal is an attempt to >> address some shortcomings that I see happening especially in the IoT >> / Device world where expertise around certificates and PKIs is just >> not there. >> >> More and more people that do not really understand the way PKIs >> SHOULD work in order to really address the threats related to Key >> Management propose the use of weak infrastructure just because (a) >> there is no active work aimed at solving issues that exists and (b) >> go for a quick solution that provides, in many cases, really just a >> fuzzy feeling rather than solid architectures. >> >> An example of this is the trend that has been growing a lot at IETF >> with the insanity about short-lived certificates (different working >> groups have no other choices but use what other WG did without >> realizing how weak those solutions are). I can not find any proposals >> in the recent times that does not say "let's use short-lived >> certificates": did we all became great at protecting secrets ? do we >> all use HW protected keys ? >> >> In my experience I have seen (positively) increasing the use of >> crypto and keys with a decreasing understanding about the risks and >> less options when it comes to recover from broken trust. >> >> Also, the same people that argue for short-lived certificates often >> pick that option because of the (proven wrong over and over again) >> willingness to mix AuthN and AuthZ - most of the times not even >> understanding that that is what the authors are doing! >> >> PKIX has a long history about trying to separate the two concepts >> (i.e., using tokens for authorization like attribute certificates). >> Delegation, especially when it is a self-delegation, was solved with >> the introduction of proxy certificates. >> >> I also would like to point out the inability (or, actually more >> accurately the un-willingness - especially from former ADs) to take >> on important work and new proposals that address efficient revocation >> handling and discoverability of PK-related services (hack, we still >> not have a distributed support system for Public Key operations >> deployed or even envisioned in 2017! That is simply CRAZY to me!). >> >> We are still stuck with CRLs most of the times, OCSP if we are lucky, >> and in most cases even these mechanisms are criticized widely by >> people at the meetings without really understanding that Internet PKI >> and PKIs (as pointed out) are not the same thing. Even in the >> Internet PKIs, applications like browsers do not properly check >> revocation claiming that few milliseconds of delay (well, they could >> just check it in parallel and just block further operations in case >> revocation is detected or, as they do for content, they could simply >> pre-fetch the information for usually visited resources). >> >> Wrongly designed PKIs (or Weak PKIs) are being deployed today and >> expected to run for 30yrs when the algorithms that are supported >> (mainly in HW) are NOT going to pass the test of time - not on that >> scale, not for millions of people, not with devices that might handle >> our private data. This will affect our homes and the quality of >> Internet connections (degrading the user experience and creating huge >> issues for the operators in the future). >> >> Why are we so unprepared to face these issues ? I would say (still >> personal point of view - based on almost 20 yrs of participation in >> the PKI discussions): >> >> * *There are NO venues where to discuss possible solutions to >> existing problems.* The PKIX working group has been closed down (very >> arbitrarily, I might say) and now expertise about the nuances of >> understanding and running PKIs is mostly lost or very difficult to >> chase. >> >> * *The LAMPS WG has, on purpose, a very limited Charter and only >> few items* (mostly quite marginal, I would say) are actually accepted >> as working items. Solving revocation should be the 1st item and the >> most important on the list... but it is not - actually when I >> proposed, it was not even acknowledged. >> >> * *The constant**nonsense of people saying that PKIs do not work as >> an excuse not to improve them while they are the reason we can deploy >> and manage security and provide privacy. *Eroding all the good work >> done in the past just because people do not understand the importance >> of providing BETTER support for Trust Management rather than a QUICK >> solution (e.g., short-lived certificates, mix of authorization and >> authentication, forgetting the existence of RFCs that already provide >> more secure solutions than the ones that are re-invented, today, over >> and over again). >> >> Things are happening in other environments and lacking the support >> from IETF is really scary. The world moves forward and the IETF is >> standing still on this topic. I really do not understand why. >> >> For example: what is more important, fixing internationalization for >> e-mail addresses or allowing the checking of revocation information >> in such a way that we can restrict the use of short-lived >> certificates only when STRICTLY necessary ? >> >> Well.. things to consider. >> >> I tried many times to push the issue without success... politics is >> the enemy of the right thing to do... and today we are just dealing >> with politicians when it comes to PKIs... >> >> Just my 2 cents.. but I would be interested in your opinions too... >> >> Cheers, >> Max >> >> >> On 7/18/17 5:47 PM, Erik Andersen wrote: >>> >>> Hi David, >>> >>> PKIX is not the whole world. >>> >>> The smart grid security work within IEC TC57 WG15 does not refer to >>> RFC 5280, but only to X.509. X.509 provides functionality, like >>> authorization and validation lists (AVLs) not part of any IETF >>> specification. >>> >>> In the smart grid and IoT world, traditional PKI techniques fall >>> short. I believe that is what Max is trying to tell. >>> >>> Erik >>> >>> *Fra:*pkix [mailto:pkix-bounces@ietf.org] *På vegne af *David A. Cooper >>> *Sendt:* 18 July 2017 16:03 >>> *Til:* Peter Gutmann >>> *Cc:* PKIX >>> *Emne:* Re: [pkix] Managing Long-Lived CA certs >>> >>> Can you provide a citation for your claim that "PKIX says you're not >>> allowed to use it. No reason given, you just can't."? >>> >>> RFC 5280 says: >>> >>> This specification obsoletes [RFC3280]. Differences from RFC >>> 3280 are summarized below: >>> >>> * Section 4.2.1.4 in RFC 3280, which specified the >>> privateKeyUsagePeriod certificate extension but >>> deprecated its >>> use, was removed. Use of this ISO standard extension is >>> neither >>> deprecated nor recommended for use in the Internet PKI. >>> >>> "Use of this ISO standard extension is neither deprecated nor >>> recommended" doesn't sound like "you just can't" to me. >>> >>> On 07/17/2017 11:31 PM, Peter Gutmann wrote: >>> >>> Erik Andersen writes: >>> >>> What about the private key usage period extension >>> >>> That would be the obvious choice, but PKIX says you're not >>> allowed to use it. >>> >>> No reason given, you just can't. This would imply that support >>> for it in >>> >>> implementations is going to be hard to find... >>> >>> Peter. >>> >>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> -- >> Best Regards, >> Massimiliano Pala, Ph.D. >> OpenCA Labs Director >> OpenCA Logo >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------604E554BAE67906D779CABB1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Max,

Just my 1 cent ... since you said you would be interested to hear opinions.

PKI is still very useful and used for servers, but it is no more adequate to be used for user authentication over the net.

Initially, privacy was not considered, but now it is. Using PKC for users or clients allows to link user accounts between servers
whereas it is not the case with FIDO which has been built using "privacy by design" principles. What we need today for human users
is no more only security but both privacy and security (where privacy comes first).

Coming back to your original proposal, I quote your text below:
What I am thinking about would be adding an extension that says: "This CA can issue certificates from up to 5 years from the validFrom,
after this, just use it to provide revocation information". This might provide some protection in case the CA key is compromised after
the initial 5 years of validity (e.g., certificates issued after that date shall be rejected).
The way you present the case violates one the fundamentals of PKI: A certificate contains necessarily a validity period defined by:

   Validity ::= SEQUENCE {
       notBefore      Time,
       notAfter         Time }

A CA is not required to handle revocation, once the certificate has expired.

However, before that sentence you wrote:
Until we have a supported mechanism for reprovisioning devices (...), one possible solution for limiting the exposure of the private key
would be to have a scoped certificate issuance period.
Hence you have identified the solution: work on a mechanism for reprovisioning devices.

RFC 2510 that was issued in the last century (March 1999) contains a description on how to perform a root key change.
See  section "2.4 Root CA key update". This might possibly help to solve your problem.

This is just my 1 cent.

Denis

Max, You are absolutely right.  The "PKI community" (which doesn't really exist) have left PKI to die and the market is therefore flocking around FIDO alliance products
which unlike PKI were designed for an on-line world from the beginning.

Anders

On 2017-07-19 19:33, Dr. Pala wrote:
Hi all,

I just want to point out that the extension that is mentioned is NOT the same as I wanted try to propose (if this is highly controversial, it can just be an informational RFC). The only correct answer to my question actually is: nothing like that exists, something similar was deprecated in RFC5280 but it is still used in other environments.

What follows is a bit of summary of (a) what I see happening in the real world, and (b) my PERSONAL point of view about the real situation where we are heading today.

As Erik pointed out, my quick and short proposal is an attempt to address some shortcomings that I see happening especially in the IoT / Device world where expertise around certificates and PKIs is just not there.

More and more people that do not really understand the way PKIs SHOULD work in order to really address the threats related to Key Management propose the use of weak infrastructure just because (a) there is no active work aimed at solving issues that exists and (b) go for a quick solution that provides, in many cases, really just a fuzzy feeling rather than solid architectures.

An example of this is the trend that has been growing a lot at IETF with the insanity about short-lived certificates (different working groups have no other choices but use what other WG did without realizing how weak those solutions are). I can not find any proposals in the recent times that does not say "let's use short-lived certificates": did we all became great at protecting secrets ? do we all use HW protected keys ?

In my experience I have seen (positively) increasing the use of crypto and keys with a decreasing understanding about the risks and less options when it comes to recover from broken trust.

Also, the same people that argue for short-lived certificates often pick that option because of the (proven wrong over and over again) willingness to mix AuthN and AuthZ - most of the times not even understanding that that is what the authors are doing!

PKIX has a long history about trying to separate the two concepts (i.e., using tokens for authorization like attribute certificates). Delegation, especially when it is a self-delegation, was solved with the introduction of proxy certificates.

I also would like to point out the inability (or, actually more accurately the un-willingness - especially from former ADs) to take on important work and new proposals that address efficient revocation handling and discoverability of PK-related services (hack, we still not have a distributed support system for Public Key operations deployed or even envisioned in 2017! That is simply CRAZY to me!).

We are still stuck with CRLs most of the times, OCSP if we are lucky, and in most cases even these mechanisms are criticized widely by people at the meetings without really understanding that Internet PKI and PKIs (as pointed out) are not the same thing. Even in the Internet PKIs, applications like browsers do not properly check revocation claiming that few milliseconds of delay (well, they could just check it in parallel and just block further operations in case revocation is detected or, as they do for content, they could simply pre-fetch the information for usually visited resources).

Wrongly designed PKIs (or Weak PKIs) are being deployed today and expected to run for 30yrs when the algorithms that are supported (mainly in HW) are NOT going to pass the test of time - not on that scale, not for millions of people, not with devices that might handle our private data. This will affect our homes and the quality of Internet connections (degrading the user experience and creating huge issues for the operators in the future).

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

  * *There are NO venues where to discuss possible solutions to existing problems.* The PKIX working group has been closed down (very arbitrarily, I might say) and now expertise about the nuances of understanding and running PKIs is mostly lost or very difficult to chase.

  * *The LAMPS WG has, on purpose, a very limited Charter and only few items* (mostly quite marginal, I would say) are actually accepted as working items. Solving revocation should be the 1st item and the most important on the list... but it is not - actually when I proposed, it was not even acknowledged.

  * *The constant**nonsense of people saying that PKIs do not work as an excuse not to improve them while they are the reason we can deploy and manage security and provide privacy. *Eroding all the good work done in the past just because people do not understand the importance of providing BETTER support for Trust Management rather than a QUICK solution (e.g., short-lived certificates, mix of authorization and authentication, forgetting the existence of RFCs that already provide more secure solutions than the ones that are re-invented, today, over and over again).

Things are happening in other environments and lacking the support from IETF is really scary. The world moves forward and the IETF is standing still on this topic. I really do not understand why.

For example: what is more important, fixing internationalization for e-mail addresses or allowing the checking of revocation information in such a way that we can restrict the use of short-lived certificates only when STRICTLY necessary ?

Well.. things to consider.

I tried many times to push the issue without success... politics is the enemy of the right thing to do... and today we are just dealing with politicians when it comes to PKIs...

Just my 2 cents.. but I would be interested in your opinions too...

Cheers,
Max


On 7/18/17 5:47 PM, Erik Andersen wrote:

Hi David,

PKIX is not the whole world.

The smart grid security work within IEC TC57 WG15 does not refer to RFC 5280, but only to X.509. X.509 provides functionality, like authorization and validation lists (AVLs) not part  of any IETF specification.

In the smart grid and IoT world, traditional PKI techniques fall short. I believe that is what Max is trying to tell.

Erik

*Fra:*pkix [mailto:pkix-bounces@ietf.org] *På vegne af *David A. Cooper
*Sendt:* 18 July 2017 16:03
*Til:* Peter Gutmann <pgut001@cs.auckland.ac.nz>
*Cc:* PKIX <pkix@ietf.org>
*Emne:* Re: [pkix] Managing Long-Lived CA certs

Can you provide a citation for your claim that "PKIX says you're not allowed to use it. No reason given, you just can't."?

RFC 5280 says:

    This specification obsoletes [RFC3280].  Differences from RFC 3280 are summarized below:

          * Section 4.2.1.4 in RFC 3280, which specified the
            privateKeyUsagePeriod certificate extension but deprecated its
            use, was removed.  Use of this ISO standard extension is neither
            deprecated nor recommended for use in the Internet PKI.

"Use of this ISO standard extension is neither deprecated nor recommended" doesn't sound like "you just can't" to me.

On 07/17/2017 11:31 PM, Peter Gutmann wrote:

    Erik Andersen<era@x500.eu> <mailto:era@x500.eu>  writes:

        What about the private key usage period extension

    That would be the obvious choice, but PKIX says you're not allowed to use it.

    No reason given, you just can't.  This would imply that support for it in

    implementations is going to be hard to find...

    Peter.



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

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


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


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


--------------604E554BAE67906D779CABB1-- From nobody Thu Jul 20 02:23:18 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7546131BF7 for ; Thu, 20 Jul 2017 02:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=informatik.hu-berlin.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12Qb63IK4KHO for ; Thu, 20 Jul 2017 02:23:09 -0700 (PDT) Received: from mailout1.informatik.hu-berlin.de (mailout1.informatik.hu-berlin.de [141.20.20.101]) (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 ED592131892 for ; Thu, 20 Jul 2017 02:23:06 -0700 (PDT) Received: from mailbox.informatik.hu-berlin.de (mailbox [141.20.20.63]) by mail.informatik.hu-berlin.de (8.15.1/8.15.1/INF-2.0-MA-SOLARIS-2.10-25) with ESMTPS id v6K9N2iF023419 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 20 Jul 2017 11:23:03 +0200 (MEST) Received: from [192.168.2.102] (p548E68C4.dip0.t-ipconnect.de [84.142.104.196]) (authenticated bits=0) by mailbox.informatik.hu-berlin.de (8.15.1/8.15.1/INF-2.0-MA-SOLARIS-2.10-AUTH-26-465-587) with ESMTPSA id v6K9N1wK023411 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 20 Jul 2017 11:23:02 +0200 (MEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=informatik.hu-berlin.de; s=mailbox; t=1500542582; bh=gD2vCHIG6E3nFhrxPuBv62Sz+Af9QujFJ3zx50ilf20=; h=Subject:To:References:From:Date:In-Reply-To; b=Mi/oTwcCv0o2qdS0ApxDbMRan7YOxRESTcfSUcCeVWb3UpXuKyhr2fuqbsaMGfGoo DbeKXuZaMfLstpPLAOSfZbH5w9eRNuRdyI6+MT3vappie/YCdPJkK18teIKghkxsBy 2jOe4eh5097m3M63voqiHxqn9cDX8kWfIZVCTMzQ= To: pkix@ietf.org References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <003d01d2ffdd$35d67c70$a1837550$@x500.eu> From: EG Giessmann Message-ID: <3c9ca3d1-aee3-6b7c-5c4c-b701f59695e7@informatik.hu-berlin.de> Date: Thu, 20 Jul 2017 11:22:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mailbox X-Virus-Status: Clean X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.6.1 (mail.informatik.hu-berlin.de [141.20.20.50]); Thu, 20 Jul 2017 11:23:04 +0200 (MEST) Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:23:12 -0000 Just to support Denis: The so called validity time is defined as "the time interval during which the CA warrants that it will maintain information about the status of the public-key certificate." Therefore it is in fact a warranty time and not a validity time. /Ernst. From nobody Thu Jul 20 04:38:58 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0402E12EC30 for ; Thu, 20 Jul 2017 04:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEjSAw9cfrqr for ; Thu, 20 Jul 2017 04:38:54 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id D482C12969E for ; Thu, 20 Jul 2017 04:38:53 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 034D93740FB2 for ; Thu, 20 Jul 2017 07:38:52 -0400 (EDT) From: "Dr. Pala" To: PKIX Organization: OpenCA Labs Message-ID: Date: Thu, 20 Jul 2017 13:38:51 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8F97EEBA2922A529C2248FAA" Content-Language: en-US Archived-At: Subject: [pkix] Considerations about the need to resume PKIX work X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:38:56 -0000 This is a multi-part message in MIME format. --------------8F97EEBA2922A529C2248FAA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [ Cross-Post: LAMS and SAAG ] Hi all, I would like to draw the Sec Area attention on an issue that I think is becoming more relevant every day. It seems quite clear that today there is a lot of work around authentication and encryption that make use of PKIX certificates. However, there is no place in IETF, today, where problems related to PKIX can be effectively tackled. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussion around the feasibility of resuming the work in two particular areas: revocation and discoverability. *The Problem *What I noticed in recent proposals in many working groups (when it comes to certificate management) is that more and more people turn towards the use of short-lived certificates to avoid checking revocation information. Sometimes this choice is motivated by real technical considerations, but in many cases the choice is "forced" because nobody is currently working on fixing the two main issues related to trust infrastructures: efficient revocation and discoverability of services. *The Revocation Situation* Most of the times, when interacting with PKIs, we are still stuck with CRLs, OCSP if we are lucky (including stapling - available in TLS connections if really really lucky), and in most cases even these mechanisms are criticized widely by people as being inadequate today. This resulted in applications to use proprietary methods for checking revocation (e.g., CRLSet) or to skip checking all together (or mandate for short-lived certificates only as in the case, for example, of STIR). Many people today ignore the fact that, when coupled with small devices, the generation of new keys require (a) a lot of resources, and (b) a good source of randomness. Requiring apps / devices to generate new keys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of key management ? /Examples of possible work to address the issues are OCSP over DNS and some more efficient ways to verify the validity of a whole chain of certificates efficiently./ *The Discoverability Situation* As far as I know, there are no standardized mechanisms that would provide discoverability of services that would help users and applications to discover Public Key Services providers and associated services in a dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be discussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS). Isn't that curious that still today nobody is working on some sort of infrastructure that would facilitate interacting with PKIs ? After all, PKIs are the core Trust mechanism that enables reliable authentication and encryption over the Internet today. Such infrastructure could really improve the security of the Internet and make PKIs more usable from an application (and users) standpoint of view. /Examples of possible work to address the issue are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-configuration support for PK)./ *Deployment Trends in the Real World* Today I am witnessing the deployment of arguably not-well-designed PKIs (or, in other terms, what I call Weak PKIs) that do not provide support for revocation and that are expected to use CAs and EE certificates with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that it is a common assumption that the algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT going to pass the test of time, ignoring the revocation could really affect the privacy of millions of people - and we are currently not doing anything at the IETF to prevent this issue. /There is the need for simple revocation services, but arguably we do not have what's needed today (requires improvements)./ *IETF Specific Situation and Issues* Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in PKI discussions) that these might be some of the main reasons: * *There are NO venues where to discuss possible solutions to existing problems.* The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above) * *The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow scoped Charters and only few items**(mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular).* Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons. * *The constant**nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. *It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them. Moreover, things are happening in environments outside IETF (WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these problems is really scary to me. The world moves forward, fast, and the IETF is standing still on this topic./*I really do not understand why.*/ *Final Considerations* In this message I try to summarize the reasons why I think there is the need to provide a venue where these problems are discussed and the need for key people to not actively block the possibility for people that are willing to work on this to have a venue where the work can be carried out. I think that this work is of the utter importance and I would like to understand what the position of the whole security area is around these points and the proposed work. /I hope that the discussion around this message can spark some interest and that work in the PKIX area can finally resume at the IETF - which was, in the past, thought of as the lighthouse where these issues could be addressed./ A small request, please, try to read this e-mail carefully and consider the implications of NOT taking on these tasks when replying and/or discussing the topic. Also, since I know this (PKIX) is a minefield for "political" reasons (which should not be a drive here), please keep the discussion on the positive / constructive side (thanks). /If you feel like a private response is better than on the mailing list, please just reply privately./ Looking forward to hear your opinions on this hoping that this e-mail can be the beginning of the end of PKIX still-standing issues :D Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------8F97EEBA2922A529C2248FAA Content-Type: multipart/related; boundary="------------25BDD3985741D90503B7D5E6" --------------25BDD3985741D90503B7D5E6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

[ Cross-Post: LAMS and SAAG ]


Hi all,

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

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

The Problem

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

The Revocation Situation

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

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

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

The Discoverability Situation

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

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

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

Deployment Trends in the Real World

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

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

IETF Specific Situation and Issues

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

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

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

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

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

Final Considerations

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

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

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

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

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

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

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------25BDD3985741D90503B7D5E6 Content-Type: image/png; name="efhklhncoknghhph.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="efhklhncoknghhph.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------25BDD3985741D90503B7D5E6-- --------------8F97EEBA2922A529C2248FAA-- From nobody Thu Jul 20 05:15:28 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D037129B43 for ; Thu, 20 Jul 2017 05:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFx-s4uYHGcN for ; Thu, 20 Jul 2017 05:15:26 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B850129468 for ; Thu, 20 Jul 2017 05:15:26 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id f21so13535351wrf.5 for ; Thu, 20 Jul 2017 05:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=RIykXbmrkXsnaBrJFO0nJQ7OoZQxGGRv85/XDyAOmJU=; b=hKwPjJIgSl3qEnCcINddP+Icshxx1Jezrl2A6mYH5ZzwsMBiOIhLj+I14uRQ+9Ua/l BFxBqsf9O+Im3BerKXhcLz/JK9jMwFZYo979+oXi+AIHS12AZG8Glq1kz8LCnEOlhq8t X/eu2I1LuqB169tR+KyHxGhUPFwXev+GvDmvoCoAtceOPaoX4r9Ouo6DRseCjFxfz/pP 7xvzgGa/Y9lfq6hbKzfv8I7CzPsgp77qsitue8HBV4gs7uONj6XSpAEYS4lWr5zhvQS6 1McDkrUKPPXrQNBFna/9SPWioN6gHEGLsRmjslOhaWiQ4QBtU4MktuDr8vzQewUjENiO RHqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RIykXbmrkXsnaBrJFO0nJQ7OoZQxGGRv85/XDyAOmJU=; b=qdf/J7ypD5T79nFl6Y8VphHSTvKA/oCFfW60RFAq6i/sYRYOebuywRmy0QoVa5PVuw 2KzOSj+C7TBMAlVONWqCF+7IYEUZh1i0q9oQL+YkWe7lBjFAYQVa1ReA+PGuCVY+/MK+ AE5EVDBKIfp0yvAI8YtzTGihWxq+22DcePwkE/Y2bkjz0RYp56n9amavxJFKL1dud+zG 4mc9NgjQq5qjpCZPWIDmqrI64VF9U9D72jIlatc4INN62Uq2oa133+sfZeydqg4fqnlY nyOnYwgtQFOCBRtGA2Ze/86gnHCrJJ75nKwMeB1WP7YGXIm1NBtrtQntwd3XSVkzgseu Kgsg== X-Gm-Message-State: AIVw113baQQsuijfQ65v3gim0zy1U08ChtLTf9HlwTuQsjimxufnne/b UqdUMAEXMzYcPnFr X-Received: by 10.223.136.178 with SMTP id f47mr3375727wrf.250.1500552924452; Thu, 20 Jul 2017 05:15:24 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id o131sm2534738wmd.26.2017.07.20.05.15.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 05:15:23 -0700 (PDT) To: "Dr. Pala" , PKIX References: From: Anders Rundgren Message-ID: <5ac2abf1-f46a-8c95-9d33-3e20dc60daed@gmail.com> Date: Thu, 20 Jul 2017 14:15:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [pkix] Considerations about the need to resume PKIX work X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:15:27 -0000 Max, If we stick to the problem with outdated crypto algorithms, the only reasonable solution is updating keys (and software...) when needed. The latter is worked on in the IETF TEEP WG. Regarding the state of PKI, none of the PKIX enrollment protocols support MFA or key attestations. In fact, the entire PKIX WG were *against* such ideas (when raised by me) when EST was on the "drawing board". FIDO alliance products (of course) have this as a core facility. Anders From nobody Thu Jul 20 05:25:06 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6C812EC30 for ; Thu, 20 Jul 2017 05:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7vvHp-NXZx0 for ; Thu, 20 Jul 2017 05:25:02 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 188C5127058 for ; Thu, 20 Jul 2017 05:25:02 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 620D93740FB2 for ; Thu, 20 Jul 2017 08:25:01 -0400 (EDT) To: PKIX References: <5ac2abf1-f46a-8c95-9d33-3e20dc60daed@gmail.com> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <5ae70d92-00b2-8072-c28b-b9fd07c0adcf@openca.org> Date: Thu, 20 Jul 2017 14:24:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5ac2abf1-f46a-8c95-9d33-3e20dc60daed@gmail.com> Content-Type: multipart/alternative; boundary="------------1D49F266E1FC1D72E848ACC5" Content-Language: en-US Archived-At: Subject: Re: [pkix] Considerations about the need to resume PKIX work X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:25:03 -0000 This is a multi-part message in MIME format. --------------1D49F266E1FC1D72E848ACC5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Anders, Maybe, this time we might have a way in. I would be willing to work on it (even outside IETF, if there is no interest) and provide implementations in LibPKI. Easy and Secure "Provisioning / Enrollment" protocols are at the core for many ecosystems (e.g., IoT, WIFI, etc.). For the TEEP - I do not think they are going to address this particular issue/issues for what I have seen at the BoF. Let's talk about this - can you send me pointers you might think are useful to start from ? Cheers, Max On 7/20/17 2:15 PM, Anders Rundgren wrote: > Max, > > If we stick to the problem with outdated crypto algorithms, the only > reasonable solution is updating keys (and software...) when needed. > The latter is worked on in the IETF TEEP WG. > > Regarding the state of PKI, none of the PKIX enrollment protocols > support MFA or key attestations. In fact, the entire PKIX WG were > *against* such ideas (when raised by me) when EST was on the "drawing > board". FIDO alliance products (of course) have this as a core facility. > > Anders -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------1D49F266E1FC1D72E848ACC5 Content-Type: multipart/related; boundary="------------38160DD904DE0EEBA4A1D237" --------------38160DD904DE0EEBA4A1D237 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Anders,

Maybe, this time we might have a way in. I would be willing to work on it (even outside IETF, if there is no interest) and provide implementations in LibPKI. Easy and Secure "Provisioning / Enrollment" protocols are at the core for many ecosystems (e.g., IoT, WIFI, etc.). For the TEEP - I do not think they are going to address this particular issue/issues for what I have seen at the BoF.

Let's talk about this - can you send me pointers you might think are useful to start from ?

Cheers,
Max


On 7/20/17 2:15 PM, Anders Rundgren wrote:
Max,

If we stick to the problem with outdated crypto algorithms, the only reasonable solution is updating keys (and software...) when needed.  The latter is worked on in the IETF TEEP WG.

Regarding the state of PKI, none of the PKIX enrollment protocols support MFA or key attestations.  In fact, the entire PKIX WG were *against* such ideas (when raised by me) when EST was on the "drawing board". FIDO alliance products (of course) have this as a core facility.

Anders

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------38160DD904DE0EEBA4A1D237 Content-Type: image/png; name="fhjiobdolhgpmphd.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="fhjiobdolhgpmphd.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= --------------38160DD904DE0EEBA4A1D237-- --------------1D49F266E1FC1D72E848ACC5-- From nobody Thu Jul 20 08:35:33 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC414128BC8 for ; Thu, 20 Jul 2017 08:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YorBEXFbuHuf for ; Thu, 20 Jul 2017 08:35:30 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id EBA781252BA for ; Thu, 20 Jul 2017 08:35:29 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 2CB913740F3C for ; Thu, 20 Jul 2017 11:35:28 -0400 (EDT) To: pkix@ietf.org References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <003d01d2ffdd$35d67c70$a1837550$@x500.eu> From: "Dr. Pala" Message-ID: <01eab005-286c-0df9-400e-e1cecddfe50d@openca.org> Date: Thu, 20 Jul 2017 17:35:27 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------655D833E2AE4AC7E5E49668F" Content-Language: en-US Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:35:32 -0000 This is a multi-part message in MIME format. --------------655D833E2AE4AC7E5E49668F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Denis, replies inline... On 7/19/17 10:30 PM, Denis wrote: > Max, > > Just my 1 cent ... since you said you would be interested to hear > opinions. > > PKI is still very useful and used for servers, but it is no more > adequate to be used for user authentication over the net. Although I do disagree with you about this, I am not referring to this case specifically. > > Initially, privacy was not considered, but now it is. Using PKC for > users or clients allows to link user accounts between servers > whereas it is not the case with FIDO which has been built using > "privacy by design" principles. What we need today for human users > is no more only security but *both privacy and security* (where > privacy comes first). As I said, I am not really aiming at providing privacy but trying to (a) improve the revocation support in PKIs (the most pressing issue) and (b) provide a support system that would help applications to more easily make use of Public Key technologies (in my mind the target is not exclusively X509 PKIs, but that's just my personal thoughts). > > Coming back to your original proposal, I quote your text below: > > What I am thinking about would be adding an extension that says: > "This CA can issue certificates from up to 5 years from the > validFrom, > after this, just use it to provide revocation information". This > might provide some protection in case the CA key is compromised after > the initial 5 years of validity (e.g., certificates issued after > that date shall be rejected). > > The way you present the case violates one the fundamentals of PKI: A > certificate contains necessarily a validity period defined by: > > Validity ::= SEQUENCE { > notBeforeTime, > notAfterTime } > > A CA is not required to handle revocation, once the certificate has > expired. You are totally correct, however the simple proposal is not about changing the validity of a certificate, but limit a scope in the key usage for a CA cert in particular (but actually could be extended, if needed, to EE certs and particular key usages). > > However, before that sentence you wrote: > > Until we have a supported mechanism for reprovisioning devices > (...), one possible solution for limiting the exposure of the > private key > would be to have a scoped certificate issuance period. > > Hence you have identified the solution: work on a mechanism for > reprovisioning devices. We are working on this. However, updating in-field devices might not be an option. An additional mechanism that addresses today's solution (not mutually exclusive like you seem to imply) is something that, I think, should be considered. > RFC 2510 that was issued in the last century (March 1999) contains a > description on how to perform a root key change. > See section "2.4 Root CA key update". This might possibly help to > solve your problem. Denis, I do not understand the reference. We are not talking about updating Root Keys here (4210 and 6712 update the reference). Cross-Certification between the old and new infrastructures, the use of bridge CAs, the publication of the cross-certificate pair are all options there, but they are not relevant to the problem at hand. Can you please elaborate about how the Root CA rekeying is related to what I am tackling ? Thanks for your replies, I do appreciate the conversation - especially coming from people with your experience and your current affiliation (I love different points of view!). Cheers, Max --------------655D833E2AE4AC7E5E49668F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Denis,

replies inline...


On 7/19/17 10:30 PM, Denis wrote:
Max,

Just my 1 cent ... since you said you would be interested to hear opinions.

PKI is still very useful and used for servers, but it is no more adequate to be used for user authentication over the net.
Although I do disagree with you about this, I am not referring to this case specifically.

Initially, privacy was not considered, but now it is. Using PKC for users or clients allows to link user accounts between servers
whereas it is not the case with FIDO which has been built using "privacy by design" principles. What we need today for human users
is no more only security but both privacy and security (where privacy comes first).
As I said, I am not really aiming at providing privacy but trying to (a) improve the revocation support in PKIs (the most pressing issue) and (b) provide a support system that would help applications to more easily make use of Public Key technologies (in my mind the target is not exclusively X509 PKIs, but that's just my personal thoughts).


Coming back to your original proposal, I quote your text below:
What I am thinking about would be adding an extension that says: "This CA can issue certificates from up to 5 years from the validFrom,
after this, just use it to provide revocation information". This might provide some protection in case the CA key is compromised after
the initial 5 years of validity (e.g., certificates issued after that date shall be rejected).
The way you present the case violates one the fundamentals of PKI: A certificate contains necessarily a validity period defined by:

   Validity ::= SEQUENCE {
       notBefore      Time,
       notAfter         Time }

A CA is not required to handle revocation, once the certificate has expired.
You are totally correct, however the simple proposal is not about changing the validity of a certificate, but limit a scope in the key usage for a CA cert in particular (but actually could be extended, if needed, to EE certs and particular key usages).


However, before that sentence you wrote:
Until we have a supported mechanism for reprovisioning devices (...), one possible solution for limiting the exposure of the private key
would be to have a scoped certificate issuance period.
Hence you have identified the solution: work on a mechanism for reprovisioning devices.
We are working on this. However, updating in-field devices might not be an option. An additional mechanism that addresses today's solution (not mutually exclusive like you seem to imply) is something that, I think, should be considered.
RFC 2510 that was issued in the last century (March 1999) contains a description on how to perform a root key change.
See  section "2.4 Root CA key update". This might possibly help to solve your problem.
Denis, I do not understand the reference. We are not talking about updating Root Keys here (4210 and 6712 update the reference). Cross-Certification between the old and new infrastructures, the use of bridge CAs, the publication of the cross-certificate pair are all options there, but they are not relevant to the problem at hand.

Can you please elaborate about how the Root CA rekeying is related to what I am tackling ?

Thanks for your replies, I do appreciate the conversation - especially coming from people with your experience and your current affiliation (I love different points of view!).

Cheers,
Max




--------------655D833E2AE4AC7E5E49668F-- From nobody Thu Jul 20 08:38:38 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B05131CCA for ; Thu, 20 Jul 2017 08:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVVCSbWTFPts for ; Thu, 20 Jul 2017 08:38:35 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 9155E131CB6 for ; Thu, 20 Jul 2017 08:38:35 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 16B373740F3C for ; Thu, 20 Jul 2017 11:38:34 -0400 (EDT) To: pkix@ietf.org References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <1500387403338.42595@cs.auckland.ac.nz> <1500391529591.47499@cs.auckland.ac.nz> <1500416769.24548519@apps.rackspace.com> From: "Dr. Pala" Message-ID: <35460c78-baac-b90c-6b65-60a01bebd04c@openca.org> Date: Thu, 20 Jul 2017 17:38:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1500416769.24548519@apps.rackspace.com> Content-Type: multipart/alternative; boundary="------------789C9D02E62FEB9FC75F88C7" Content-Language: en-US Archived-At: Subject: Re: [pkix] Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:38:37 -0000 This is a multi-part message in MIME format. --------------789C9D02E62FEB9FC75F88C7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Steve, that is a comment that definitely comes from an old PKIX-er :D I totally understand where you come from, but with good will we can break out of old habits and actually make the world a better place together :D I hope I can provide some inspiration for people to focus on real problems :D Don't give up! Cheers, Max On 7/19/17 12:26 AM, swilson@lockstep.com.au wrote: > > This is why we in PKI can't have nice things. > > Cheers, > > Steve. > > --------------789C9D02E62FEB9FC75F88C7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Steve,

that is a comment that definitely comes from an old PKIX-er :D I totally understand where you come from, but with good will we can break out of old habits and actually make the world a better place together :D I hope I can provide some inspiration for people to focus on real problems :D

Don't give up!

Cheers,
Max


On 7/19/17 12:26 AM, swilson@lockstep.com.au wrote:

 

This is why we in PKI can't have nice things. 

 

Cheers,

 

Steve.

 



--------------789C9D02E62FEB9FC75F88C7-- From nobody Thu Jul 20 08:53:42 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A871B131838 for ; Thu, 20 Jul 2017 08:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxT1BF8_P0zh for ; Thu, 20 Jul 2017 08:53:34 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E974131C73 for ; Thu, 20 Jul 2017 08:53:31 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id k71so19066675wrc.2 for ; Thu, 20 Jul 2017 08:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=5w1Wevp+V4p7mZgqSYNloQI249U2GKnrn+gKvs+EhRc=; b=s7PcTvu8dpiWgC70Ka1GC7b6w4DaWSbGI9NfPrqLy3FMybGGTkrn+1Os3dJrk0hJhi /64CaQiy7trA/v7CygZYOLZ/1XK0FYN+ilFDDLsxYDANzMQfWOgfFwV3iOUp4zL7eQPV eJINafFWvYhlP6cuIYyuu/N0QCPEEViVlF0m+RS8npuqk7eYh5p5d+bIoy5agbsUR76r 03E1bzB6Yiv6Q1ivZxMURFA1ArxCBmfTngktDuketDbFUNCyY5nEesEM/UfB4B+kU3eJ Bsj7EYk2wURHMcNiYTc4VOwgnOXxMrLe0FE25C6UuEKcd1EzpZNNLQU5io2oMIHUFgeX xnmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5w1Wevp+V4p7mZgqSYNloQI249U2GKnrn+gKvs+EhRc=; b=mqTZlLtJJw6jN2+tF+vjxUr8JqBVYSUcAehAePoZgdD/+P3n4kkOj59ozPCTRLJ+bt MyFSX4PB1yN2B64sPqcut5g5IU+Jo25s5EZn8ByM/msY6WmAocYtVe3F+NSF0zyZbrb/ fU33xDV6Rvhg1rPNOILpLDwcS92cw9NUvDqdyKSh9AMvKSmm9sCHU3HjMVQzTSo33wqQ JFk8MUqPjBUBtwTvtqRd+4VTPtY10zUa2R4N7Qiyqc/1RxHTtOW2NBdBJEPc3WuwHugP 92oFYsrcSY2blskAyxQ+qC1zwvlVf7Z+abUvdf6tfhQmNnCZ+B+wXrM+l1IgQISzltbv 587A== X-Gm-Message-State: AIVw111Iv5KEhLDM7Rx+07eLWurKa8J/WtA0KX3jGDShNQAsmzzxzNaf nKDrTFhaOTjeq/uW X-Received: by 10.223.179.71 with SMTP id k7mr3737816wrd.232.1500566009501; Thu, 20 Jul 2017 08:53:29 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id v203sm2801002wmd.2.2017.07.20.08.53.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 08:53:28 -0700 (PDT) To: "Dr. Pala" , PKIX References: <5ac2abf1-f46a-8c95-9d33-3e20dc60daed@gmail.com> <5ae70d92-00b2-8072-c28b-b9fd07c0adcf@openca.org> From: Anders Rundgren Message-ID: <4e6c434d-2452-3d54-13fd-3d38fdda950d@gmail.com> Date: Thu, 20 Jul 2017 17:53:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5ae70d92-00b2-8072-c28b-b9fd07c0adcf@openca.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [pkix] Considerations about the need to resume PKIX work X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 15:53:41 -0000 On 2017-07-20 14:24, Dr. Pala wrote: > Hi Anders, Hi Max, > > Maybe, this time we might have a way in. I would be willing to work on it (even outside IETF, if there is no interest) and provide implementations in LibPKI. Easy and Secure "Provisioning / Enrollment" protocols are at the core for many ecosystems (e.g., IoT, WIFI, etc.). For the TEEP - I do not think they are going to address this particular issue/issues for what I have seen at the BoF. > > Let's talk about this - can you send me pointers you might think are useful to start from ? Oh, there are virtually TONs of possible and potentially useful crypto-related projects out there. I have over the years provided plenty of pointers in PKIX to such with quite limited feedback. The crux is getting anything implemented as well as getting some kind of funding. There are more subtle hurdles as well. If you are not world-renowned cryptographer or working for a well-known (US) technology provider nobody will even read your papers. I do currently not work with IoT or WiFi authentication so I may be a less useful partner. I'm rather trying to create a scheme for challenging CENTRALIZED payment schemes like Android and Apple Pay through a DECENTRALIZED trust infrastructure. https://mobilepki.org/webpay-acquirer/payees/86344 It is so full of crypto that hardly any bank-tech folks get it :-| Anders > > Cheers, > Max > > > On 7/20/17 2:15 PM, Anders Rundgren wrote: >> Max, >> >> If we stick to the problem with outdated crypto algorithms, the only reasonable solution is updating keys (and software...) when needed. The latter is worked on in the IETF TEEP WG. >> >> Regarding the state of PKI, none of the PKIX enrollment protocols support MFA or key attestations. In fact, the entire PKIX WG were *against* such ideas (when raised by me) when EST was on the "drawing board". FIDO alliance products (of course) have this as a core facility. >> >> Anders > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > OpenCA Logo > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From nobody Thu Jul 20 09:40:02 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8308131945 for ; Thu, 20 Jul 2017 09:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEPkt4Lsap3O for ; Thu, 20 Jul 2017 09:39:59 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id CCA3A131714 for ; Thu, 20 Jul 2017 09:39:58 -0700 (PDT) Received: from dhcp-8e48.meeting.ietf.org (dhcp-8e48.meeting.ietf.org [31.133.142.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id C6C5A3740F3C; Thu, 20 Jul 2017 12:39:57 -0400 (EDT) To: Anders Rundgren , PKIX References: <5ac2abf1-f46a-8c95-9d33-3e20dc60daed@gmail.com> <5ae70d92-00b2-8072-c28b-b9fd07c0adcf@openca.org> <4e6c434d-2452-3d54-13fd-3d38fdda950d@gmail.com> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <8ef7a28d-538b-2d83-2dc0-91e22ef3f98f@openca.org> Date: Thu, 20 Jul 2017 18:39:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <4e6c434d-2452-3d54-13fd-3d38fdda950d@gmail.com> Content-Type: multipart/alternative; boundary="------------40AC826DDE7D1E9447C796D1" Content-Language: en-US Archived-At: Subject: Re: [pkix] Considerations about the need to resume PKIX work X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 16:40:01 -0000 This is a multi-part message in MIME format. --------------40AC826DDE7D1E9447C796D1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Thanks Anders, DISCLAIMER: I just want to clarify that this discussion is not part of what I proposed as work on revocation. This said, I would say that if your attempt to provide a decentralized system for payments would benefit from the work around revocation and / or discoverability, I would be interested to read about the use-cases there. Thanks, Max On 7/20/17 5:53 PM, Anders Rundgren wrote: > On 2017-07-20 14:24, Dr. Pala wrote: >> Hi Anders, > > Hi Max, > >> >> Maybe, this time we might have a way in. I would be willing to work >> on it (even outside IETF, if there is no interest) and provide >> implementations in LibPKI. Easy and Secure "Provisioning / >> Enrollment" protocols are at the core for many ecosystems (e.g., IoT, >> WIFI, etc.). For the TEEP - I do not think they are going to address >> this particular issue/issues for what I have seen at the BoF. >> >> Let's talk about this - can you send me pointers you might think are >> useful to start from ? > > Oh, there are virtually TONs of possible and potentially useful > crypto-related projects out there. > > I have over the years provided plenty of pointers in PKIX to such with > quite limited feedback. > The crux is getting anything implemented as well as getting some kind > of funding. > > There are more subtle hurdles as well. If you are not world-renowned > cryptographer or > working for a well-known (US) technology provider nobody will even > read your papers. > > I do currently not work with IoT or WiFi authentication so I may be a > less useful partner. > > I'm rather trying to create a scheme for challenging CENTRALIZED > payment schemes > like Android and Apple Pay through a DECENTRALIZED trust infrastructure. > https://mobilepki.org/webpay-acquirer/payees/86344 > It is so full of crypto that hardly any bank-tech folks get it :-| -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------40AC826DDE7D1E9447C796D1 Content-Type: multipart/related; boundary="------------5C39FD260A07CD390F315D69" --------------5C39FD260A07CD390F315D69 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thanks Anders,

DISCLAIMER: I just want to clarify that this discussion is not part of what I proposed as work on revocation.

This said, I would say that if your attempt to provide a decentralized system for payments would benefit from the work around revocation and / or discoverability, I would be interested to read about the use-cases there.

Thanks,
Max


On 7/20/17 5:53 PM, Anders Rundgren wrote:
On 2017-07-20 14:24, Dr. Pala wrote:
Hi Anders,

Hi Max,


Maybe, this time we might have a way in. I would be willing to work on it (even outside IETF, if there is no interest) and provide implementations in LibPKI. Easy and Secure "Provisioning / Enrollment" protocols are at the core for many ecosystems (e.g., IoT, WIFI, etc.). For the TEEP - I do not think they are going to address this particular issue/issues for what I have seen at the BoF.

Let's talk about this - can you send me pointers you might think are useful to start from ?

Oh, there are virtually TONs of possible and potentially useful crypto-related projects out there.

I have over the years provided plenty of pointers in PKIX to such with quite limited feedback.
The crux is getting anything implemented as well as getting some kind of funding.

There are more subtle hurdles as well.  If you are not world-renowned cryptographer or
working for a well-known (US) technology provider nobody will even read your papers.

I do currently not work with IoT or WiFi authentication so I may be a less useful partner.

I'm rather trying to create a scheme for challenging CENTRALIZED payment schemes
like Android and Apple Pay through a DECENTRALIZED trust infrastructure.
https://mobilepki.org/webpay-acquirer/payees/86344
It is so full of crypto that hardly any bank-tech folks get it :-|

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------5C39FD260A07CD390F315D69 Content-Type: image/png; name="bdknaakfpokbhmhi.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="bdknaakfpokbhmhi.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= --------------5C39FD260A07CD390F315D69-- --------------40AC826DDE7D1E9447C796D1-- From nobody Thu Jul 20 12:56:37 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69956131B8D for ; Thu, 20 Jul 2017 12:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdGU0Lm-1CSf for ; Thu, 20 Jul 2017 12:56:25 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A67131B80 for ; Thu, 20 Jul 2017 12:56:24 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id 33so18288534wrz.4 for ; Thu, 20 Jul 2017 12:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=6NnWhYRYS66pxmRSfdpj7eekC7ZMtH2dN0Pk3wlzC4Q=; b=F9a1ljDpjkj94XW+XQE15pppbusgmgH7Oxgn2NQyhZcSSsxGu4RNgpbKbY9Kh4AdfY BP5xjHK2lopGpSC8U1kCRARXIzajIZIGjh/vElF7dHzVuw9WDULED2tDh53Dn5YNjzcd OWe9c3zUTA7pigpR6MfJ2nVl56VV2qTwjVUwDgOfmC17399FJ01jGGcVMfMqi5bNNTUu B1DevVJ7s2aQU4XneKqkl8fBwqfR1QSotFepYEun55C8tjtIXJfsakxnIUs3ni/SqNHH wcaaVPMB6Jv93Vvh+KVKcsVb0HziYyZGUMVwKrELOc7lQv+bOgHJsEaoDsh99Hp0o3ne /MtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6NnWhYRYS66pxmRSfdpj7eekC7ZMtH2dN0Pk3wlzC4Q=; b=VGdKWMsxSY0pCADSKhD/b+9RgknfvqsKefl6iwXn46O8HpBy4Esjq7+tG/n32ffM5W wqGGnSWNyGM2gfy5N2xRl3CSbpR2lwgd+RLqZLEMoOBsKHK0dTgNQuwOQ6NcAZMUvOQX fHSE61m6wxRHCphLFgd8Yi51syKx/vaiLmCcmABdm1nczfICUy7S5332CsU6kqEb7j0Z nZN63sv48x0UreNgqD1P0ILVFcDwGUxBJLkEZ6GsEBTv3GtZhn5cKLtVBtPvZ2dCWXy9 m/seYZGrqtxbze1pIXrU2Xdr2ALqAKaR2Q3lJjqW4FlnXkXC1LIp8jCdDpOKvoGY+G45 MbBA== X-Gm-Message-State: AIVw111RLVsReKp4d4jFD9ISlt9H2en7ovH/drTJobuv1m9LZKhCN/wR LvZtj+MxDAUF69j7 X-Received: by 10.223.128.209 with SMTP id 75mr7063024wrl.99.1500580583250; Thu, 20 Jul 2017 12:56:23 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id b23sm722467wrd.40.2017.07.20.12.56.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 12:56:22 -0700 (PDT) To: "Dr. Pala" , PKIX References: <5ac2abf1-f46a-8c95-9d33-3e20dc60daed@gmail.com> <5ae70d92-00b2-8072-c28b-b9fd07c0adcf@openca.org> <4e6c434d-2452-3d54-13fd-3d38fdda950d@gmail.com> <8ef7a28d-538b-2d83-2dc0-91e22ef3f98f@openca.org> From: Anders Rundgren Message-ID: <1a9cc410-7312-227e-7e5b-f715f86f9bdd@gmail.com> Date: Thu, 20 Jul 2017 21:56:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8ef7a28d-538b-2d83-2dc0-91e22ef3f98f@openca.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [pkix] Considerations about the need to resume PKIX work X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 19:56:35 -0000 On 2017-07-20 18:39, Dr. Pala wrote: > Thanks Anders, > > DISCLAIMER: I just want to clarify that this discussion is not part of what I proposed as work on revocation. > > This said, I would say that if your attempt to provide a decentralized system for payments would benefit from the work around revocation and / or discoverability, I would be interested to read about the use-cases there. Hi Max, The system I'm working with is fairly unconventional and maybe not in your taste. If you take a peek at the link I provided (and associated documents), you will find a "Pseudo CA" issuing short-lived certificate-like objects expressed in JSON. Why "Pseudo CA"? Because a true X.509 solution would not meet the decentralization objectives. Since the payment messages were based on JSON and use the definitions in the certificate-like objects, it seemed logical to use JSON everywhere it was possible. IoT is an entirely different animal than payments (although some IoT devices can be payers as well). PKI for user auth was severely wounded by the [not so] smart card industry. The final kill was made by Google who removed on-line provisioning from Chrome. Not even the inventor of the Web, Sir Berners-Lee could save it: https://lists.w3.org/Archives/Public/www-tag/2015Sep/0000.html Cheers, Anders > > Thanks, > Max > > > On 7/20/17 5:53 PM, Anders Rundgren wrote: >> On 2017-07-20 14:24, Dr. Pala wrote: >>> Hi Anders, >> >> Hi Max, >> >>> >>> Maybe, this time we might have a way in. I would be willing to work on it (even outside IETF, if there is no interest) and provide implementations in LibPKI. Easy and Secure "Provisioning / Enrollment" protocols are at the core for many ecosystems (e.g., IoT, WIFI, etc.). For the TEEP - I do not think they are going to address this particular issue/issues for what I have seen at the BoF. >>> >>> Let's talk about this - can you send me pointers you might think are useful to start from ? >> >> Oh, there are virtually TONs of possible and potentially useful crypto-related projects out there. >> >> I have over the years provided plenty of pointers in PKIX to such with quite limited feedback. >> The crux is getting anything implemented as well as getting some kind of funding. >> >> There are more subtle hurdles as well. If you are not world-renowned cryptographer or >> working for a well-known (US) technology provider nobody will even read your papers. >> >> I do currently not work with IoT or WiFi authentication so I may be a less useful partner. >> >> I'm rather trying to create a scheme for challenging CENTRALIZED payment schemes >> like Android and Apple Pay through a DECENTRALIZED trust infrastructure. >> https://mobilepki.org/webpay-acquirer/payees/86344 >> It is so full of crypto that hardly any bank-tech folks get it :-| > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > OpenCA Logo From nobody Thu Jul 20 20:23:43 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C08131D71 for ; Thu, 20 Jul 2017 20:23: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wzb6fC4eovDp for ; Thu, 20 Jul 2017 20:23:40 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C6B131D70 for ; Thu, 20 Jul 2017 20:23:40 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id w191so3062557wmw.1 for ; Thu, 20 Jul 2017 20:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=QVmY4RI2e3uLVKp6lxlKbUoBPpSLtDxAb+p9+Keag1E=; b=V6XLMae3E7w2Ndhk4i3RgOSR6UK/94kiUwBX2+AEqP4u5uWcgINdoPRQKVBlLIhjw0 VsdT9HJx4hCxmxLDCBdnnaOPKzII8aQ3tGxLgWDXEMcv+AOFMp6cNYYJyo56/i0msdlE 9FFfJKntl0J2Bqd/arxH5hBLzyl8GEA9XRp+E7VhYyNBasuDd0Irh6o7+8fsHYGgdeZU a/Q9d14annbje2mgpvHtmSLLXdFkpX2v9/Htr3UEApCf8AwTO6/t5MZYMVf5EJB8flgA GiDeTlQqLya6q8x00VLf0KlsVbzSInI+pKW4o1OUl+BLqbxw5CeXgYPx/DQMAUN0JCxM q4eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QVmY4RI2e3uLVKp6lxlKbUoBPpSLtDxAb+p9+Keag1E=; b=NIj7QuENkqwUKY/WpKXoWsAHpTUwU/3a3I27VrLTAj/zOmpBzrsX+pOtSL3c/5vw7V kBLUrcMLZwuNbj8q/nN9vva1l1By4vvWaDprhvIweZ7potNjvvR2iDGeW261w7wTrplN B+ohpWqf5fAJsFhMHhBColVZ+GVApZ2mBuE7tqIwFMN0z+Z+Oz45mznzo1tE97Ps9U7o ssdXVbJ1CpHQkxRyf0NcLSqHjiVsKmgk8DAoXtOpn8DcZCOKF5wU4CEN5JfSOpwgyldZ aCQIwhCKwNuBadusDGrPg5JzcMvn1ZHumIzlFWiqX5HVxGYblu+M3dRUJ/ytWc+TvUlY jShQ== X-Gm-Message-State: AIVw113zHJNWTNxn6+Z3CVTQN84C1nxlYRwKJkPs5PRkamAQxAcbPiG0 FBXO6X9xg3N1l4NP X-Received: by 10.28.22.207 with SMTP id 198mr768098wmw.119.1500607418607; Thu, 20 Jul 2017 20:23:38 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id 82sm346750wmt.17.2017.07.20.20.23.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 20:23:38 -0700 (PDT) To: pkix@ietf.org References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <003d01d2ffdd$35d67c70$a1837550$@x500.eu> From: Anders Rundgren Message-ID: Date: Fri, 21 Jul 2017 05:23:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [pkix] Upgradable/Replaceable IoT systems. Re: Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 03:23:42 -0000 Hi, It is not uncommon that there are more than one imaginable solution to a problem. In this case there is an obvious alternative to what is proposed. Assume that a system * in some way becomes obsolete. If such a system represents a considerable investment AND needs to live for decades, it should be upgradable. If OTOH the system is not upgradable, it should be replaced. If an IoT device only supports outdated algorithms it is anyway vulnerable to attacks making workarounds on the CA side fairly useless. BTW, who in their right mind would run a CA with compromised keys or a CA for obsolete devices? Anders * System in this context involves the entire infrastructure, including possible CAs. > Hi PKIX, > > I have a small question for the list regarding long-lived CA > certificates. Especially in the context of device certificates, we often > see the use of extra long-lived certificates for Root and Sub CAs (e.g., > 35+ years) combined with limited key sizes (e.g., p256). > > Until we have a supported mechanism for reprovisioning devices (...), > one possible solution for limiting the exposure of the private key would > be to have a scoped certificate issuance period. > > What I am thinking about would be adding an extension that says: "This > CA can issue certificates from up to 5 years from the validFrom, after > this, just use it to provide revocation information". This might provide > some protection in case the CA key is compromised after the initial 5 > years of validity (e.g., certificates issued after that date shall be > rejected). > > Does such extension exists today ? If not, could this be some work for > LAMPS/SPASM WG ? From nobody Thu Jul 20 22:01:51 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF78129B7A for ; Thu, 20 Jul 2017 22:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKxDP0PAV68y for ; Thu, 20 Jul 2017 22:01:47 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB17126C23 for ; Thu, 20 Jul 2017 22:01:47 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id e131so4132448wme.0 for ; Thu, 20 Jul 2017 22:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=jvpfiPlcprH50MpwLfw8b6qS8ygfvG5q1eHMomd78Eg=; b=f0AODHRXaq7DExCrHQA/JnpIpeN/w/2RubSqh8l1hR0Igz+/lVygeLimuGiFWBSZqJ JVdrwGg5SUNd3LzlUQV8r07lsqYdxFpQEk1axbSJQx4/BG7U1NE530+YCDgD5wpv6cB8 A/IJX4ln7tBvdudEVlkOtdt4xEgrc2nB6XDO5mcfpjDPwupWAUgX3iPEp5ribGPuuNma 8DskzGxdgH38/OThSDgL6u/c9HY3otRhKgRojy7Am4tuTTBgEKOuj33Qk6FqohcE71LB 2W9rE3MpmmNav7mMKqU7f2YvzAsW0c+ey2DAqZSn2RK7aDcWcODzPuG9BGZ0AEBt8q5C eByA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jvpfiPlcprH50MpwLfw8b6qS8ygfvG5q1eHMomd78Eg=; b=N4fG9sG3FvnlUYMxaL2QVQhTDZ3uMCmt7lch4jDHVR8uciVbAX3DnR2lttoRwVGGqz IJd3k2GbcWt3ZXexAmKVCG77+nuPs7FxOCaaGV2bQwzbgb0oa3hslrQW16+ujeJn3Npr SNWJ8qstWQBAMuIe8gkr4dP3y9W2IBCViXkZuGeNc0FhuVpJYGx13DB5uUod2WQsVQ75 r+0hzI4aiXGt3Lil37Qskr3a4adbE8GWf5zaD+FKkVEV1WiOcRYcRLO3f8bQid5pVb1k fBt55FzhE0YiQ0PT2AfzdnZwzqaaUjjRiR999Z+8D1T+UEfC3einPhkDGIE0O/0PGEe1 WQmw== X-Gm-Message-State: AIVw111r5xeEL3bBfoNNqB0RSZ1jD9NoojFZ1vZbqswD2Myhwm+/99o0 dSB2n7K4gkh+WQsy X-Received: by 10.28.230.199 with SMTP id e68mr4220865wmi.138.1500613305297; Thu, 20 Jul 2017 22:01:45 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id 94sm12969104wrb.55.2017.07.20.22.01.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 22:01:44 -0700 (PDT) From: Anders Rundgren To: pkix@ietf.org References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <003d01d2ffdd$35d67c70$a1837550$@x500.eu> Message-ID: <0edcee2d-3dea-bbaa-2cd1-cf3915bfeff7@gmail.com> Date: Fri, 21 Jul 2017 07:01:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [pkix] Connected Cars. Upgradable/Replaceable IoT systems. Re: Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 05:01:49 -0000 My guess is that 10-15Y+ old connected cars won't be permitted on public roads unless they are upgraded. Upgrading really old cars will become a major task since the electronics is unlikely to actually be upgradable. Anders On 2017-07-21 05:23, Anders Rundgren wrote: > Hi, > > It is not uncommon that there are more than one imaginable solution to a problem. > > In this case there is an obvious alternative to what is proposed. > Assume that a system * in some way becomes obsolete. > > If such a system represents a considerable investment AND needs to live for decades, it should be upgradable. > > If OTOH the system is not upgradable, it should be replaced. > > If an IoT device only supports outdated algorithms it is anyway vulnerable to attacks making workarounds on the CA side fairly useless. > > BTW, who in their right mind would run a CA with compromised keys or a CA for obsolete devices? > > Anders > * System in this context involves the entire infrastructure, including possible CAs. > >> Hi PKIX, >> >> I have a small question for the list regarding long-lived CA >> certificates. Especially in the context of device certificates, we often >> see the use of extra long-lived certificates for Root and Sub CAs (e.g., >> 35+ years) combined with limited key sizes (e.g., p256). >> >> Until we have a supported mechanism for reprovisioning devices (...), >> one possible solution for limiting the exposure of the private key would >> be to have a scoped certificate issuance period. >> >> What I am thinking about would be adding an extension that says: "This >> CA can issue certificates from up to 5 years from the validFrom, after >> this, just use it to provide revocation information". This might provide >> some protection in case the CA key is compromised after the initial 5 >> years of validity (e.g., certificates issued after that date shall be >> rejected). >> >> Does such extension exists today ? If not, could this be some work for >> LAMPS/SPASM WG ? > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From nobody Fri Jul 21 13:01:25 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37AC12ECAD for ; Fri, 21 Jul 2017 13:01:23 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYq_t6mP1G30 for ; Fri, 21 Jul 2017 13:01:22 -0700 (PDT) Received: from mail2.safelayer.com (mail2.safelayer.com [80.25.227.156]) (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 844A2129B25 for ; Fri, 21 Jul 2017 13:01:22 -0700 (PDT) Received: from [192.168.8.23] (port=54168 helo=mailmad.safelayer.lan) by mail2.safelayer.com with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dYe6s-0000Db-2W for pkix@ietf.org; Fri, 21 Jul 2017 22:01:14 +0200 Auto-Submitted: auto-generated From: Cesar Armenta To: pkix@ietf.org Message-ID: Date: Fri, 21 Jul 2017 22:01:15 +0200 X-MIMETrack: Serialize by Router on mailmad/SFLY(Release 9.0.1FP8|February 23, 2017) at 21/07/2017 22:01:15 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Archived-At: Subject: [pkix] AUTO: Cesar Armenta is out of office (returning 31/07/2017) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 20:01:24 -0000 I am out of the office until 31/07/2017. Me encuentro fuera de la oficina hasta el 31/07/2017. Si se trata de alguna cuesti=F3n urgente, por favor, escriba a support@safelayer.com I am out of the office until July 31st 2017 For any urgent matters, please contact support@safelayer.com Note: This is an automated response to your message "pkix Digest, Vol = 96, Issue 13" sent on 21/07/2017 21:00:17. This is the only notification you will receive while this person is awa= y.= From nobody Mon Jul 24 06:23:20 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F899131CFB for ; Mon, 24 Jul 2017 06:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZsSEy1efAIU for ; Mon, 24 Jul 2017 06:23:16 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 B2C78131D05 for ; Mon, 24 Jul 2017 06:23:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D20376215F; Mon, 24 Jul 2017 09:23:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03xnbnptBwcR; Mon, 24 Jul 2017 09:23:08 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id C5E766219D; Mon, 24 Jul 2017 09:23:07 -0400 (EDT) To: Anders Rundgren , pkix@ietf.org References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <003d01d2ffdd$35d67c70$a1837550$@x500.eu> <0edcee2d-3dea-bbaa-2cd1-cf3915bfeff7@gmail.com> From: Robert Moskowitz Message-ID: <07553cee-882a-74e3-569f-2c501461f2dd@htt-consult.com> Date: Mon, 24 Jul 2017 09:23:05 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0edcee2d-3dea-bbaa-2cd1-cf3915bfeff7@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [pkix] Connected Cars. Upgradable/Replaceable IoT systems. Re: Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 13:23:19 -0000 I have consulted a few auto OEMs on matters like this. Today, and actually for a few years, all devices with software MUST be field (minimum dealer) upgradeable. And some support 'over the air' updates. This includes the 'telematics' control unit where up to now, has been the only component with certificates. I worked on three telematics certificate systems. The IEEE 1609.2 standard for Vehicle safety messaging has a 'monster' PKI with certificate management. To put it mildly. However, IEEE 802.1AR 'Device Identity' standard defines the iDevID as a permanent, non-mutable certificate with expected 10 - 20 year life. Yeah lots of issues with this. Lots of reasons for this approach. Note that the iDevID is only used for proof on manufacturer identity when enrolling in the buyer's PKI with the lDevID (see ANIMA that is using these). It may also be used in firmware updates from the manufacturer. Thus the iDevID is not intended to be an 'operational' certifcate. Further note that 802.1AR certificates MAY be a major player in the future (perhaps as early as 2019 vehicles) Automotive Ethernet sensor networks (as may 802.1AE mac security). Bob On 07/21/2017 01:01 AM, Anders Rundgren wrote: > My guess is that 10-15Y+ old connected cars won't be permitted on > public roads unless they are upgraded. > Upgrading really old cars will become a major task since the > electronics is unlikely to actually be upgradable. > > Anders > > On 2017-07-21 05:23, Anders Rundgren wrote: >> Hi, >> >> It is not uncommon that there are more than one imaginable solution >> to a problem. >> >> In this case there is an obvious alternative to what is proposed. >> Assume that a system * in some way becomes obsolete. >> >> If such a system represents a considerable investment AND needs to >> live for decades, it should be upgradable. >> >> If OTOH the system is not upgradable, it should be replaced. >> >> If an IoT device only supports outdated algorithms it is anyway >> vulnerable to attacks making workarounds on the CA side fairly useless. >> >> BTW, who in their right mind would run a CA with compromised keys or >> a CA for obsolete devices? >> >> Anders >> * System in this context involves the entire infrastructure, >> including possible CAs. >> >>> Hi PKIX, >>> >>> I have a small question for the list regarding long-lived CA >>> certificates. Especially in the context of device certificates, we >>> often >>> see the use of extra long-lived certificates for Root and Sub CAs >>> (e.g., >>> 35+ years) combined with limited key sizes (e.g., p256). >>> >>> Until we have a supported mechanism for reprovisioning devices (...), >>> one possible solution for limiting the exposure of the private key >>> would >>> be to have a scoped certificate issuance period. >>> >>> What I am thinking about would be adding an extension that says: "This >>> CA can issue certificates from up to 5 years from the validFrom, after >>> this, just use it to provide revocation information". This might >>> provide >>> some protection in case the CA key is compromised after the initial 5 >>> years of validity (e.g., certificates issued after that date shall be >>> rejected). >>> >>> Does such extension exists today ? If not, could this be some work for >>> LAMPS/SPASM WG ? >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From nobody Mon Jul 24 06:54:32 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9E8131D19 for ; Mon, 24 Jul 2017 06:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJ37SzMpx0Fc for ; Mon, 24 Jul 2017 06:54:28 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C80131771 for ; Mon, 24 Jul 2017 06:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1500904468; x=1532440468; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0i1HS2wS19D/LYv2cZ9mK9da511Hu5Uhnv64tIrS6c4=; b=HsQgnwVfT2vQMzmti5bJ4OYHnPBP+BpvoAt+YOATF6qlkoQQGXvW+wj1 0J18phZyQ9wWiu/yEBEHkL13O0vGFaotOT8NYxbV5RHKaoNJ2z6ifsr7Y 2Ekm0oX0ghFiFLlzvPu662EZJvUmjOI0mlDSMoHSu5nPIA/2vbEIpdzXn PkTVy+bad1GYEuvmMsIOwDgwzZjjeffsjHpNsbR4fIgFjigybZBAqpNUM I16dxqSFWttVIHroeU7MEV3EQfBPGk1731V4KqXzTHkyzRpNVeGFvKhwy RwxlsPhNTVv5KWsUSPmQmUldEyR5E6RsTP5Ji2B0Mzc4Kv1QNWWuP7o5m Q==; X-IronPort-AV: E=Sophos;i="5.40,407,1496059200"; d="scan'208";a="167822678" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from uxcn13-tdc-c.uoa.auckland.ac.nz ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Jul 2017 01:54:25 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.4) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 25 Jul 2017 01:54:25 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Tue, 25 Jul 2017 01:54:25 +1200 From: Peter Gutmann To: Robert Moskowitz , Anders Rundgren , "pkix@ietf.org" Thread-Topic: [pkix] Connected Cars. Upgradable/Replaceable IoT systems. Re: Managing Long-Lived CA certs Thread-Index: AQHTAd5+6l/jXclsikyPxskxVVbZeqJiMw+AgADQUkc= Date: Mon, 24 Jul 2017 13:54:24 +0000 Message-ID: <1500904462997.1000@cs.auckland.ac.nz> References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <003d01d2ffdd$35d67c70$a1837550$@x500.eu> <0edcee2d-3dea-bbaa-2cd1-cf3915bfeff7@gmail.com>, <07553cee-882a-74e3-569f-2c501461f2dd@htt-consult.com> In-Reply-To: <07553cee-882a-74e3-569f-2c501461f2dd@htt-consult.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [pkix] Connected Cars. Upgradable/Replaceable IoT systems. Re: Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 13:54:30 -0000 Robert Moskowitz writes:=0A= =0A= >The IEEE 1609.2 standard for Vehicle safety messaging has a 'monster' PKI= =0A= >with certificate management. To put it mildly.=0A= =0A= Not just a monster PKI, a monster in general. They invented their own=0A= gratuitously incompatible way of doing everything possible (message securit= y,=0A= certificates, you name it, including a pile of novel security mechanisms ne= ver=0A= before deployed at any real-world scale).=0A= =0A= The thing with X.509, CMS, PGP, whatever you want to use is that after abou= t=0A= twenty years of public naming and shaming vendors have got at least some of= =0A= the bits right (but see for example the thread currently running on mozilla= -=0A= dev about CAs all over the world issuing certs for domain names that can't = be=0A= validated, in other words that were never checked by the CA before the cert= s=0A= were issued).=0A= =0A= OTOH the 1609.2 stuff, which goes way beyond what any standard public CA ha= s=0A= ever attempted (e.g. SCMS or Secure Credential Management System, which is.= ..=0A= no, it's too horrible to go into) will be used in a closed, non-public=0A= environment where little if anything will ever be tested or checked for=0A= correctness.=0A= =0A= Until the Black Hat and Defcon presentations start appearing...=0A= =0A= >I worked on three telematics certificate systems.=0A= =0A= I got exposed to 1609.2. My response was that there simply wasn't enough= =0A= money in existence to get me to try and make that thing work.=0A= =0A= Peter.=0A= From nobody Mon Jul 24 07:11:39 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E12131D1E for ; Mon, 24 Jul 2017 07:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTIzW_7Op-eJ for ; Mon, 24 Jul 2017 07:11:36 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 35376131D21 for ; Mon, 24 Jul 2017 07:11:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 1662062192; Mon, 24 Jul 2017 10:11:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id c18oskYirEJk; Mon, 24 Jul 2017 10:11:29 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 3972562191; Mon, 24 Jul 2017 10:11:29 -0400 (EDT) To: Peter Gutmann , Anders Rundgren , "pkix@ietf.org" References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <003d01d2ffdd$35d67c70$a1837550$@x500.eu> <0edcee2d-3dea-bbaa-2cd1-cf3915bfeff7@gmail.com> <07553cee-882a-74e3-569f-2c501461f2dd@htt-consult.com> <1500904462997.1000@cs.auckland.ac.nz> From: Robert Moskowitz Message-ID: Date: Mon, 24 Jul 2017 10:11:26 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1500904462997.1000@cs.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [pkix] Connected Cars. Upgradable/Replaceable IoT systems. Re: Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 14:11:38 -0000 On 07/24/2017 09:54 AM, Peter Gutmann wrote: > Robert Moskowitz writes: > >> The IEEE 1609.2 standard for Vehicle safety messaging has a 'monster' PKI >> with certificate management. To put it mildly. > Not just a monster PKI, a monster in general. They invented their own > gratuitously incompatible way of doing everything possible (message security, > certificates, you name it, including a pile of novel security mechanisms never > before deployed at any real-world scale). > > The thing with X.509, CMS, PGP, whatever you want to use is that after about > twenty years of public naming and shaming vendors have got at least some of > the bits right (but see for example the thread currently running on mozilla- > dev about CAs all over the world issuing certs for domain names that can't be > validated, in other words that were never checked by the CA before the certs > were issued). > > OTOH the 1609.2 stuff, which goes way beyond what any standard public CA has > ever attempted (e.g. SCMS or Secure Credential Management System, which is... > no, it's too horrible to go into) will be used in a closed, non-public > environment where little if anything will ever be tested or checked for > correctness. > > Until the Black Hat and Defcon presentations start appearing... > >> I worked on three telematics certificate systems. > I got exposed to 1609.2. My response was that there simply wasn't enough > money in existence to get me to try and make that thing work. I made a counter proposal which was rejected becuase it was a change in direction. So I saw that the horses had already left the barn and just sit back and watch. And this may be the largest scale ever attempted. I don't know of any PKI with more than 100M entities enrolled. Though some of the national ID systems are in this size. But hopefully we are not talking 1609.2; I only mentioned it for some level of completeness in the automotive environment. From nobody Mon Jul 24 09:17:47 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE31F131E85 for ; Mon, 24 Jul 2017 09:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PloyT-666hAC for ; Mon, 24 Jul 2017 09:17:44 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7145131E7B for ; Mon, 24 Jul 2017 09:17:43 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id d145so47580386qkc.2 for ; Mon, 24 Jul 2017 09:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BrKthAGajqCypHsuNvHXv8eBUTzhdgk1wuxN0/Kwi9I=; b=kAbbz0lRV2UrSNhcLqewaCqCZtFN8sbMcGtuU3fDFmghbfF/wb7VlPhdTJimacqnhP YuWe2K0gMvK1auRKr//BWwsFIAkdB8aI+/hooiwow82z3qv8KWhtOju/4nv2l46eGYBq zvjCmCVA4ck3GAfkR99otWDvTQFXmAe7lbqbqirMT6xGfv/M/r96Q1fHeTP5c1cn59kH Y4HlZYHSFNjkYzBiC/AoahnAVFeG4tQZ/MwEyn2qqKAUyhyF07u5VumrERxuJsdubyyS eMon0+bnbuRZww0R8g/nK6pUBuXDmQZsJjmla6KkhEqU8nmYoyoM2MT4lftSMtl4H3aE 9gKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BrKthAGajqCypHsuNvHXv8eBUTzhdgk1wuxN0/Kwi9I=; b=hCBvtG6NZXo8fK13cfQiV+B7r/VJw0AXIMT7yeDSnlyZFUI30/r3xSDfyVthy++Eoo Lhv+FYr9ELaaHvv3uhkumebjbqNOzwRR/pswjKppa0+wD+s2VlhsDkJaUlOXZWBmSg4t vcZvaF3XYR+JykidFnn8E92i95Figphoctyueyflf59fg59/xmIEf0kpqbOf6453ZA7r ZtnpM7KNRVwsG2Bh2IK8ujsc4Fv+4iCyaxqGkoYQN3SscESlxf/Ay35CCbHo2dDI0Slf RKj/mseMldh6oWfCxoMZ6zArCRLvRBYb57i/gaUKQEYmeKC9/OAnho9nOiMPmDi12yCO jAYg== X-Gm-Message-State: AIVw111QQGZoz2CbcJXm3dxbwtIfQPaH2zdUHKowyrMi9kMLsrFgnmzz SwfWWWUs6qgfmN5J4rzSHNCckG7WBZq6 X-Received: by 10.55.107.134 with SMTP id g128mr19473254qkc.166.1500913062845; Mon, 24 Jul 2017 09:17:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.99 with HTTP; Mon, 24 Jul 2017 09:17:41 -0700 (PDT) In-Reply-To: <07553cee-882a-74e3-569f-2c501461f2dd@htt-consult.com> References: <467c8936-f6aa-0853-878c-24fc8803c599@openca.org> <001501d2ff0e$00eddfa0$02c99ee0$@x500.eu> <1500348690922.69356@cs.auckland.ac.nz> <27d212b4-c5a6-19d1-2afd-f18adaf21031@nist.gov> <003d01d2ffdd$35d67c70$a1837550$@x500.eu> <0edcee2d-3dea-bbaa-2cd1-cf3915bfeff7@gmail.com> <07553cee-882a-74e3-569f-2c501461f2dd@htt-consult.com> From: Erwann Abalea Date: Mon, 24 Jul 2017 18:17:41 +0200 Message-ID: To: Robert Moskowitz Cc: Anders Rundgren , "" Content-Type: multipart/alternative; boundary="001a114fe738f320520555128dca" Archived-At: Subject: Re: [pkix] Connected Cars. Upgradable/Replaceable IoT systems. Re: Managing Long-Lived CA certs X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 16:17:46 -0000 --001a114fe738f320520555128dca Content-Type: text/plain; charset="UTF-8" 2017-07-24 15:23 GMT+02:00 Robert Moskowitz : > I have consulted a few auto OEMs on matters like this. > > Today, and actually for a few years, all devices with software MUST be > field (minimum dealer) upgradeable. And some support 'over the air' > updates. > > This includes the 'telematics' control unit where up to now, has been the > only component with certificates. I worked on three telematics certificate > systems. > > The IEEE 1609.2 standard for Vehicle safety messaging has a 'monster' PKI > with certificate management. To put it mildly. > > However, IEEE 802.1AR 'Device Identity' standard defines the iDevID as a > permanent, non-mutable certificate with expected 10 - 20 year life. Yeah > lots of issues with this. Lots of reasons for this approach. Note that > the iDevID is only used for proof on manufacturer identity when enrolling > in the buyer's PKI with the lDevID (see ANIMA that is using these). It > may also be used in firmware updates from the manufacturer. Thus the > iDevID is not intended to be an 'operational' certifcate. > That's right. This long-term ID is used to get short-term IDs that are changed frequently and used to sign messages (CAM and DENM at least). Having worked on the ETSI counterpart of 1609.2, the expected figures are: around 1500 short-term IDs per vehicle and per year, CAMs are to be sent+signed between 1 and 10 times per second (depending on environment and network status). ETSI also wanted to have their own autoconfigurable network, in which network addresses contain GPS coordinates, some messages specify the intended network coverage, and every vehicle can act as a mobile router. And all messages are to be signed, by one of these short-term IDs. Reason for a new certificate format: reduce the size of network packets to limit the congestion; ETSI adds a congestion control layer that doesn't exist in 1609.x, limiting in-air messages to 0.6s, whatever the current rate (which is also negotiable). Reason for that many certificates: try to forbid an attacker to passively track a vehicle's path. Privacy, in fact. Revocation of these short-term IDs is somewhat defined in 1609.2, not at all in ETSI (that may change). -- Erwann. --001a114fe738f320520555128dca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= 2017-07-24 15:23 GMT+02:00 Robert Moskowitz <rgm-sec@htt-consult.c= om>:
I have consulted a few= auto OEMs on matters like this.

Today, and actually for a few years, all devices with software MUST be fiel= d (minimum dealer) upgradeable.=C2=A0 And some support 'over the air= 9; updates.

This includes the 'telematics' control unit where up to now, has be= en the only component with certificates.=C2=A0 I worked on three telematics= certificate systems.

The IEEE 1609.2 standard for Vehicle safety messaging has a 'monster= 9; PKI with certificate management.=C2=A0 To put it mildly.

However, IEEE 802.1AR 'Device Identity' standard defines the iDevID= as a permanent, non-mutable certificate with expected 10 - 20 year life.= =C2=A0 Yeah lots of issues with this.=C2=A0 Lots of reasons for this approa= ch.=C2=A0 Note that the iDevID is only used for proof on manufacturer ident= ity when enrolling in the buyer's PKI with the lDevID (see ANIMA that i= s using these).=C2=A0 =C2=A0It may also be used in firmware updates from th= e manufacturer.=C2=A0 Thus the iDevID is not intended to be an 'operati= onal' certifcate.

That's right.= This long-term ID is used to get short-term IDs that are changed frequentl= y and used to sign messages (CAM and DENM at least).

Having worked on the ETSI counterpart of 1609.2, the expected figures ar= e: around 1500 short-term IDs per vehicle and per year, CAMs are to be sent= +signed between 1 and 10 times per second (depending on environment and net= work status).

ETSI also wanted to have their own a= utoconfigurable network, in which network addresses contain GPS coordinates= , some messages specify the intended network coverage, and every vehicle ca= n act as a mobile router. And all messages are to be signed, by one of thes= e short-term IDs.

Reason for a new certificate for= mat: reduce the size of network packets to limit the congestion; ETSI adds = a congestion control layer that doesn't exist in 1609.x, limiting in-ai= r messages to 0.6s, whatever the current rate (which is also negotiable).
Reason for that many certificates: try to forbid an attacker to pa= ssively track a vehicle's path. Privacy, in fact.

<= div>Revocation of these short-term IDs is somewhat defined in 1609.2, not a= t all in ETSI (that may change).

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

[ Cross Post: Saag, PKIX, and LAMPS ]

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

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

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

Cheers,
Max


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

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

Russ


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

Hi all,

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

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

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

The Revocation Situation
=

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

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

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

The Discoverability Situation=

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

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

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

Deployment Trends in the Real= World

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

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

IETF Specific Situation and Issues

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

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

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

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

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

Final Considerations

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

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

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

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

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

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

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